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: Sun, 04 Jun 2023 21:14:12 +0200 Message-ID: <15da4fe3-a701-28ad-089f-beecdf954b1f@ipfire.org> In-Reply-To: <2522bf18-d511-e94e-19fd-01e5d0413de3@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8801750563921601848==" List-Id: --===============8801750563921601848== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi All, I Have submitted a patch set for fixing the bug#13137 related to OpenVPN. Thi= s patch set together with the one for bug#13138 related to IPSec that I shipp= ed yesterday fix the major bugs I found for CU175. Sorry it took a bit longer than I had hoped for. Please let me know if there are any problems with what I have produced and I = will work to sort them out. I am not aware of any other blocking bugs for CU175 at this point in time.=C2= =A0 :crossed_fingers: Regards, Adolf. On 02/06/2023 21:35, Adolf Belka wrote: > The poster found the following reference > > https://serverfault.com/questions/857131/odd-error-while-using-openssl > > which suggests that openssl can sometimes give spurious error messages if u= nique_subject is not explicitly defined as yes but it doesn't give any sugges= tion for why this would have occurred with the move to openssl-3.x > > > Regards, > > Adolf. > > > On 02/06/2023 21:28, Adolf Belka wrote: >> 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 tr= ying 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 th= at it did not happen in CU174. >>> >>> >>> I added the -legacy option into every openssl command in vpnmain.cgi deal= ing with .p12 files but this did not solve this problem. I then added -legacy= to every openssl command. This solved the problem. >>> >> Someone else in that thread about the IPSec Root/Host certificate creation= has 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 co= mments 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 open= ssl-3.x >> >> I will see what input the poster provides but does anyone on this mailing = list have any suggestion as to how the unique_subject =3D yes fix works and w= hy it is needed with openssl-3.x or any input on how to make the decision bet= ween the two approaches or if both should be used? >> >> Regards, >> >> Adolf. >> >>> >>> I then tried only adding the legacy option to each non .p12 openssl comma= nd one at a time but this also did not fix the problem. So more than one of t= he 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 th= en the same effect should be possible by adding the legacy provider into the = openssl.cnf file. Tried this but it didn't solve the error message when creat= ing the Root/Host IPSec certificate set. So there must be some sort of differ= ence 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 open= ssl commands have the legacy option added. >>> >>> >>> The same will be done for the ovpnmain.cgi file to be on the safe side. C= urrently 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 eve= ry openssl command should not cause anything to break. >>> >>> >>> Hope to provide a patch set for the various IPSec/OpenVPN openssl issues = found 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 fau= lty 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 = suspicion. >>>> I believe that is the case. The failure I found has no openssl command i= n the cgi file and adding "providers legacy default" to the end of the client= n2n conf file made everything work again. >>>> >>>> Your idea of making a modification to the openssl conf file is a good on= e and I will try that out and see if that works. If so then that would be the= better approach as then any certificates would be covered by the legacy appr= oach if required. >>>> >>>> Regards, >>>> Adolf. >>>>> >>>>> I will halt the update for now and let=E2=80=99s take some more time to= figure 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 = legacy default" into the n2n client configuration file. >>>>>> >>>>>> I have raised a bug on this https://bugzilla.ipfire.org/show_bug.cgi?i= d=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 wi= ll merge the branch back into master again. >>>>>>>> >>>>>>>> Just as a reminder the reversion changes went through on next but ar= e not yet reverted in master. This needs to be done before CU175 is released = otherwise n2n connections will fail to work properly. >>>>>>>> >>>>>>> The reversions have been applied to master (Core Update 175) and I di= d an update but have found that the n2n connection when the end that had the = client upload has stopped working. This is definitely not because of bug#1104= 8 as all of that has been reverted (confirmed by looking at the ovpnmain.cgi = file) >>>>>>> >>>>>>> I have realised that what is happening is the same as for the insecur= e roadwarrior certificate that was created with openssl-1.1.1x would not work= with openssl-3.x. I fixed that with the addition of the legacy option into t= he openssl command for that client package download. >>>>>>> >>>>>>> The same thing is happening with the n2n connection. I will find the = command that access the .p12 file in the zip package and add the legacy optio= n 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 w= rote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> On 24/05/2023 11:02, Michael Tremer wrote: >>>>>>>>>>> Hello, >>>>>>>>>>>> On 24 May 2023, at 09:47, Adolf Belka = wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi Michael, >>>>>>>>>>>> >>>>>>>>>>>> On 24/05/2023 10:07, Michael Tremer wrote: >>>>>>>>>>>>> It looks like we might not want to release the forthcoming Core= Update before this. >>>>>>>>>>>>> >>>>>>>>>>>>> I did not hear any rumours about what might be the issue, but I= would say that it wouldn=E2=80=99t hurt us to wait. >>>>>>>>>>>>> >>>>>>>>>>>>> What other outstanding issues do we have that are currently blo= cking the update? >>>>>>>>>>>>> >>>>>>>>>>>> The fix for Bug#13117 has been merged into master so that is no = longer blocking. >>>>>>>>>>>> >>>>>>>>>>>> As mentioned to Peter, I recommend reverting my fix for Bug#1104= 8 as some issues were found by myself (missed in my own testing) plus from ot= her testers reporting in the forum. I am making progress on this but there ar= e still 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= agree! >>>>>>>>>> The reversion of the update.sh script was done two days ago but th= ere 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=3D762c88ec= 4d85e3a4f7265b887f054cbe7703eb7c >>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D82822934= ba769bca4235cd2a02f848cdc8511120 >>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D070abb0d= 011ff71e5aefd170dcb366d81bdf2497 >>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D18bece0e= dbd817933f48fdbffcffffd074e42c05 >>>>>>>>>> >>>>>>>>>> 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 s= een 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-a= nnounce(a)openssl.org >>>>>>>>>>>>>> Reply-To: openssl-users(a)openssl.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> The OpenSSL project team would like to announce the forthcomin= g release >>>>>>>>>>>>>> of OpenSSL versions 3.0.9, 1.1.1u and 1.0.2zh. Note that OpenS= SL 1.0.2 >>>>>>>>>>>>>> is End Of Life and so 1.0.2zh will be available to premium sup= port >>>>>>>>>>>>>> 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 fi= xed 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 >>>>>>>>> >>>>>>>>> >>>>> --===============8801750563921601848==--