From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Feedback on testing of openvpn connections with openssl-3.2.0 Date: Fri, 19 Jan 2024 16:25:04 +0000 Message-ID: <568F6977-250B-4079-B0EE-1A128FF8C201@ipfire.org> In-Reply-To: <42a6e462-bb9e-4eae-9ee9-95bff12c75be@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6573626473826577645==" List-Id: --===============6573626473826577645== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 19 Jan 2024, at 11:50, Adolf Belka wrote: >=20 > Hi Peter & Michael, >=20 > On 19/01/2024 09:50, Peter M=C3=BCller wrote: >> Hello Adolf, hello Michael, >>> Hi Michael & all, >>>=20 >>> On 17/01/2024 15:25, Adolf Belka wrote: >>>> Hi Michael & all, >>>>=20 >>>> On 17/01/2024 11:22, Michael Tremer wrote: >>>>> Hello Adolf, >>>>>=20 >>>>> Thank you very much for testing. >>>>>=20 >>>>> I believe that I might have a small regression from OpenSSL 3.2.0 - at = least I think it is that: >>>>>=20 >>>>> https://bugzilla.ipfire.org/show_bug.cgi?id=3D13527 >>>>>=20 >>>>> Apache won=E2=80=99t start if a system has been upgraded for a long tim= e and is using an older RSA key. >>>>>=20 >>>>> 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 oth= er idea. >>>>=20 >>>> When I raised the patch I looked through the logs and didn't find anythi= ng 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 = phrases and couldn't find anything either related to it. >>>>=20 >>>> When I did my unstable update Apache did not stop for me. I had another = look at it just now and my RSA cert has a 4096 bit key. I must have re4-creat= ed it myself at some time in the past. The original version of the vm is prob= ably around 6 to 12 months old from when I had to re-install it due to some p= roblem. >>>>=20 >>>> My production system has a 2048 bit key. Maybe that makes the difference. >>>>=20 >>>> I will do some clones of my vm and re-create the Apache server certs wit= h 1024 and 2048 bit certs and test doing the update and see if I get the same= problem with either of those two sizes. >>>>=20 >>> Okay have done my testing and some more searching. 1024 bit rsa key works= fine 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 leve= l from 1 to 2. >>>=20 >>> With security level 2 a minimum of 2048 bit keys are required to be used.= Anything 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 s= ystem must have had a 1024 bit rsa key length. >> To be honest, I am surprised that modern web browsers still accept 1k RSA = keys. I thought at least Firefox has started rejecting these a while ago. >=20 > Firefox might well do so but as we have the ECDSA certificate as well all m= y Firefox systems are taking that in preference. I have not been able to find= any 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 f= or both ecdsa and rsa certs to be present. You can simply remove the ECDSA certificates from the configuration file in /= etc/httpd/conf/vhosts.d/ipfire-interface-ssl.conf. Otherwise there is no way to convince your browser to use old crypto as far a= s I know. Some browsers have feature flags where certain things can be enable= d/disabled but that usually is for development/testing newer features or thin= gs that have just been released to the masses. > It seems to me that anyone that has a 1024 bit rsa certificate won't be usi= ng it on Firefox. I don't know if all browsers take the ecdsa cert in prefere= nce if it is available. To put it simply, the IPFire websites do not use RSA for several years now. W= e only use ECDSA certificates there. So browsers need to be *very* old to not= support that. Hence I would support to remove RSA from the=C2=B4 web UI. > 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. I believe virtually nobody will see it as they will only use ECDSA. >>>=20 >>>=20 >>> It is in the changelog but you would have to read it closely and it is no= t 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, >>> DSA and DH keys of 1024 bits and above and less than 2048 bits and EC= C keys >>> 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= cannot >>> be enabled. >>>=20 >>>=20 >>> 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 = put it back to 1 if so desired. >>>=20 >>> Personally I would be okay with it being at 2 but then we will need to ch= eck 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 certif= icate notification to be re-shown to users and need to be accepted again. >> Yes, this will cause such effects, because web browsers take a certificate= s' fingerprint into account when storing a certificate exception. >> It is a tricky situation: I think we should definitely do something about = this, 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 droppin= g RSA for the web interface altogether. That might break some very outdated c= lients who do not understand anything about ECC, but we can't help it. >> 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. >=20 > Do you know which clients might prefer rsa over ecdsa and how to set that p= reference. In Firefox it looks to just use ecdsa. I tried to figure this out by finding some report on browser compatibility/us= age, but I didn=E2=80=99t find anything that is recent enough. I believe that no recent OS/browser would struggle with this. >>>=20 >>> If so then this would need to be flagged up in the release notes so users= are not surprised by that. >> Fully agree. Past changes of this kind have shown us how important communi= cation 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. >=20 > 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 everythin= g went without a problem and the rsa cert was 4096 bit afterwards. Thank you for confirming. I am still not entirely sure if we should leave thi= s in, or whether we should remove RSA entirely. I do not see what RSA provide= s at this point. -Michael > Regards, >=20 > Adolf. >=20 >> Thanks, and best regards, >> Peter M=C3=BCller >>>=20 >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>>>=20 >>>>>=20 >>>>> Since we are already using ECDSA keys as well as RSA keys, how about dr= opping the RSA keys altogether to solve this problem? >>>>=20 >>>> We could do that but I would think 4096 bit keys are still okay for RSA. >>>>=20 >>>> Will let you know what I find with my testing. >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 >>>>>=20 >>>>> -Michael >>>>>=20 >>>>>> On 16 Jan 2024, at 14:18, Adolf Belka wrote: >>>>>>=20 >>>>>> Hi All, >>>>>>=20 >>>>>> At the last video call we agreed to test out openvpn and ipsec with th= e openssl-3.2.0 version that is in next. >>>>>>=20 >>>>>> I cloned a vm and updated it to unstable (CU183) and ran my existing o= penvpn connections on it that had been created with an older version of opens= sl-3.x. Everything worked without any problems. >>>>>>=20 >>>>>> 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 gre= en machine with no problems. >>>>>>=20 >>>>>> So for openvpn there looks to be no issues with openssl-3.2.0 from my = testing. >>>>>>=20 >>>>>> Regards, >>>>>> Adolf. >>>>>>=20 >>>>>> --=20 >>>>>> Sent from my laptop --===============6573626473826577645==--