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 23:51:48 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7483361777643561182==" List-Id: --===============7483361777643561182== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Peter, On 06/06/2023 22:58, Peter M=C3=BCller wrote: > Hello Adolf, > hello Michael, >=20 > thank you very much for verifying the OpenVPN functionality for PKCS12 cont= ainers imported > from IPFire systems running OpenSSL 1.1.1x. >=20 > As discussed yesterday, I tested the same functionality for IPsec, both for= N2N and roadwarrior > connections. For both cases, an IPFire installtion running Core-Update 175 = Development Build > master/3d2beee7 was able to import PKCS12 containers created on an IPFire i= nstallation running > Core Update 174 without any error message whatsoever, and the IPsec connect= ions could be established > afterwards. >=20 > As far as I am aware, all blocking issues with Core Update 175 are now reso= lved, and this > update can finally be released! @Michael, a draft for its release announcem= ent should be with > you already. I am afraid there is still some more work I am involved in. I realised=20 that we did not have the providers legacy default line in the=20 roadwarrior client configs. After a discussion with Michael, we also=20 decide that we don't want everything to be running legacy, otherwise it=20 will stay like that for ever. So I am working on some patches that will identify the connection=20 certificates that were created with openssl-1.1.1x and those with=20 openssl-3.x and this will be stored as a key for each connection. Then=20 when using any of the openssl pkcs12 commands, those that are uploading=20 existing certificates will use -legacy if the key is openssl-1.1.1x and=20 not for the openssl-3.x If -legacy is used then providers legacy default will be added to the=20 end of the .ovpn profile file. For the openssl pkcs12 command that is creating a new connection=20 certificate, it will always not use -legacy so that any new certificates=20 that are created will always be the newer ones. If you use -legacy with=20 the pkcs12 creation command then the version will be the same as was=20 created with openssl-1.1.1x even though openssl-3.x is running on IPFire. When existing connection certificates expire (default is 760 days) then=20 when a new connection certificate is created it will also always be the=20 openssl-3.x version. Over time the old openssl-1.1.1x certificates will disappear. I will also look at doing the same thing with the net2net connection=20 certificates so only old ones imported will have the providers legacy=20 default added at the end of the n2nconf file. The patches I will supply will be based on the nightly build from last=20 night so none of my existing patches need to be reverted. I will also go back and modify the backup.pl restore function so that it=20 also checks the openssl generation of all the connection certs and where=20 required adds the providers legacy default to the .ovpn config. I am working to get it done as soon as possible. Regards, Adolf. >=20 > To echo Erik, many many thanks for all the hard work, and dealing with the = massive headache > the transition to OpenSSL 3.x has induced! >=20 > All the best, > Peter M=C3=BCller >=20 >> True, >> thanks to all for this. >> >> Best, >> >> Erik >> >> Am Dienstag, dem 06.06.2023 um 17:23 +0200 schrieb Adolf Belka: >>> Hi Michael, >>> >>> I tested out a newly created openvpn connection on Openssl-3.x and >>> installed that on my laptop with the existing legacy providers lines >>> in >>> the openssl.cnf file commented out. that connection was successfully >>> made. >>> >>> So what we discussed is the case. Any new connection from CU175 >>> onwards >>> 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. >>>> >>>> I just created a page to explain this problem: >>>> >>>> https://wiki.ipfire.org/configuration/services/openvpn/openssl-3-transit= ion >>>> >>>> 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: >>>>> >>>>> 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 shipped 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 unique_subject is not explicitly defined as yes but >>>>>> it doesn't give any suggestion 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 trying 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 dealing 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=A0 have 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 comments 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 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 between >>>>>>> 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 openssl.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. 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 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 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 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 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 client 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 the better approach >>>>>>>>> as then any certificates would be covered by the legacy >>>>>>>>> approach 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?id=3D13137=C2=A0and >>>>>>>>>>> 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 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 did 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#11048 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 insecure 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 the 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 >>>>>>>>>>>> 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 >>>>>>>>>>>>>>> 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 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 blocking 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#11048 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 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 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=3D762= c88ec4d85e3a4f7265b887f054cbe7703eb7c >>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D828= 22934ba769bca4235cd2a02f848cdc8511120 >>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D070= abb0d011ff71e5aefd170dcb366d81bdf2497 >>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D18b= ece0edbd817933f48fdbffcffffd074e42c05 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 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 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>> >>>> >>> >> --=20 Sent from my laptop --===============7483361777643561182==--