From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Forthcoming OpenSSL Releases (new blocking bug from openssl-3.x) Date: Tue, 06 Jun 2023 10:33:08 +0100 Message-ID: In-Reply-To: <15da4fe3-a701-28ad-089f-beecdf954b1f@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============6190519697282438947==" List-Id: --===============6190519697282438947== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thank you. I just created a page to explain this problem: https://wiki.ipfire.org/configuration/services/openvpn/openssl-3-transition Please feel free to edit if I forgot to mention something. We should include this in the change log for the release, but highlight that = this breaking change has not been introduced in c175, but c175 has the fix. -Michael > On 4 Jun 2023, at 20:14, Adolf Belka wrote: >=20 > Hi All, >=20 > I Have submitted a patch set for fixing the bug#13137 related to OpenVPN. T= his patch set together with the one for bug#13138 related to IPSec that I shi= pped yesterday fix the major bugs I found for CU175. >=20 > Sorry it took a bit longer than I had hoped for. >=20 > Please let me know if there are any problems with what I have produced and = I will work to sort them out. >=20 > I am not aware of any other blocking bugs for CU175 at this point in time. = :crossed_fingers: >=20 >=20 > Regards, >=20 > Adolf. >=20 >=20 > On 02/06/2023 21:35, Adolf Belka wrote: >> The poster found the following reference >>=20 >> https://serverfault.com/questions/857131/odd-error-while-using-openssl >>=20 >> 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 sugge= stion for why this would have occurred with the move to openssl-3.x >>=20 >>=20 >> Regards, >>=20 >> Adolf. >>=20 >>=20 >> On 02/06/2023 21:28, Adolf Belka wrote: >>> Hi All, >>>=20 >>> On 02/06/2023 19:54, Adolf Belka wrote: >>>> Hi All, >>>>=20 >>>> Just when you thought it was safe to get back in the water - aaaaah. >>>>=20 >>>>=20 >>>> I suspected that IPSec would also suffer from the same problem of openss= l-3.x vs openssl-1.1.1x for the opening of .p12 certificates. >>>>=20 >>>> Today, from feedback from Roberto Pena in the forum, it turns out that t= rying to create a Root/Host certificate set for IPSec causes an error message= to be created. >>>>=20 >>>> I reproduced this on CU175 Testing build master/9797af30 and confirmed t= hat it did not happen in CU174. >>>>=20 >>>>=20 >>>> I added the -legacy option into every openssl command in vpnmain.cgi dea= ling with .p12 files but this did not solve this problem. I then added -legac= y to every openssl command. This solved the problem. >>>>=20 >>> Someone else in that thread about the IPSec Root/Host certificate creatio= n has suggested adding >>>=20 >>> "unique_subject =3D yes" >>>=20 >>> into /var/ipfire/certs/index.txt.attr >>>=20 >>> have tried that and it does solve the problem. >>>=20 >>> However now have the dilemma of which solution to use, the unique_subject= or the legacy option in the openssl commands. >>>=20 >>> 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 c= omments that the default value of that variable is yes anyway and no referenc= e to it needing to be changed because of a changed from openssl-1.1.1x to ope= nssl-3.x >>>=20 >>> 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 = why it is needed with openssl-3.x or any input on how to make the decision be= tween the two approaches or if both should be used? >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>>>=20 >>>> I then tried only adding the legacy option to each non .p12 openssl comm= and 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. >>>>=20 >>>> I thought if every openssl command was going to have the legacy option t= hen 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 crea= ting the Root/Host IPSec certificate set. So there must be some sort of diffe= rence between the command line legacy option and the legacy provider option i= n the openssl.cnf file. >>>>=20 >>>>=20 >>>> So I will also submit a patch set for the vpnmain.cgi file where all ope= nssl commands have the legacy option added. >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>> I did test creating the Root/Host certificate set on OpenVPN with openss= l-3.x and that worked successfully but I think having the legacy option on ev= ery openssl command should not cause anything to break. >>>>=20 >>>>=20 >>>> 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 Michae= l has said in the past. Better to get any patch fix correct than to have a fa= ulty one quickly. >>>>=20 >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 >>>>=20 >>>> On 31/05/2023 20:53, Adolf Belka wrote: >>>>> Hi Michael, >>>>>=20 >>>>> On 31/05/2023 20:43, Michael Tremer wrote: >>>>>> Hello, >>>>>>=20 >>>>>> 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 = in the cgi file and adding "providers legacy default" to the end of the clien= t n2n conf file made everything work again. >>>>>=20 >>>>> Your idea of making a modification to the openssl conf file is a good o= ne and I will try that out and see if that works. If so then that would be th= e better approach as then any certificates would be covered by the legacy app= roach if required. >>>>>=20 >>>>> Regards, >>>>> Adolf. >>>>>>=20 >>>>>> I will halt the update for now and let=E2=80=99s take some more time t= o figure this one out. >>>>>>=20 >>>>>> Best, >>>>>> -Michael >>>>>>=20 >>>>>>> On 31 May 2023, at 19:42, Adolf Belka wrot= e: >>>>>>>=20 >>>>>>> Hi All, >>>>>>>=20 >>>>>>> I have figured out how to solve the problem. I have to add "providers= legacy default" into the n2n client configuration file. >>>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> Regards, >>>>>>>=20 >>>>>>> Adolf. >>>>>>>=20 >>>>>>>=20 >>>>>>> On 31/05/2023 17:07, Adolf Belka wrote: >>>>>>>> Hi All, >>>>>>>>=20 >>>>>>>> I have a blocking bug. >>>>>>>>=20 >>>>>>>> On 29/05/2023 23:34, Adolf Belka wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> I reverted those changes in next and if the build goes through I w= ill merge the branch back into master again. >>>>>>>>>=20 >>>>>>>>> Just as a reminder the reversion changes went through on next but a= re not yet reverted in master. This needs to be done before CU175 is released= otherwise n2n connections will fail to work properly. >>>>>>>>>=20 >>>>>>>> The reversions have been applied to master (Core Update 175) and I d= id 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#110= 48 as all of that has been reverted (confirmed by looking at the ovpnmain.cgi= file) >>>>>>>>=20 >>>>>>>> I have realised that what is happening is the same as for the insecu= re roadwarrior certificate that was created with openssl-1.1.1x would not wor= k with openssl-3.x. I fixed that with the addition of the legacy option into = the openssl command for that client package download. >>>>>>>>=20 >>>>>>>> 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 opti= on to that. Presuming it works I will raise and submit a patch to fix it. >>>>>>>>=20 >>>>>>>> I will also raise a bug for it and assign myself to it. >>>>>>>>=20 >>>>>>>> Regards, >>>>>>>>=20 >>>>>>>> Adolf. >>>>>>>>=20 >>>>>>>>> Regards, >>>>>>>>> Adolf. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -Michael >>>>>>>>>>=20 >>>>>>>>>>> On 26 May 2023, at 14:33, Adolf Belka = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Hi, >>>>>>>>>>>=20 >>>>>>>>>>> On 24/05/2023 11:02, Michael Tremer wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>>> On 24 May 2023, at 09:47, Adolf Belka wrote: >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Hi Michael, >>>>>>>>>>>>>=20 >>>>>>>>>>>>> On 24/05/2023 10:07, Michael Tremer wrote: >>>>>>>>>>>>>> It looks like we might not want to release the forthcoming Cor= e Update before this. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> What other outstanding issues do we have that are currently bl= ocking the update? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>> The fix for Bug#13117 has been merged into master so that is no= longer blocking. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> As mentioned to Peter, I recommend reverting my fix for Bug#110= 48 as some issues were found by myself (missed in my own testing) plus from o= ther testers reporting in the forum. I am making progress on this but there a= re 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 t= here are 4 other commits for the same bug fix that also need to be reverted. >>>>>>>>>>>=20 >>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D762c88e= c4d85e3a4f7265b887f054cbe7703eb7c >>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D8282293= 4ba769bca4235cd2a02f848cdc8511120 >>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D070abb0= d011ff71e5aefd170dcb366d81bdf2497 >>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D18bece0= edbd817933f48fdbffcffffd074e42c05 >>>>>>>>>>>=20 >>>>>>>>>>> just to make sure that those don't get missed. >>>>>>>>>>>=20 >>>>>>>>>>> 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 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> The OpenSSL project team would like to announce the forthcomi= ng release >>>>>>>>>>>>>>> of OpenSSL versions 3.0.9, 1.1.1u and 1.0.2zh. Note that Open= SSL 1.0.2 >>>>>>>>>>>>>>> is End Of Life and so 1.0.2zh will be available to premium su= pport >>>>>>>>>>>>>>> customers only. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> These releases will be made available on Tuesday 30th May 2023 >>>>>>>>>>>>>>> between 1300-1700 UTC. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> These are security-fix releases. The highest severity issue f= ixed in >>>>>>>>>>>>>>> each of these three releases is Moderate: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> https://www.openssl.org/policies/secpolicy.html >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Yours >>>>>>>>>>>>>>> The OpenSSL Project Team >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>=20 >>>>>>>>>>>>> --=20 >>>>>>>>>>>>> Sent from my laptop >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>=20 --===============6190519697282438947==--