From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: Feedback on testing of openvpn connections with openssl-3.2.0 Date: Fri, 19 Jan 2024 08:50:00 +0000 Message-ID: <4d559eeb-c0c3-4aee-be5f-9978afa649ca@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1203159589319590922==" List-Id: --===============1203159589319590922== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Adolf, hello Michael, > Hi Michael & all, >=20 > On 17/01/2024 15:25, Adolf Belka wrote: >> Hi Michael & all, >> >> On 17/01/2024 11:22, Michael Tremer wrote: >>> Hello Adolf, >>> >>> Thank you very much for testing. >>> >>> I believe that I might have a small regression from OpenSSL 3.2.0 - at le= ast I think it is that: >>> >>> =C2=A0=C2=A0 https://bugzilla.ipfire.org/show_bug.cgi?id=3D13527 >>> >>> Apache won=E2=80=99t start if a system has been upgraded for a long time = and is using an older RSA key. >>> >>> I could not find any indication in the change log of OpenSSL, but since w= e did not touch Apache itself in this update, I cannot come up with any other= idea. >> >> When I raised the patch I looked through the logs and didn't find anything= that sprung out to me as being a problem. When Arne raised that bug I went b= ack and had another look at the logs and searched though them with various ph= rases and couldn't find anything either related to it. >> >> When I did my unstable update Apache did not stop for me. I had another lo= ok at it just now and my RSA cert has a 4096 bit key. I must have re4-created= it myself at some time in the past. The original version of the vm is probab= ly around 6 to 12 months old from when I had to re-install it due to some pro= blem. >> >> My production system has a 2048 bit key. Maybe that makes the difference. >> >> I will do some clones of my vm and re-create the Apache server certs with = 1024 and 2048 bit certs and test doing the update and see if I get the same p= roblem with either of those two sizes. >> > Okay have done my testing and some more searching. 1024 bit rsa key works f= ine with CU182 but Apache fails to start with CU183. >=20 > 2048 bit rsa key works fine with both CU182 & CU183. >=20 >=20 > I have found a mention that openssl-3.2.0 has increased the security level = from 1 to 2. >=20 > With security level 2 a minimum of 2048 bit keys are required to be used. A= nything smaller is not accepted. >=20 >=20 > Security level 1 accepted a minimum key length of 1024 bits. >=20 >=20 > So that looks to be the cause of the effect found by Arne. It means the sys= tem must have had a 1024 bit rsa key length. To be honest, I am surprised that modern web browsers still accept 1k RSA key= s. I thought at least Firefox has started rejecting these a while ago. >=20 >=20 > It is in the changelog but you would have to read it closely and it is not = very near the top of the changelog. This is what is said:- >=20 > The default SSL/TLS security level has been changed from 1 to 2. RSA, > =C2=A0=C2=A0 DSA and DH keys of 1024 bits and above and less than 2048 bit= s and ECC keys > =C2=A0=C2=A0 of 160 bits and above and less than 224 bits were previously = accepted by > =C2=A0=C2=A0 default but are now no longer allowed. By default TLS compres= sion was > =C2=A0=C2=A0 already disabled in previous OpenSSL versions. At security le= vel 2 it cannot > =C2=A0=C2=A0 be enabled. >=20 >=20 > There seem to be suggestions I have read that you can change the security l= evel to a different value to the default value if you want to, so we could pu= t it back to 1 if so desired. >=20 > Personally I would be okay with it being at 2 but then we will need to chec= k if the certificate has a 1024 bit rsa key and if so to re-generate it. >=20 > I am not sure if this regeneration will then cause the self signed certific= ate notification to be re-shown to users and need to be accepted again. Yes, this will cause such effects, because web browsers take a certificates' = fingerprint into account when storing a certificate exception. It is a tricky situation: I think we should definitely do something about thi= s, and going back to security level 1 isn't a good option to me. Personally, I would be happy with taking this as an opportunity of dropping R= SA for the web interface altogether. That might break some very outdated clie= nts who do not understand anything about ECC, but we can't help it. It will also prompt certificate warnings to users whose clients previously pr= eferred RSA over ECC, but since the server does the latter for performance re= ason, I'd dismiss that as a corner case. >=20 > If so then this would need to be flagged up in the release notes so users a= re not surprised by that. Fully agree. Past changes of this kind have shown us how important communicat= ion is. :-) Thanks, and best regards, Peter M=C3=BCller >=20 >=20 > Regards, >=20 > Adolf. >=20 >> >>> >>> Since we are already using ECDSA keys as well as RSA keys, how about drop= ping the RSA keys altogether to solve this problem? >> >> We could do that but I would think 4096 bit keys are still okay for RSA. >> >> Will let you know what I find with my testing. >> >> Regards, >> >> Adolf. >> >>> >>> -Michael >>> >>>> On 16 Jan 2024, at 14:18, Adolf Belka wrote: >>>> >>>> Hi All, >>>> >>>> At the last video call we agreed to test out openvpn and ipsec with the = openssl-3.2.0 version that is in next. >>>> >>>> I cloned a vm and updated it to unstable (CU183) and ran my existing ope= nvpn connections on it that had been created with an older version of openssl= -3.x. Everything worked without any problems. >>>> >>>> I then created new connections with openssl-3.2.0 and tested them out. A= gain the connection was successfully made and I could access the remote green= machine with no problems. >>>> >>>> So for openvpn there looks to be no issues with openssl-3.2.0 from my te= sting. >>>> >>>> Regards, >>>> Adolf. >>>> >>>> --=20 >>>> Sent from my laptop >>>> >>> --===============1203159589319590922==--