Problems to evalujate the security of my setup

MaddinR

Hello @ all

I want to evaluate the security of my settings, but unfortunately that is not so easy and I hope to get some help. I'm a little unclear about authentication and using the control channel. Please be lenient, I wrote this with Help by an Online-Translator.

This is an excerpt from my old conf with the given output:

dh       /etc/openvpn/keys/dh.pem
tls-auth /etc/openvpn/keys/ta.key 0

This is openvpn's output after start:

Mon Oct  1 16:14:38 2018 OpenVPN 2.4.6 armv6l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Aug 12 2018
Mon Oct  1 16:14:38 2018 library versions: OpenSSL 1.1.0f  25 May 2017, LZO 2.08
Mon Oct  1 16:14:38 2018 Diffie-Hellman initialized with 2048 bit key
Mon Oct  1 16:14:38 2018 Outgoing Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication
Mon Oct  1 16:14:38 2018 Incoming Control Channel Authentication: Using 512 bit message hash 'SHA512' for HMAC authentication

Now I want to improve my security with some changed settings. This is an excerpt from 2 tries of my new Conf.
Variant 1:

dh none
ecdh-curve secp384r1
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
tls-crypt /etc/openvpn/keys/ta.key

The output:

Mon Oct  1 16:22:31 2018 OpenVPN 2.4.6 armv6l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Aug 12 2018
Mon Oct  1 16:22:31 2018 library versions: OpenSSL 1.1.0f  25 May 2017, LZO 2.08
Mon Oct  1 16:22:31 2018 ECDH curve secp384r1 added
Mon Oct  1 16:22:31 2018 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Oct  1 16:22:31 2018 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Oct  1 16:22:31 2018 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Oct  1 16:22:31 2018 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

Variant 2:

dh /etc/openvpn/keys/dh.pem
ecdh-curve secp384r1
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384
tls-crypt /etc/openvpn/keys/ta.key

The output:

Mon Oct  1 16:19:16 2018 OpenVPN 2.4.6 armv6l-unknown-linux-gnueabihf [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD] built on Aug 12 2018
Mon Oct  1 16:19:16 2018 library versions: OpenSSL 1.1.0f  25 May 2017, LZO 2.08
Mon Oct  1 16:19:16 2018 Diffie-Hellman initialized with 2048 bit key
Mon Oct  1 16:19:16 2018 ECDH curve secp384r1 added
Mon Oct  1 16:19:16 2018 Outgoing Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Oct  1 16:19:16 2018 Outgoing Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication
Mon Oct  1 16:19:16 2018 Incoming Control Channel Encryption: Cipher 'AES-256-CTR' initialized with 256 bit key
Mon Oct  1 16:19:16 2018 Incoming Control Channel Encryption: Using 256 bit message hash 'SHA256' for HMAC authentication

That seems all to be alright, the differences are explainable. But after here my/the problems launched.

This is the output of an established connection with old Conf:

Mon Oct  1 16:16:48 2018 2.999.888.117:1565 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

Output with new Conf, variant 1:

Mon Oct  1 16:22:57 2018 2.999.888.117:6433 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

New Conf, variant 2:

Mon Oct  1 16:20:26 2018 2.999.888.117:9702 Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

It seems, it is all the same ...(???)... but is it realy the same? Where is the improvement, if apparently all variants come to the same result?

But the important questions are: What happens if a smartphone with an older Android does not support the new settings like elliptic curves, if "dh none" is set like Variant 1? Is there something like a fallback on lower or no security? Or is just the connection failed because it is rejected by Server?

What happens if both parameters (dh-file and EC (variant 2)) are set to allow old and new client devices to connect? Is there a conflict or is a particular procedure preferred when both are possible? Which one is preferred, the one with the highest security, or just the first match found?

I do not know how I can test that all with Android or can force problems or reject connects... android in several generations is not really helpful in that .... :?

Best regard and thank you
Martin

MaddinR

Hello @ all

Is there really no one here who can help me with my question? :?

I'll try again by simplifying my question. Is it the right way to indicate both...?... the earlier dh statement and the newer ECDH, as in the following example? Or do I create/force a conflict or unpredictable behavior?

tls-crypt /etc/openvpn/ta.key
dh /etc/openvpn/dh.pem
ecdh-curve secp384r1
tls-cipher TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GC

Best regards
Martin

TinCanTech

OpenVPN cryptography is actually provided by the SSL library OpenSSL or mbedTLS.

So you must adhere to the conventions they enforce.

As for your "simplified" question above .. I don't think you can mix --dh with --ecdh-curve.

Best advice is .. try it yourself .. just like everybody else does.

MaddinR

Thank you for your response.

Yes, I get that now.... so not both together. Unfortunately, I find for my 2 following questions neither in the man page nor on the Web the answers. Are ecdh-curve and tls-cipher limiting parameters, that force only my given certain parameter? And if I don't specify these parameters, does OpenVPN still use the ECDH as default to establish the connection?

I only can't understand, is it necessary to set ecdh-curve in my Conf to get ecdh-curve, or are ecdh-curves default-behavior of Openvpn 2.4.6?

Try and error is not a good way to create security, if no security maybe comes out in the end. :-)

TinCanTech

Your logs at --verb 4 will indicate the security in place.

The openvpn defaults are fairly strict.

When you create your PKI you will start to learn.

The fact still remains that learning computer security is a never ending battle ..
Just when you think every thing is covered some clever git goes and discovers VORACLE
or any of the other major security flaws of our current computers.

If you are that worried then consult a security expert.

Or do like Ed Snowden ... 😉

MaddinR

TinCanTech wrote When you create your PKI you will start to learn.

There is not my problem... I use OpenVPN since 6-8 Years ago very successful and never with Problems... that is really not the Problem. My Problem is, that elliptic-curves are new Features since Version 2.4 and I dont know, that I have to activate it or is it default active. BTW, I read some Facts of Voracle a few weeks ago, that is the reason, while I am looking to ECDH, to improve my Security-Settings.

Ok, after reading ~100 and more Web-Sites it seems, the ecdh-curve- and tls-cipher-Statements are not a activating-in-general-Statement, but only a limiting Statement. Would you also see it that way?

bg, Martin

TinCanTech

Google has this at the top of the list.

MaddinR

Hello

Unfortunately the link was'nt helpful. Looking back it's seems like a guessing-game over countless web-pages and some further days. And no one of the pages is really concret and based on ultimate statements.

I have now found out, that the right way is to not specify a tls-cipher, because a fix cipher specification would prevent a later upgrade (Openssl) to a better (more secure) cipher from being used.

This is imho (at now) a good solution... without a tls-cipher-statement:

dh none
ecdh-curve secp384r1
tls-crypt /etc/openvpn/ta.key

Thank you for your suggestions.