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: Tue, 06 Jun 2023 17:23:09 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2612459029954640477==" List-Id: --===============2612459029954640477== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, I tested out a newly created openvpn connection on Openssl-3.x and=20 installed that on my laptop with the existing legacy providers lines in=20 the openssl.cnf file commented out. that connection was successfully made. So what we discussed is the case. Any new connection from CU175 onwards=20 will work with a system with OpenSSL-3.x It was what we hoped for and expected but it is good to have it confirmed. Regards, Adolf. On 06/06/2023 11:33, Michael Tremer wrote: > Thank you. >=20 > I just created a page to explain this problem: >=20 > https://wiki.ipfire.org/configuration/services/openvpn/openssl-3-transition >=20 > Please feel free to edit if I forgot to mention something. >=20 > We should include this in the change log for the release, but highlight tha= t this breaking change has not been introduced in c175, but c175 has the fix. >=20 > -Michael >=20 >> On 4 Jun 2023, at 20:14, Adolf Belka wrote: >> >> Hi All, >> >> I Have submitted a patch set for fixing the bug#13137 related to OpenVPN. = This patch set together with the one for bug#13138 related to IPSec that I sh= ipped 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.= :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= unique_subject is not explicitly defined as yes but it doesn't give any sugg= estion 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 opens= sl-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 messag= e 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 de= aling with .p12 files but this did not solve this problem. I then added -lega= cy to every openssl command. This solved the problem. >>>>> >>>> Someone else in that thread about the IPSec Root/Host certificate creati= on has suggested adding >>>> >>>> "unique_subject =3D yes" >>>> >>>> into /var/ipfire/certs/index.txt.attr >>>> >>>> have tried that and it does solve the problem. >>>> >>>> However now have the dilemma of which solution to use, the unique_subjec= t or the legacy option in the openssl commands. >>>> >>>> I have asked the person who suggested the unique_subject fix, why this i= s the correct fix to this problem. I searched on the internet but only found = comments that the default value of that variable is yes anyway and no referen= ce to it needing to be changed because of a changed from openssl-1.1.1x to op= enssl-3.x >>>> >>>> I will see what input the poster provides but does anyone on this mailin= g list 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 b= etween the two approaches or if both should be used? >>>> >>>> Regards, >>>> >>>> Adolf. >>>> >>>>> >>>>> I then tried only adding the legacy option to each non .p12 openssl com= mand 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 th= e openssl.cnf file. Tried this but it didn't solve the error message when cre= ating the Root/Host IPSec certificate set. So there must be some sort of diff= erence 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 op= enssl commands have the legacy option added. >>>>> >>>>> >>>>> The same will be done for the ovpnmain.cgi file to be on the safe side.= Currently 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 opens= sl-3.x and that worked successfully but I think having the legacy option on e= very openssl command should not cause anything to break. >>>>> >>>>> >>>>> Hope to provide a patch set for the various IPSec/OpenVPN openssl issue= s found over the weekend, presuming no one finds any further issues. As Micha= el has said in the past. Better to get any patch fix correct than to have a f= aulty 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 tha= t suspicion. >>>>>> 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 clie= nt n2n 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 t= he better approach as then any certificates would be covered by the legacy ap= proach 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 wro= te: >>>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> I have figured out how to solve the problem. I have to add "provider= s legacy 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 a= t 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 not yet reverted in master. This needs to be done before CU175 is release= d otherwise 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 th= e client upload has stopped working. This is definitely not because of bug#11= 048 as all of that has been reverted (confirmed by looking at the ovpnmain.cg= i file) >>>>>>>>> >>>>>>>>> I have realised that what is happening is the same as for the insec= ure roadwarrior certificate that was created with openssl-1.1.1x would not wo= rk with 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 th= e command that access the .p12 file in the zip package and add the legacy opt= ion 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 = wrote: >>>>>>>>>>>> >>>>>>>>>>>> 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 Co= re 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 b= locking the update? >>>>>>>>>>>>>>> >>>>>>>>>>>>>> The fix for Bug#13117 has been merged into master so that is n= o longer blocking. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As mentioned to Peter, I recommend reverting my fix for Bug#11= 048 as 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 still some bits outstanding. The bug has been around for a long time so i= t 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 = 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=3D762c88= ec4d85e3a4f7265b887f054cbe7703eb7c >>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D828229= 34ba769bca4235cd2a02f848cdc8511120 >>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D070abb= 0d011ff71e5aefd170dcb366d81bdf2497 >>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D18bece= 0edbd817933f48fdbffcffffd074e42c05 >>>>>>>>>>>> >>>>>>>>>>>> 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= -announce(a)openssl.org >>>>>>>>>>>>>>>> Reply-To: openssl-users(a)openssl.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The OpenSSL project team would like to announce the forthcom= ing release >>>>>>>>>>>>>>>> of OpenSSL versions 3.0.9, 1.1.1u and 1.0.2zh. Note that Ope= nSSL 1.0.2 >>>>>>>>>>>>>>>> is End Of Life and so 1.0.2zh will be available to premium s= upport >>>>>>>>>>>>>>>> customers only. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> These releases will be made available on Tuesday 30th May 20= 23 >>>>>>>>>>>>>>>> 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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >=20 --=20 Sent from my laptop --===============2612459029954640477==--