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 10:44:05 +0000 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5743112904987535735==" List-Id: --===============5743112904987535735== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 lea= st 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 a= nd 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 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 ba= ck and had another look at the logs and searched though them with various phr= ases and couldn't find anything either related to it. > > When I did my unstable update Apache did not stop for me. I had another loo= k 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 probabl= y around 6 to 12 months old from when I had to re-install it due to some prob= lem. > > 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 1= 024 and 2048 bit certs and test doing the update and see if I get the same pr= oblem with either of those two sizes. > Okay have done my testing and some more searching. 1024 bit rsa key works fin= e 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 fr= om 1 to 2. With security level 2 a minimum of 2048 bit keys are required to be used. Any= thing 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 syste= m must have had a 1024 bit rsa key length. It is in the changelog but you would have to read it closely and it is not ve= ry 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, DSA and DH keys of 1024 bits and above and less than 2048 bits and ECC ke= ys of 160 bits and above and less than 224 bits were previously accepted by default but are now no longer allowed. By default TLS compression was already disabled in previous OpenSSL versions. At security level 2 it can= not be enabled. There seem to be suggestions I have read that you can change the security lev= el to a different value to the default value if you want to, so we could put = it back to 1 if so desired. Personally I would be okay with it being at 2 but then we will need to check = 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 certificat= e notification to be re-shown to users and need to be accepted again. If so then this would need to be flagged up in the release notes so users are= not surprised by that. Regards, Adolf. > >> >> Since we are already using ECDSA keys as well as RSA keys, how about dropp= ing 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 o= penssl-3.2.0 version that is in next. >>> >>> I cloned a vm and updated it to unstable (CU183) and ran my existing open= vpn 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. Ag= ain 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 tes= ting. >>> >>> Regards, >>> Adolf. >>> >>> --=20 >>> Sent from my laptop >>> >> --===============5743112904987535735==--