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 21:28:39 +0200 Message-ID: <1b64e561-aa70-2377-5b4b-2925ebc4fbdb@ipfire.org> In-Reply-To: <9f20248d-6ce4-21fe-894c-b87fffef98ad@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5543561366588072197==" List-Id: --===============5543561366588072197== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi All, On 02/06/2023 19:54, Adolf Belka wrote: > 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 tryi= ng to create a Root/Host certificate set for IPSec causes an error message to= be created. > > I reproduced this on CU175 Testing build master/9797af30 and confirmed that= it did not happen in CU174. > > > I added the -legacy option into every openssl command in vpnmain.cgi dealin= g with .p12 files but this did not solve this problem. I then added -legacy t= o every openssl command. This solved the problem. > Someone else in that thread about the IPSec Root/Host certificate creation ha= s suggested adding "unique_subject =3D yes" into /var/ipfire/certs/index.txt.attr =C2=A0have tried that and it does solve the problem. However now have the dilemma of which solution to use, the unique_subject or = the legacy option in the openssl commands. I have asked the person who suggested the unique_subject fix, why this is the= correct fix to this problem. I searched on the internet but only found comme= nts that the default value of that variable is yes anyway and no reference to= it needing to be changed because of a changed from openssl-1.1.1x to openssl= -3.x I will see what input the poster provides but does anyone on this mailing lis= t have any suggestion as to how the unique_subject =3D yes fix works and why = it is needed with openssl-3.x or any input on how to make the decision betwee= n the two approaches or if both should be used? Regards, Adolf. > > I then tried only adding the legacy option to each non .p12 openssl command= one at a time but this also did not fix the problem. So more than one of the= non .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= the same effect should be possible by adding the legacy provider into the op= enssl.cnf file. Tried this but it didn't solve the error message when creatin= g the Root/Host IPSec certificate set. So there must be some sort of differen= ce between the command line legacy option and the legacy provider option in t= he openssl.cnf file. > > > So I will also submit a patch set for the vpnmain.cgi file where all openss= l commands have the legacy option added. > > > The same will be done for the ovpnmain.cgi file to be on the safe side. Cur= rently 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= openssl command should not cause anything to break. > > > Hope to provide a patch set for the various IPSec/OpenVPN openssl issues fo= und over the weekend, presuming no one finds any further issues. As Michael h= as said in the past. Better to get any patch fix correct than to have a fault= y 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 su= spicion. >> I believe that is the case. The failure I found has no openssl command in = the cgi file and adding "providers legacy default" to the end of the client n= 2n conf file made everything work again. >> >> Your idea of making a modification to the openssl conf file is a good one = and I will try that out and see if that works. If so then that would be the b= etter approach as then any certificates would be covered by the legacy approa= ch if required. >> >> Regards, >> Adolf. >>> >>> I will halt the update for now and let=E2=80=99s take some more time to f= igure 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 le= gacy 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 al= l. >>>>>>> >>>>>>> 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 = not yet reverted in master. This needs to be done before CU175 is released ot= herwise n2n connections will fail to work properly. >>>>>> >>>>> The reversions have been applied to master (Core Update 175) and I did = an update but have found that the n2n connection when the end that had the cl= ient upload has stopped working. This is definitely not because of bug#11048 = as all of that has been reverted (confirmed by looking at the ovpnmain.cgi fi= le) >>>>> >>>>> I have realised that what is happening is the same as for the insecure = roadwarrior certificate that was created with openssl-1.1.1x would not work w= ith 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 co= mmand that access the .p12 file in the zip package and add the legacy option = to 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 wro= te: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> On 24/05/2023 11:02, Michael Tremer wrote: >>>>>>>>> Hello, >>>>>>>>>> On 24 May 2023, at 09:47, Adolf Belka w= rote: >>>>>>>>>> >>>>>>>>>> Hi Michael, >>>>>>>>>> >>>>>>>>>> On 24/05/2023 10:07, Michael Tremer wrote: >>>>>>>>>>> It looks like we might not want to release the forthcoming Core U= pdate before this. >>>>>>>>>>> >>>>>>>>>>> I did not hear any rumours about what might be the issue, but I w= ould say that it wouldn=E2=80=99t hurt us to wait. >>>>>>>>>>> >>>>>>>>>>> What other outstanding issues do we have that are currently block= ing the update? >>>>>>>>>>> >>>>>>>>>> The fix for Bug#13117 has been merged into master so that is no lo= nger blocking. >>>>>>>>>> >>>>>>>>>> As mentioned to Peter, I recommend reverting my fix for Bug#11048 = as some issues were found by myself (missed in my own testing) plus from othe= r testers reporting in the forum. I am making progress on this but there are = still some bits outstanding. The bug has been around for a long time so it wo= n'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 a= gree! >>>>>>>> The reversion of the update.sh script was done two days ago but ther= e 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=3D762c88ec4d= 85e3a4f7265b887f054cbe7703eb7c >>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D82822934ba= 769bca4235cd2a02f848cdc8511120 >>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D070abb0d01= 1ff71e5aefd170dcb366d81bdf2497 >>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D18bece0edb= d817933f48fdbffcffffd074e42c05 >>>>>>>> >>>>>>>> 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 see= n 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-ann= ounce(a)openssl.org >>>>>>>>>>>> Reply-To: openssl-users(a)openssl.org >>>>>>>>>>>> >>>>>>>>>>>> The OpenSSL project team would like to announce the forthcoming = release >>>>>>>>>>>> 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 suppo= rt >>>>>>>>>>>> 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 fixe= d 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 >>>>>>> >>>>>>> >>> --===============5543561366588072197==--