On 14/11/2019 11:35, Thomas Luening wrote: > # lsb_release -a > Description: Debian GNU/Linux 10 (buster) > Release: 10 > Codename: buster > > # openvpn --version > OpenVPN 2.4.8 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] > [MH/PKTINFO] [AEAD] built on Nov 13 2019 > library versions: OpenSSL 1.1.1d 10 Sep 2019, LZO 2.10
Nice! That's a good updated build. > Hello @all > > Every year once I check my OpenVPN settings to see if everything is up to > date. This was a log entry last year that showed that DHE has agreed on an > ephemeral key: > Sun Oct 7 10:16:48 2018 123.123.123.123:6577 Control Channel: TLSv1.2, cipher > TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA This is using TLSv1.2 on the control channel, where the TLS negotiated cipher is ECDHE-RSA-AES256-GCM-SHA384 > Now it looks different on the control channel ... none of the two cipher > suites in conf are used. Regardless of my settings the same another suite is > always used, so I'm afraid it's a static key again. Now I think possibly there > is a problem... ? I looked at the verbosed logs and searched the web, but I > can't find a helping clue anywhere. > > Settings Server ECDH: > dh none > ecdh-curve secp384r1 > tls-cipher TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384 I would recommend to *not* use --tls-cipher. That's an advanced feature, and in this case it will actually ensure your control channel is NOT upgraded to a stronger cipher suite than the one you give here. Remember that the TLS layer will always try to negotiate the strongest cipher possible which both sides support. To avoid getting too weak ciphers via various downgrade attempts, it's better to add this line to your config: --tls-version-min 1.2 ... this ensures only supported cipher suites in TLSv1.2 or newer is used. > # grep -i channel openvpn_udp.log > Thu Nov 14 10:35:04 2019 Outgoing Control Channel Encryption: Cipher > 'AES-256-CTR' initialized with 256 bit key > Thu Nov 14 10:35:04 2019 Outgoing Control Channel Encryption: Using 256 bit > message hash 'SHA256' for HMAC authentication > Thu Nov 14 10:35:04 2019 Incoming Control Channel Encryption: Cipher > 'AES-256-CTR' initialized with 256 bit key > Thu Nov 14 10:35:04 2019 Incoming Control Channel Encryption: Using 256 bit > message hash 'SHA256' for HMAC authentication These lines indicates you use --tls-crypt, so even the TLS traffic is encrypted using a shared symmetric key (the tls-crypt key). This means the encrypted TLS data stream is encrypted once more before being sent to the remote side. This has an additional computational overhead (crypto isn't free), but it increases the security even further and protects the clear-text data being passed over the initial TLS handshake (certificates, SNI). This is also believed to be a reasonable protection against future post-quantum attacks. > Thu Nov 14 10:37:03 2019 3.137.231.167:15653 Control Channel: TLSv1.3, cipher > TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA This uses TLSv1.3; the very latest TLS version which does a lot of differences compared to TLSv1.2 and older. I'm not up-to-date on how TLSv1.3 does the key exchange, but there has to be a key exchange to derive an ephemeral TLS session key used for the symmetric encryption of the TLS data payload. > Thu Nov 14 10:37:04 2019 3.137.231.167:15653 Outgoing Data Channel: Cipher > 'AES-256-GCM' initialized with 256 bit key > Thu Nov 14 10:37:04 2019 3.137.231.167:15653 Incoming Data Channel: Cipher > 'AES-256-GCM' initialized with 256 bit key These refers to the data channel cipher setup. The data channel encryption key is, as before, derived using the same PRF function with input from the symmetric TLS encryption key. > Setttings Server RSA: > dh /etc/openvpn/keys/dh.pem > tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384 > > # grep -i channel openvpn_udp.log > Thu Nov 14 10:41:46 2019 Outgoing Control Channel Encryption: Cipher > 'AES-256-CTR' initialized with 256 bit key > Thu Nov 14 10:41:46 2019 Outgoing Control Channel Encryption: Using 256 bit > message hash 'SHA256' for HMAC authentication > Thu Nov 14 10:41:46 2019 Incoming Control Channel Encryption: Cipher > 'AES-256-CTR' initialized with 256 bit key > Thu Nov 14 10:41:46 2019 Incoming Control Channel Encryption: Using 256 bit > message hash 'SHA256' for HMAC authentication Same as above, tls-crypt > Thu Nov 14 10:41:59 2019 3.137.231.167:17461 Control Channel: TLSv1.3, cipher > TLSv1.3 TLS_AES_256_GCM_SHA384, 4096 bit RSA Same as above, TLSv1.3 does the key exchange differently than TLSv1.2. > Thu Nov 14 10:42:00 2019 3.137.231.167:17461 Outgoing Data Channel: Cipher > 'AES-256-GCM' initialized with 256 bit key > Thu Nov 14 10:42:00 2019 3.137.231.167:17461 Incoming Data Channel: Cipher > 'AES-256-GCM' initialized with 256 bit key Same as above, data channel crypto setup. > Is there a Problem? Thank you! No, I would say this looks pretty good and solid. I would still recommend to kick out --tls-cipher, and consider setting --tls-version-min to at least 1.2. If you know all your clients are capable of TLSv1.3, then set it to 1.3. One detail though. I see you use "ecdh-curve secp384r1". I don't see that EC has been taken into use, but that is most likely to your server and client certificates not being issued with an EC key, only RSA keys. This means that option is not really taken into use. And in regards to you concerns about static key setup, that is not possible to achieve in the moment you add --key/--cert/--ca options in your config. Those options requires --tls-client or --tls-server (which are added automatically if you use --client or --server options). A static key setup will also require the use of --secret instead of --key. A static key setup does also not have a control and data channel, so you would not see the TLS mentions as well as the control/data channel log lines. -- kind regards, David Sommerseth OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
