Re: [PATCH v3] OpenVPN: New AES-GCM cipher for N2N and RW

[ummeegge <ummeegge@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 4081 bytes --]

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
> >