From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Feedback on testing of openvpn connections with openssl-3.2.0 Date: Fri, 19 Jan 2024 12:50:27 +0100 Message-ID: <42a6e462-bb9e-4eae-9ee9-95bff12c75be@ipfire.org> In-Reply-To: <4d559eeb-c0c3-4aee-be5f-9978afa649ca@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8238051572506687134==" List-Id: --===============8238051572506687134== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Peter & Michael, On 19/01/2024 09:50, Peter M=C3=BCller wrote: > Hello Adolf, hello Michael, >=20 >=20 >> Hi Michael & all, >> >> 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 l= east 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 = we did not touch Apache itself in this update, I cannot come up with any othe= r idea. >>> >>> When I raised the patch I looked through the logs and didn't find anythin= g that sprung out to me as being a problem. When Arne raised that bug I went = back and had another look at the logs and searched though them with various p= hrases and couldn't find anything either related to it. >>> >>> When I did my unstable update Apache did not stop for me. I had another l= ook at it just now and my RSA cert has a 4096 bit key. I must have re4-create= d it myself at some time in the past. The original version of the vm is proba= bly around 6 to 12 months old from when I had to re-install it due to some pr= oblem. >>> >>> 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 = problem with either of those two sizes. >>> >> Okay have done my testing and some more searching. 1024 bit rsa key works = fine with CU182 but Apache fails to start with CU183. >> >> 2048 bit rsa key works fine with both CU182 & CU183. >> >> >> I have found a mention that openssl-3.2.0 has increased the security level= from 1 to 2. >> >> With security level 2 a minimum of 2048 bit keys are required to be used. = Anything smaller is not accepted. >> >> >> Security level 1 accepted a minimum key length of 1024 bits. >> >> >> So that looks to be the cause of the effect found by Arne. It means the sy= stem must have had a 1024 bit rsa key length. >=20 > To be honest, I am surprised that modern web browsers still accept 1k RSA k= eys. I thought at least Firefox has started rejecting these a while ago. Firefox might well do so but as we have the ECDSA certificate as well all my = Firefox systems are taking that in preference. I have not been able to find a= ny way to make IPFire try and take only the 1024 bit RSA that I created. If I= remove the ECDSA certs from IPFire then apache won't restart as it looks for= both ecdsa and rsa certs to be present. It seems to me that anyone that has a 1024 bit rsa certificate won't be using= it on Firefox. I don't know if all browsers take the ecdsa cert in preferenc= e if it is available. So with my vm setup changing the 1024 bit rsa key to 4096 did not cause me to= have the message about unsigned certificate as my firefox used the ecdsa. >=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:- >> >> The default SSL/TLS security level has been changed from 1 to 2. RSA, >> =C2=A0=C2=A0=C2=A0 DSA and DH keys of 1024 bits and above and less than 20= 48 bits and ECC keys >> =C2=A0=C2=A0=C2=A0 of 160 bits and above and less than 224 bits were previ= ously accepted by >> =C2=A0=C2=A0=C2=A0 default but are now no longer allowed. By default TLS c= ompression was >> =C2=A0=C2=A0=C2=A0 already disabled in previous OpenSSL versions. At secur= ity level 2 it cannot >> =C2=A0=C2=A0=C2=A0 be enabled. >> >> >> There seem to be suggestions I have read that you can change the security = level to a different value to the default value if you want to, so we could p= ut it back to 1 if so desired. >> >> Personally I would be okay with it being at 2 but then we will need to che= ck if the certificate has a 1024 bit rsa key and if so to re-generate it. >> >> I am not sure if this regeneration will then cause the self signed certifi= cate notification to be re-shown to users and need to be accepted again. >=20 > Yes, this will cause such effects, because web browsers take a certificates= ' fingerprint into account when storing a certificate exception. >=20 > It is a tricky situation: I think we should definitely do something about t= his, and going back to security level 1 isn't a good option to me. >=20 > Personally, I would be happy with taking this as an opportunity of dropping= RSA for the web interface altogether. That might break some very outdated cl= ients who do not understand anything about ECC, but we can't help it. >=20 > It will also prompt certificate warnings to users whose clients previously = preferred RSA over ECC, but since the server does the latter for performance = reason, I'd dismiss that as a corner case. Do you know which clients might prefer rsa over ecdsa and how to set that pre= ference. In Firefox it looks to just use ecdsa. >=20 >> >> If so then this would need to be flagged up in the release notes so users = are not surprised by that. >=20 > Fully agree. Past changes of this kind have shown us how important communic= ation is. :-) I think this is good to mention but we should indicate it will only happen if= users have browser clients that have been set to prefer rsa over ecdsa. I can also confirm that the patch commits that Arne has merged work. I ran a = CU182 vm with a 1024 bit rsa cert and did the update to CU183 and everything = went without a problem and the rsa cert was 4096 bit afterwards. Regards, Adolf. >=20 > Thanks, and best regards, > Peter M=C3=BCller >=20 >> >> >> Regards, >> >> Adolf. >> >>> >>>> >>>> Since we are already using ECDSA keys as well as RSA keys, how about dro= pping 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 op= envpn connections on it that had been created with an older version of openss= l-3.x. Everything worked without any problems. >>>>> >>>>> I then created new connections with openssl-3.2.0 and tested them out. = Again the connection was successfully made and I could access the remote gree= n machine with no problems. >>>>> >>>>> So for openvpn there looks to be no issues with openssl-3.2.0 from my t= esting. >>>>> >>>>> Regards, >>>>> Adolf. >>>>> >>>>> --=20 >>>>> Sent from my laptop >>>>> >>>> --===============8238051572506687134==--