OpenVPN 2.4 and pure elliptic curve crypto setup

[dariusz]

If anybody is interested I have found out that compiling OpenVPN 2.4 with the latest LibreSSL 2.5.0 library allows me to use ECDHE-ECDSA-CHACHA20-POLY1305 for control channel - potentially it should be faster, lighter for mobile devices with CPU without AES instructions support. Why to use ChaCha?

See https://blog.cloudflare.com/do-the-chac ... ptography/
Different context but principle remains the same - the relatively new kid on the crypto block has some advantages.



Compilation instruction for my Raspberry Pi:

1) LibreSSL

./configure --prefix=/opt/libressl-2.5.0
make -j 4 && sudo make install

2) OpenVPN

./configure --enable-systemd --with-crypto-library=openssl OPENSSL_SSL_LIBS="-L/opt/libressl-2.5.0/lib/ -lssl" OPENSSL_SSL_CFLAGS="-I/opt/libressl-2.5.0/include/" OPENSSL_CRYPTO_LIBS="-L/opt/libressl-2.5.0/lib/ -lcrypto" OPENSSL_CRYPTO_CFLAGS="-I/opt/libressl-2.5.0/include/" LDFLAGS="-L/opt/libressl-2.5.0/lib/"
make -j 4 && sudo make install

Result openvpn --version
OpenVPN 2.4.0 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 27 2017
library versions: LibreSSL 2.5.0, LZO 2.09

Now small change to server.config (do the same on client side if you use tls-cipher directive):

tls-cipher TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256

And now when using macOS using latest (3.7.0) tunnelblick with OpenVPN version set to 2.4 with LibreSSL 2.5.0 it nicely connects with latest crypto:

Tue Jan 31 09:32:59 2017 12.210.44.77:59459 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-CHACHA20-POLY1305

Please note that at the moment iOS OpenVPN client does not support 2.4 yet... so it only works from desktop. Let's hope that it will change soon.

[enri]

does iOS OpenVPN Connect able to cope with these settings?

[dariusz]

Nope.

iOS OpenVPN Connect does not support ec at the moment.

[heypete]

Hi all,

I've attempted (successfully, as far as I can tell) a similar setup using all-ECC keys, all at 521-bit length (because overkill is cheap, so why not?).

All appears to be working fine, with the client log showing "Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384" as expected.

I've also explicitly put "ecdh-curve secp521r1" in the server configuration.

I have the following questions:
1. In the absence of "ecdh-curve" being declared, what curve is used for ECDHE? I would expect the server to use the same curve as the server certificate (e.g. if the server uses secp384r1, the key exchange would use secp384r1, while if the server uses secp521r1, the key exchange would use secp521r1, and so on), but it'd be nice to confirm this.

2. Is there some way of verifying that the key exchange uses secp521r1 as expected? Even with verbosity turned up to 7 there's no indication of which curve is used for the key exchange.

3. Is there any particular reason to prefer tls-auth vs. tls-crypt? Any downsides of one versus the other? In my case, there's a very limited number of users (myself and a few family members) all using systems I administer, so widespread compatibility with the public is not necessary.

Thanks.

[dariusz]

1. In the absence of "ecdh-curve" being declared, what curve is used for ECDHE? I would expect the server to use the same curve as the server certificate (e.g. if the server uses secp384r1, the key exchange would use secp384r1, while if the server uses secp521r1, the key exchange would use secp521r1, and so on), but it'd be nice to confirm this.

As per man pages:
--ecdh-curve name
Specify the curve to use for elliptic curve Diffie Hellman. Available curves can be listed with --show-curves. The specified curve will only be used for ECDH TLS-ciphers. This option is not supported in mbed TLS builds of OpenVPN.


If no ecdh-curve is provided than at least my OpenVPN server (compiled with the latest LibreSSL and all my certs using brainpoolP512r1) will use secp384r1. My openvpn.log (Initialization Sequence details)

without ecdh-curve at all
Wed Feb 8 13:27:14 2017 OpenVPN 2.4.0 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Feb 5 2017
Wed Feb 8 13:27:14 2017 library versions: LibreSSL 2.5.1, LZO 2.09
Wed Feb 8 13:27:14 2017 Failed to extract curve from certificate (UNDEF), using secp384r1 instead.
Wed Feb 8 13:27:14 2017 ECDH curve secp384r1 added
Wed Feb 8 13:27:14 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:27:14 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 8 13:27:14 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:27:14 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

with "ecdh-curve brainpoolP512r1"
Wed Feb 8 13:29:04 2017 OpenVPN 2.4.0 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Feb 5 2017
Wed Feb 8 13:29:04 2017 library versions: LibreSSL 2.5.1, LZO 2.09
Wed Feb 8 13:29:04 2017 ECDH curve brainpoolP512r1 added
Wed Feb 8 13:29:04 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:29:04 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 8 13:29:04 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:29:04 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

2. Is there some way of verifying that the key exchange uses secp521r1 as expected? Even with verbosity turned up to 7 there's no indication of which curve is used for the key exchange.

check your server log after restart - as in previous point it should list what curve has been selected.

3. Is there any particular reason to prefer tls-auth vs. tls-crypt? Any downsides of one versus the other? In my case, there's a very limited number of users (myself and a few family members) all using systems I administer, so widespread compatibility with the public is not necessary.

Actually tls-crypt introduced in 2.4 is better. It does not only authenticate (like tls-auth) , but also encrypt the TLS control channel.

As per man pages:

--tls-crypt keyfile

Encrypt and authenticate all control channel packets with the key from keyfile. (See --tls-auth for more background.)

Encrypting (and authenticating) control channel packets:

· provides more privacy by hiding the certificate used for the TLS connection,

· makes it harder to identify OpenVPN traffic as such,

· provides "poor-man's" post-quantum security, against attackers who will never know the pre-shared key (i.e. no forward secrecy).

[heypete]

If no ecdh-curve is provided than at least my OpenVPN server (compiled with the latest LibreSSL and all my certs using brainpoolP512r1) will use secp384r1. My openvpn.log (Initialization Sequence details)

without ecdh-curve at all
Wed Feb 8 13:27:14 2017 OpenVPN 2.4.0 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Feb 5 2017
Wed Feb 8 13:27:14 2017 library versions: LibreSSL 2.5.1, LZO 2.09
Wed Feb 8 13:27:14 2017 Failed to extract curve from certificate (UNDEF), using secp384r1 instead.
Wed Feb 8 13:27:14 2017 ECDH curve secp384r1 added
Wed Feb 8 13:27:14 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:27:14 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 8 13:27:14 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:27:14 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

with "ecdh-curve brainpoolP512r1"
Wed Feb 8 13:29:04 2017 OpenVPN 2.4.0 armv7l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Feb 5 2017
Wed Feb 8 13:29:04 2017 library versions: LibreSSL 2.5.1, LZO 2.09
Wed Feb 8 13:29:04 2017 ECDH curve brainpoolP512r1 added
Wed Feb 8 13:29:04 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:29:04 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Wed Feb 8 13:29:04 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Wed Feb 8 13:29:04 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

Excellent. It does indeed show up in the server log, and the secp521r1 curve shows as being added correctly. Thanks!

Actually tls-crypt introduced in 2.4 is better. It does not only authenticate (like tls-auth) , but also encrypt the TLS control channel.

Right. I read the man page and understand the "Why tls-crypt is a good thing." concept. The major advantage is encrypting the control channel, which is handy. Other than compatibility issues with older clients (which don't apply in my case), are there any downsides? tls-crypt uses AES-256-CTR which is fast, and not much data gets sent over the control channel anyway, so there shouldn't be an meaningful performance impact. Still, it's nice to get confirmation.

Thanks for the prompt and detailed response.

[dariusz]

I think that the must is to use either of two parameters because they limit attack vector. as only authenticated packets are processed it makes it impossible for non valid user to try to DDoS your OpenVPN server as their non signed packets would be simply discarded before processing. From practical perspective I don't see massive advantage of neither of them. tls-crypt obfuscate OpenVPN traffic even more by static key encryption but as long as solid crypto is used I don't think it makes much difference from security perspective. Does it protect traffic from being detected as VPN? I doubt this claim. In places where it matters e.g. China, sophistication of their detection technology requires more clever tools anyway.

That said I decided to to use tls-crypt. Simply as you said because overkill is cheap:) Only cost I see is battery power - more complex crypto requires more processing. Depends on your usage pattern when on the move - vpn always on or just used for sensitive apps like banking. Unfortunately there is no iOS client yet supporting OpenVPN 2.4 new features so at least for me it is academic. Moving forward I will definitely switch all my VPN setup to elliptic crypto (mobile devices being the main reason).

[bird333]

Everything put together and here we are. Working EC encrypted OpenVPN session:
#server starts:
Mon Jan 16 11:14:44 2017 OpenVPN 2.4.0 armv7l-unknown-linux-gnueabihf [SSL (mbed TLS)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Jan 16 2017
Mon Jan 16 11:14:44 2017 library versions: mbed TLS 2.4.0, LZO 2.09
Mon Jan 16 11:14:44 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Jan 16 11:14:44 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Jan 16 11:14:44 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Jan 16 11:14:44 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Jan 16 11:14:44 2017 ROUTE_GATEWAY 192.168.142.1/255.255.255.0 IFACE=wlan0 HWADDR=f4:f2:6d:0f:68:9b
Mon Jan 16 11:14:44 2017 TUN/TAP device tun2 opened
Mon Jan 16 11:14:44 2017 TUN/TAP TX queue length set to 100
Mon Jan 16 11:14:44 2017 do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Mon Jan 16 11:14:44 2017 /sbin/ifconfig tun2 10.88.90.1 pointopoint 10.88.90.2 mtu 1500
Mon Jan 16 11:14:44 2017 /sbin/route add -net 10.88.90.0 netmask 255.255.255.0 gw 10.88.90.2
Mon Jan 16 11:14:44 2017 Could not determine IPv4/IPv6 protocol. Using AF_INET
Mon Jan 16 11:14:44 2017 Socket Buffers: R=[163840->163840] S=[163840->163840]
Mon Jan 16 11:14:44 2017 UDPv4 link local (bound): [AF_INET][undef]:1194
Mon Jan 16 11:14:44 2017 UDPv4 link remote: [AF_UNSPEC]
Mon Jan 16 11:14:44 2017 GID set to nogroup
Mon Jan 16 11:14:44 2017 UID set to openvpn_server
Mon Jan 16 11:14:44 2017 MULTI: multi_init called, r=256 v=256
Mon Jan 16 11:14:44 2017 IFCONFIG POOL: base=10.88.90.4 size=62, ipv6=0
Mon Jan 16 11:14:44 2017 Initialization Sequence Completed

Where does that cipher and hash come from? I don't have either of those in my config files but they show up in the logs. I have AES-256-CBC and SHA512 in my config.

[dariusz]

Can you please post your confit?

[bird333]

I will but your config doesn't seem to have this but you get this output too. Is it the TLS negotiation?

[Pippin]

@bird333
See manual 2.4 --ncp.....

[dariusz]

Crypto parameters negotiation is automatic unless explicitly disabled as per 2.4 manual

[bird333]

The control channel encryption still shows AES-256-CTR and SHA256 with 'ncp-disable' added to the server and client configs. The client log does show that AES-256-CBC and SHA512 for the 'data channel' which it didn't before I added 'ncp-disable'. See below.

Client log

Code: Select all

Mon May 22 18:07:35 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon May 22 18:07:35 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon May 22 18:07:35 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon May 22 18:07:35 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication




Mon May 22 18:07:35 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384
Mon May 22 18:07:35 2017 [server] Peer Connection Initiated with [AF_INET]*.*.*.*:1194
Mon May 22 18:07:35 2017 Key [AF_INET]*.*.*.*:1194 [0] not initialized (yet), dropping packet.
Mon May 22 18:07:35 2017 Key [AF_INET]*.*.*.*:1194 [0] not initialized (yet), dropping packet.
Mon May 22 18:07:36 2017 Key [AF_INET]*.*.*.*:1194 [0] not initialized (yet), dropping packet.
Mon May 22 18:07:36 2017 MANAGEMENT: >STATE:1495494456,GET_CONFIG,,,,,,
Mon May 22 18:07:36 2017 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Mon May 22 18:07:36 2017 PUSH: Received control message: 'PUSH_REPLY,ping 15,ping-restart 60,peer-id 1'
Mon May 22 18:07:36 2017 OPTIONS IMPORT: timers and/or timeouts modified
Mon May 22 18:07:36 2017 OPTIONS IMPORT: peer-id set
Mon May 22 18:07:36 2017 OPTIONS IMPORT: adjusting link_mtu to 1657
Mon May 22 18:07:36 2017 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon May 22 18:07:36 2017 Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Mon May 22 18:07:36 2017 Data Channel Decrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Mon May 22 18:07:36 2017 Data Channel Decrypt: Using 512 bit message hash 'SHA512' for HMAC authentication

[dariusz]

Mon Jan 16 11:14:44 2017 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Jan 16 11:14:44 2017 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Jan 16 11:14:44 2017 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Jan 16 11:14:44 2017 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

Above lines in server log indicate that you have tls-crypt enabled and it initiated control channel packets encryption. tls-crypt is not mandatory but adds extra layer of security. It is used in addition to control channel cipher which is either negotiated or explicitly specified by your configuration e.g. in your case ECDHE-ECDSA-AES256-GCM-SHA384 with HMAC - SHA512

[bird333]

I guess my question was why does it not match what's in the config? I suspect that 'tls-crypt' defaults to AES-256-CTR and SHA256 and there is no way to change it.

[dariusz]

@bird333

For me it looks the same. It is not configurable.

[bird333]

I found this in a google search. https://sourceforge.net/p/openvpn/mailm ... /35761755/ Indeed it looks like this is hardcoded and can't be changed.

[dariusz]

Cool. Thx for sharing.

[umdmc]

Nice write up. I was able to get it working on my router. One question though. I did the step using Openssl 1.1.0f:

Code: Select all

c:/OpenSSL-Win32/bin/openssl ec -in ECClient1.key -des3 -out ECClient1.3des.key

My generated key ECClient1.3des.key was created fine. But I am not seeing the initial syntax that you have in your key.

Code: Select all

-----BEGIN EC PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,6778BFA39150BF9E

It just shows the key without the above:

Code: Select all

-----BEGIN EC PRIVATE KEY-----

My key.....

-----END EC PRIVATE KEY-----

Does that matter?

[dariusz]

Are you checking the ECClient1.3des.key file?