From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adolf Belka To: development@lists.ipfire.org Subject: Re: Forthcoming OpenSSL Releases (new blocking bug from openssl-3.x) Date: Fri, 02 Jun 2023 19:54:43 +0200 Message-ID: <9f20248d-6ce4-21fe-894c-b87fffef98ad@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7170087306099390772==" List-Id: --===============7170087306099390772== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi All, Just when you thought it was safe to get back in the water - aaaaah. I suspected that IPSec would also suffer from the same problem of openssl-3.x= vs openssl-1.1.1x for the opening of .p12 certificates. Today, from feedback from Roberto Pena in the forum, it turns out that trying= to create a Root/Host certificate set for IPSec causes an error message to b= e created. I reproduced this on CU175 Testing build master/9797af30 and confirmed that i= t did not happen in CU174. I added the -legacy option into every openssl command in vpnmain.cgi dealing = with .p12 files but this did not solve this problem. I then added -legacy to = every openssl command. This solved the problem. I then tried only adding the legacy option to each non .p12 openssl command o= ne at a time but this also did not fix the problem. So more than one of the n= on .p12 commands needs to be defined as legacy at the same time. I thought if every openssl command was going to have the legacy option then t= he same effect should be possible by adding the legacy provider into the open= ssl.cnf file. Tried this but it didn't solve the error message when creating = the Root/Host IPSec certificate set. So there must be some sort of difference= between the command line legacy option and the legacy provider option in the= openssl.cnf file. So I will also submit a patch set for the vpnmain.cgi file where all openssl = commands have the legacy option added. The same will be done for the ovpnmain.cgi file to be on the safe side. Curre= ntly I had only added it to the openssl commands running on .p12 files. I did test creating the Root/Host certificate set on OpenVPN with openssl-3.x= and that worked successfully but I think having the legacy option on every o= penssl command should not cause anything to break. Hope to provide a patch set for the various IPSec/OpenVPN openssl issues foun= d over the weekend, presuming no one finds any further issues. As Michael has= said in the past. Better to get any patch fix correct than to have a faulty = one quickly. Regards, Adolf. On 31/05/2023 20:53, Adolf Belka wrote: > Hi Michael, > > On 31/05/2023 20:43, Michael Tremer wrote: >> Hello, >> >> Does this mean that OpenVPN cannot read those files either? I had that sus= picion. > I believe that is the case. The failure I found has no openssl command in t= he cgi file and adding "providers legacy default" to the end of the client n2= n conf file made everything work again. > > Your idea of making a modification to the openssl conf file is a good one a= nd I will try that out and see if that works. If so then that would be the be= tter approach as then any certificates would be covered by the legacy approac= h if required. > > Regards, > Adolf. >> >> I will halt the update for now and let=E2=80=99s take some more time to fi= gure this one out. >> >> Best, >> -Michael >> >>> On 31 May 2023, at 19:42, Adolf Belka wrote: >>> >>> Hi All, >>> >>> I have figured out how to solve the problem. I have to add "providers leg= acy default" into the n2n client configuration file. >>> >>> I have raised a bug on this https://bugzilla.ipfire.org/show_bug.cgi?id= =3D13137 and will submit a patch as soon as feasible. >>> >>> Regards, >>> >>> Adolf. >>> >>> >>> On 31/05/2023 17:07, Adolf Belka wrote: >>>> Hi All, >>>> >>>> I have a blocking bug. >>>> >>>> On 29/05/2023 23:34, Adolf Belka wrote: >>>>> >>>>> >>>>> On 26/05/2023 16:28, Michael Tremer wrote: >>>>>> Thank you very much for letting me know. I wasn=E2=80=99t aware at all. >>>>>> >>>>>> I reverted those changes in next and if the build goes through I will = merge the branch back into master again. >>>>> >>>>> Just as a reminder the reversion changes went through on next but are n= ot yet reverted in master. This needs to be done before CU175 is released oth= erwise n2n connections will fail to work properly. >>>>> >>>> The reversions have been applied to master (Core Update 175) and I did a= n update but have found that the n2n connection when the end that had the cli= ent upload has stopped working. This is definitely not because of bug#11048 a= s all of that has been reverted (confirmed by looking at the ovpnmain.cgi fil= e) >>>> >>>> I have realised that what is happening is the same as for the insecure r= oadwarrior certificate that was created with openssl-1.1.1x would not work wi= th openssl-3.x. I fixed that with the addition of the legacy option into the = openssl command for that client package download. >>>> >>>> The same thing is happening with the n2n connection. I will find the com= mand that access the .p12 file in the zip package and add the legacy option t= o that. Presuming it works I will raise and submit a patch to fix it. >>>> >>>> I will also raise a bug for it and assign myself to it. >>>> >>>> Regards, >>>> >>>> Adolf. >>>> >>>>> Regards, >>>>> Adolf. >>>>> >>>>>> >>>>>> -Michael >>>>>> >>>>>>> On 26 May 2023, at 14:33, Adolf Belka wrot= e: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On 24/05/2023 11:02, Michael Tremer wrote: >>>>>>>> Hello, >>>>>>>>> On 24 May 2023, at 09:47, Adolf Belka wr= ote: >>>>>>>>> >>>>>>>>> Hi Michael, >>>>>>>>> >>>>>>>>> On 24/05/2023 10:07, Michael Tremer wrote: >>>>>>>>>> It looks like we might not want to release the forthcoming Core Up= date before this. >>>>>>>>>> >>>>>>>>>> I did not hear any rumours about what might be the issue, but I wo= uld say that it wouldn=E2=80=99t hurt us to wait. >>>>>>>>>> >>>>>>>>>> What other outstanding issues do we have that are currently blocki= ng the update? >>>>>>>>>> >>>>>>>>> The fix for Bug#13117 has been merged into master so that is no lon= ger blocking. >>>>>>>>> >>>>>>>>> As mentioned to Peter, I recommend reverting my fix for Bug#11048 a= s some issues were found by myself (missed in my own testing) plus from other= testers reporting in the forum. I am making progress on this but there are s= till some bits outstanding. The bug has been around for a long time so it won= 't hurt for it to wait till Core Update 176. >>>>>>>> Okay. Let=E2=80=99s rather have the right fix than a quick one. I ag= ree! >>>>>>> The reversion of the update.sh script was done two days ago but there= are 4 other commits for the same bug fix that also need to be reverted. >>>>>>> >>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D762c88ec4d8= 5e3a4f7265b887f054cbe7703eb7c >>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D82822934ba7= 69bca4235cd2a02f848cdc8511120 >>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D070abb0d011= ff71e5aefd170dcb366d81bdf2497 >>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D18bece0edbd= 817933f48fdbffcffffd074e42c05 >>>>>>> >>>>>>> just to make sure that those don't get missed. >>>>>>> >>>>>>> Regards, >>>>>>> Adolf. >>>>>>>>> I haven't found anything else that was a problem and I haven't seen= any other issues mentioned in the forum that look to be caused by CU175. >>>>>>>> That sounds good then! >>>>>>>>> Regards, >>>>>>>>> Adolf. >>>>>>>>>> -Michael >>>>>>>>>> >>>>>>>>>>> Begin forwarded message: >>>>>>>>>>> >>>>>>>>>>> From: Tomas Mraz >>>>>>>>>>> Subject: Forthcoming OpenSSL Releases >>>>>>>>>>> Date: 24 May 2023 at 05:06:12 BST >>>>>>>>>>> To: "openssl-project(a)openssl.org" , "openssl-users(a)openssl.org" , openssl-anno= unce(a)openssl.org >>>>>>>>>>> Reply-To: openssl-users(a)openssl.org >>>>>>>>>>> >>>>>>>>>>> The OpenSSL project team would like to announce the forthcoming r= elease >>>>>>>>>>> of OpenSSL versions 3.0.9, 1.1.1u and 1.0.2zh. Note that OpenSSL = 1.0.2 >>>>>>>>>>> is End Of Life and so 1.0.2zh will be available to premium support >>>>>>>>>>> customers only. >>>>>>>>>>> >>>>>>>>>>> These releases will be made available on Tuesday 30th May 2023 >>>>>>>>>>> between 1300-1700 UTC. >>>>>>>>>>> >>>>>>>>>>> These are security-fix releases. The highest severity issue fixed= in >>>>>>>>>>> each of these three releases is Moderate: >>>>>>>>>>> >>>>>>>>>>> https://www.openssl.org/policies/secpolicy.html >>>>>>>>>>> >>>>>>>>>>> Yours >>>>>>>>>>> The OpenSSL Project Team >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> --=20 >>>>>>>>> Sent from my laptop >>>>>> >>>>>> >> --===============7170087306099390772==--