From mboxrd@z Thu Jan 1 00:00:00 1970 From: ummeegge To: development@lists.ipfire.org Subject: Re: [PATCH] OpenVPN: mark CBC ciphers as weak in WebUI Date: Mon, 10 Jun 2019 21:49:42 +0200 Message-ID: In-Reply-To: <1833CC6E-915A-4C04-AA0A-2F7AF12B147A@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7363789210782566341==" List-Id: --===============7363789210782566341== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Hi, On Mo, 2019-06-10 at 20:12 +0100, Michael Tremer wrote: > Hi, > > > On 10 Jun 2019, at 20:08, Peter Müller > > 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 --===============7363789210782566341==--