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:
Code: Select all
dh /etc/openvpn/keys/dh.pem
tls-auth /etc/openvpn/keys/ta.key 0
Code: Select all
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
Variant 1:
Code: Select all
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
Code: Select all
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
Code: Select all
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
Code: Select all
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
This is the output of an established connection with old Conf:
Code: Select all
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
Code: Select all
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
Code: Select all
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
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