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: Wed, 07 Jun 2023 09:50:46 +0100 Message-ID: <5629CE53-62A8-4090-9835-EAC5586AFE1F@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7339606547083177324==" List-Id: --===============7339606547083177324== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 6 Jun 2023, at 22:51, Adolf Belka wrote: >=20 > Hi Peter, >=20 > On 06/06/2023 22:58, Peter M=C3=BCller wrote: >> Hello Adolf, >> hello Michael, >> thank you very much for verifying the OpenVPN functionality for PKCS12 con= tainers imported >> from IPFire systems running OpenSSL 1.1.1x. >> As discussed yesterday, I tested the same functionality for IPsec, both fo= r 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 = installation running >> Core Update 174 without any error message whatsoever, and the IPsec connec= tions could be established >> afterwards. >> As far as I am aware, all blocking issues with Core Update 175 are now res= olved, and this >> update can finally be released! @Michael, a draft for its release announce= ment should be with >> you already. >=20 > I am afraid there is still some more work I am involved in. I realised that= we did not have the providers legacy default line in the roadwarrior client = configs. After a discussion with Michael, we also decide that we don't want e= verything to be running legacy, otherwise it will stay like that for ever. >=20 > So I am working on some patches that will identify the connection certifica= tes that were created with openssl-1.1.1x and those with openssl-3.x and this= will be stored as a key for each connection. Then when using any of the open= ssl pkcs12 commands, those that are uploading existing certificates will use = -legacy if the key is openssl-1.1.1x and not for the openssl-3.x > If -legacy is used then providers legacy default will be added to the end o= f the .ovpn profile file. You don=E2=80=99t need to store this in the CSV file. You can simply create a new function in the CGI file that takes the path of t= he p12 file and runs the command with it: openssl pkcs12 -info -nodes -in file.p12 -passin pass: -noout You will then need to parse the output and if you find =E2=80=9CMAC: sha1=E2= =80=9D at the beginning of any line (might be worth breaking the loop after t= he first iteration still) then you will return True, otherwise False. Then you can just call the function when you need to know whether this is a l= egacy certificate. It=E2=80=99s not super fast when iterating over hundreds of connections, but = we currently only need this when exporting the ZIP file which does not create= that much extra overhead. > For the openssl pkcs12 command that is creating a new connection certificat= e, it will always not use -legacy so that any new certificates that are creat= ed will always be the newer ones. If you use -legacy with the pkcs12 creation= command then the version will be the same as was created with openssl-1.1.1x= even though openssl-3.x is running on IPFire. >=20 > When existing connection certificates expire (default is 760 days) then whe= n a new connection certificate is created it will also always be the openssl-= 3.x version. >=20 > Over time the old openssl-1.1.1x certificates will disappear. >=20 > I will also look at doing the same thing with the net2net connection certif= icates so only old ones imported will have the providers legacy default added= at the end of the n2nconf file. You can use the same function as above, as it does not care whether the PKCS1= 2 file belongs to a RW or N2N connection. > The patches I will supply will be based on the nightly build from last nigh= t so none of my existing patches need to be reverted. >=20 > I will also go back and modify the backup.pl restore function so that it al= so checks the openssl generation of all the connection certs and where requir= ed adds the providers legacy default to the .ovpn config. If you use the function, you can skip that step I believe. > I am working to get it done as soon as possible. -Michael >=20 > Regards, >=20 > 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! >> All the best, >> Peter M=C3=BCller >>> True, >>> thanks to all for this. >>>=20 >>> Best, >>>=20 >>> Erik >>>=20 >>> Am Dienstag, dem 06.06.2023 um 17:23 +0200 schrieb Adolf Belka: >>>> Hi Michael, >>>>=20 >>>> 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. >>>>=20 >>>> So what we discussed is the case. Any new connection from CU175 >>>> onwards >>>> will work with a system with OpenSSL-3.x >>>>=20 >>>> It was what we hoped for and expected but it is good to have it >>>> confirmed. >>>>=20 >>>> Regards, >>>>=20 >>>> Adolf. >>>>=20 >>>> 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-transi= tion >>>>>=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 that 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: >>>>>>=20 >>>>>> Hi All, >>>>>>=20 >>>>>> 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. >>>>>>=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 suggestion 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 openssl-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 trying 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 that it did not happen in CU174. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>> Someone else in that thread about the IPSec Root/Host >>>>>>>> certificate creation 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 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 >>>>>>>>=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 between >>>>>>>> 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 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. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> So I will also submit a patch set for the vpnmain.cgi file >>>>>>>>> where all openssl 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 openssl-3.x and that worked successfully but I >>>>>>>>> think having the legacy option on every 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 Michael has said in the past. >>>>>>>>> Better to get any patch fix correct than to have a faulty >>>>>>>>> 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 client n2n conf file >>>>>>>>>> made everything work again. >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> Regards, >>>>>>>>>> Adolf. >>>>>>>>>>>=20 >>>>>>>>>>> I will halt the update for now and let=E2=80=99s take some more >>>>>>>>>>> time to figure this one out. >>>>>>>>>>>=20 >>>>>>>>>>> Best, >>>>>>>>>>> -Michael >>>>>>>>>>>=20 >>>>>>>>>>>> On 31 May 2023, at 19:42, Adolf Belka >>>>>>>>>>>> wrote: >>>>>>>>>>>>=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 will merge the branch back >>>>>>>>>>>>>>> into master again. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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) >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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. >>>>>>>>>>>>>=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 >>>>>>>>>>>>> option 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 Core 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 blocking 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#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. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D76= 2c88ec4d85e3a4f7265b887f054cbe7703eb7c >>>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D82= 822934ba769bca4235cd2a02f848cdc8511120 >>>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D07= 0abb0d011ff71e5aefd170dcb366d81bdf2497 >>>>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D18= bece0edbd817933f48fdbffcffffd074e42c05 >>>>>>>>>>>>>>>>=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 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. >>>>>>>>>>>>>>>>>>>>=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 fixed 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 >>>>>=20 >>>>=20 >>>=20 >=20 > --=20 > Sent from my laptop --===============7339606547083177324==--