Re: [PATCH] OpenVPN: mark CBC ciphers as weak in WebUI

[ummeegge <ummeegge@ipfire.org>]

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

Hi,

On Mo, 2019-06-10 at 20:12 +0100, Michael Tremer wrote:
> Hi,
> 
> > On 10 Jun 2019, at 20:08, Peter Müller <peter.mueller(a)ipfire.org>
> > wrote:
> > 
> > Hello Michael,
> > 
> > thanks for your comments.
> > 
> > > Hi,
> > > 
> > > I think I can ACK this although we definitely should change the
> > > default. I have raised that a couple of times before.
> > 
> > Yes. This is true for IPsec as well... Patch is in my pipeline…
> 
> Okay. Can we try to make a patchset out of things like this in the
> future?
> 
> That keeps things together and we can coordinate better when we merge
> this.
> 
> We have closed the last Core Update technically last week. Now we
> have some big changes here and I would prefer to not break the update
> but have it rather shipped as soon as possible.
> 
> > > 
> > > I also do not like having a very long list of ciphers that are
> > > weak. There are not too many left which are “strong”. But yeah,
> > > what can you do?
> > 
> > As far as I am concerned, there is little "strong" cryptography
> > left indeed.
> > It's basically only TLS >= 1.2 with AEAD (e.g. GCM) ciphers and
> > Forward Secrecy.
> > 
> > Speaking about RFC 8446, this is more or less what survived
> > discussions before
> > standardizing TLS 1.3 ... :-)
> 
> Yeah I picked up on that too, but we have to make sure that we ensure
> compatibility.
> 
> OpenVPN is hard to update. People cannot migrate from a cipher to
> another one and not all versions support GCM.
A helpful feature for this is --ncp-ciphers where we have had also some
discussions some time ago. In principle it is only a checkbox but
choosing the ciphers is more work also if we want to have a separate
encryption section in the WUI.

Another point which matches this topic i think is the DH-parameter
which is, i think, for updated systems (OpenVPN-2.4.x) useless since
mostly key exchanges are meanwhile managed via ECDH. We tested this
with 'dh none' --> 
https://forum.ipfire.org/viewtopic.php?f=50&t=22664
. But this is again another encryption setting which is also in my
opinion an advanced one in his specifics but a good candidate for a
default. We could also spare then the DH-parameter while PKI generation
(which needs really lot´s of time and can causes also troubles for weak
machines and long paramters). An DH-upload possiblity can still be
there for example to keep the possibility for backwards compatibility).
Did also some work on this but my time is currently really really rare!

> 
> -Michael
> 
> > > 
> > > I will wait for Erik to ack this, too.
I think we have two kinds of "weak" then. The 64bit block ciphers do
have also some technical disadvantage since Sweet32 a renegotiation is
forced after 64MB which can be fast reached. So we have a kind of "very
weak" and "weak" then? 

> > > 
> > > -Michael
> > 
> > Thanks, and best regards,
> > Peter Müller
> > -- 
> > The road to Hades is easy to travel.
> > 	-- Bion of Borysthenes
> 
> 

Some thoughts from here.

Best,

Erik