[PATCH] OpenVPN: mark CBC ciphers as weak in WebUI
ummeegge at ipfire.org
Mon Jun 10 20:49:42 BST 2019
On Mo, 2019-06-10 at 20:12 +0100, Michael Tremer wrote:
> > On 10 Jun 2019, at 20:08, Peter Müller <peter.mueller at 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
> That keeps things together and we can coordinate better when we merge
> 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
> 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' -->
. 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!
> > >
> > > 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.
More information about the Development