From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] OpenVPN: mark CBC ciphers as weak in WebUI Date: Tue, 11 Jun 2019 11:17:44 +0100 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2353507614562444829==" List-Id: --===============2353507614562444829== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 10 Jun 2019, at 20:49, ummeegge wrote: >=20 > Hi, >=20 > On Mo, 2019-06-10 at 20:12 +0100, Michael Tremer wrote: >> Hi, >>=20 >>> On 10 Jun 2019, at 20:08, Peter M=C3=BCller >>> wrote: >>>=20 >>> Hello Michael, >>>=20 >>> thanks for your comments. >>>=20 >>>> Hi, >>>>=20 >>>> I think I can ACK this although we definitely should change the >>>> default. I have raised that a couple of times before. >>>=20 >>> Yes. This is true for IPsec as well... Patch is in my pipeline=E2=80=A6 >>=20 >> Okay. Can we try to make a patchset out of things like this in the >> future? >>=20 >> That keeps things together and we can coordinate better when we merge >> this. >>=20 >> 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. >>=20 >>>>=20 >>>> I also do not like having a very long list of ciphers that are >>>> weak. There are not too many left which are =E2=80=9Cstrong=E2=80=9D. Bu= t yeah, >>>> what can you do? >>>=20 >>> As far as I am concerned, there is little "strong" cryptography >>> left indeed. >>> It's basically only TLS >=3D 1.2 with AEAD (e.g. GCM) ciphers and >>> Forward Secrecy. >>>=20 >>> Speaking about RFC 8446, this is more or less what survived >>> discussions before >>> standardizing TLS 1.3 ... :-) >>=20 >> Yeah I picked up on that too, but we have to make sure that we ensure >> compatibility. >>=20 >> 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. Do we have any implementation of this somewhere? Right now this feature is enabled and will default to what ever the OpenVPN p= roject thinks is right, but the option on the web UI does not really matter a= ny more. The cipher selected here is only being used when you have an old cli= ent which does not know about ncp-ciphers, yet. > 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' -->=20 > https://forum.ipfire.org/viewtopic.php?f=3D50&t=3D22664 When you say most, how many is that? One is enough to have the DH params. > . 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=C2=B4s 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! Yes, I think we can safely move to EC crypto for modern clients. The question= is only how we can keep to support older clients. OpenVPN makes this very ve= ry very very difficult. >=20 >>=20 >> -Michael >>=20 >>>>=20 >>>> 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?=20 In essence you are right. But isn=E2=80=99t weak just another word for broken= ? And is something either broken or not? I think it does not matter how weak = something is really. The message we want to get across to users is to not use= these ciphers any more. Having something as =E2=80=9Cweak=E2=80=9D next to = =E2=80=9Cvery weak=E2=80=9D might make it sound a bit softer and that it migh= t be a little bit acceptable to use the weak cipher. >=20 >>>>=20 >>>> -Michael >>>=20 >>> Thanks, and best regards, >>> Peter M=C3=BCller >>> --=20 >>> The road to Hades is easy to travel. >>> -- Bion of Borysthenes >>=20 >>=20 >=20 > Some thoughts from here. >=20 > Best, >=20 > Erik --===============2353507614562444829==--