From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: development@lists.ipfire.org Subject: Re: Forthcoming OpenSSL Releases (new blocking bug from openssl-3.x) Date: Tue, 06 Jun 2023 20:58:00 +0000 Message-ID: In-Reply-To: <00ac42fecff159f70954fa4c7a3e830626d97b4e.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2163717503881269662==" List-Id: --===============2163717503881269662== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Adolf, hello Michael, thank you very much for verifying the OpenVPN functionality for PKCS12 contai= ners imported from IPFire systems running OpenSSL 1.1.1x. As discussed yesterday, I tested the same functionality for IPsec, both for N= 2N and roadwarrior connections. For both cases, an IPFire installtion running Core-Update 175 De= velopment Build master/3d2beee7 was able to import PKCS12 containers created on an IPFire ins= tallation running Core Update 174 without any error message whatsoever, and the IPsec connectio= ns could be established afterwards. As far as I am aware, all blocking issues with Core Update 175 are now resolv= ed, and this update can finally be released! @Michael, a draft for its release announcemen= t should be with you already. To echo Erik, many many thanks for all the hard work, and dealing with the ma= ssive 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, >> >> 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. >>> >>> I just created a page to explain this problem: >>> >>> https://wiki.ipfire.org/configuration/services/openvpn/openssl-3-transiti= on >>> >>> 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=3D762c= 88ec4d85e3a4f7265b887f054cbe7703eb7c >>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D8282= 2934ba769bca4235cd2a02f848cdc8511120 >>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D070a= bb0d011ff71e5aefd170dcb366d81bdf2497 >>>>>>>>>>>>>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommit;h=3D18be= ce0edbd817933f48fdbffcffffd074e42c05 >>>>>>>>>>>>>> >>>>>>>>>>>>>> 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 --===============2163717503881269662==--