Hi Michael,
Am Montag, den 26.02.2018, 10:24 +0000 schrieb Michael Tremer via Development:
Hi,
some ECC in OpenVPN would be really nice. We have that in IPsec for quite a while now and it makes the tunnels come up a lot faster and we can assume that it is more secure, too.
I can confirm this here too, the key exchange on IPFires updated OpenVPN looks now like this
Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384, 8192 bit RSA
even i used 8192 bit in my testing scenario (normally 2048 bit) the connection build up and the key exchange is really fast.
ChaCha20-Poly1305 is quite interesting, too. It is an AEAD just like AES-*-GCM. It is supposed to be really fast on mobile devices and an alternative to AES. We only have one other alternative to AES which is Camellia. But that one does not seem to receive a lot of love these days.
Seed is also available which did not marked as 'weak' but possibly not as widely used as the others i think. A modern cipher usage from Mozilla can be found in here --> https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility whereby there are some limitations for IPFire since we do not have currently the possiblity for ECDSA instead of RSA, also OpenVPN limits at this time character lenght to 256 'Maximum optione line length (256) exceeded' which should be a known bug and also a fixed one https://community.openvpn.net/openvpn/ticket/631 but it appears again in 2.4.4 . Checked it and this
ipfire-server openvpnserver[16775]: cipher_list = 'TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-RSA-WITH-AES-256-GCM-SHA384:TLS-ECDHE-ECDSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256:TLS-ECDHE-ECDSA-WITH-AES-128-GCM-SHA256'
was the maximum.
In contrast to Camellia, AES is usually hardware-accelerated whereas ChaCha20 can be implemented very efficiently in software that it does not consume too much CPU time at all. Perfect for mobile to save battery life.
Probably there is not very good support for ChaCha20-Poly1305 out there. So AES will be the default, but we would have a very good alternative for anyone who know what they are doing.
If someone wants to use ChaCha20-Poly1305 this should be no problem via via the "Additional configuration".
May we should set also AES-256-GCM as default cipher instead of AES- 256-CBC in ovpnmain.cgi ?!
ECDSA instead of RSA might be also worth to think about but as i said, this implies huge changes.
Best, -Michael
On Mon, 2018-02-26 at 07:48 +0100, ummeegge wrote:
Hi Michael,
Am Sonntag, den 25.02.2018, 17:06 +0000 schrieb Michael Tremer via Development:
Hi,
I suppose this looks alright.
OK
Does OpenVPN 2.4 support ChaCha20-Poly1305, too?
Yes, but i think only via the '--tls-cipher' directive which IPFire currently do not supports via WUI. Made a quick try over the server.conf.local and the additional configuration.
server.conf.local entries:
tls-version-min 1.2 tls-cipher TLS-ECDHE-RSA-WITH-CHACHA20-POLY1305-SHA256
whereby the server logs points the following out:
Feb 26 07:19:47 ipfire-prime openvpnserver[10190]: cipher_list = 'TLS-ECDHE- RSA-WITH-CHACHA20-POLY1305-SHA256'
But in general we step into a new crypto era with OpenVPN since ECC is now fully integrated in OpenVPN.
Under the hood we will discover now also ECDHE for the control channel without changing anything so the EC crypto is now partly available with Core 120.
But pure elliptic curve crypto is also possible e.g. https://forums.openvpn.net/viewtopic.php?t=23227 but this would be a huge amount of changes in ovpnmain.cgi but may it is worth it. Let´s see...
-Michael
Greetings,
Erik