From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4ZLwlJ1f2Tz30ZL for ; Mon, 24 Mar 2025 14:43:08 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) client-signature RSA-PSS (4096 bits)) (Client CN "mail01.haj.ipfire.org", Issuer "R10" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4ZLwlD4Wmdz2yf1 for ; Mon, 24 Mar 2025 14:43:04 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4ZLwlC6WL4zjj; Mon, 24 Mar 2025 14:43:03 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1742827384; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p2CsV3056zmn1lL8AcZdxwlT/NGLV8b+lpxatRTV3Gw=; b=PyWUIN+gQ3pdR1DROuMcY3+camGsq416kdJOgKDVjDvLrojLvM3q2fLy7/ai537uCgVzah d3icVvm61rkcQzBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1742827384; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p2CsV3056zmn1lL8AcZdxwlT/NGLV8b+lpxatRTV3Gw=; b=GmESmvo8UQ8I2cSLH3dqT9pWp3/E4tutbHzEWiCyPMdt+KQbmvX4pycbGcCQPmAbsgDdq5 G/VMMcJKd4jjefW+SC0np5uMy+6SInhQxAjTrJemDVUiAQxGmnoJ/GpIpXOzLsC6YoWZIQ KisEfmfeVSnx123fNq/GZXVeam5b3P3AKqmGK5DKHDW0+0GdIf1I6Vuj4hVeKEa9nYiv47 8QKB+gY2fncWxiiUkIuW0YA0EsOSHSTqlQdOueA3YkKOjX53w55DtYb/yLNYhvtOLTAZtO 43Ychy49s6iZIiHIKlnhMcH+eSxeqMa1vl7oIgUol50Qgf4UtWfX3qFD8H2Xtw== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: List-Subscribe: , List-Unsubscribe: , List-Post: List-Help: Sender: Mail-Followup-To: Mime-Version: 1.0 Subject: Re: IPFire 2.29 - Core Update 193 is available for testing From: Michael Tremer In-Reply-To: Date: Mon, 24 Mar 2025 14:43:03 +0000 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <174238111584.1720815.10275774082881760962.ipfire@ipfire.org> <2c4d9fcd-6cde-4bcd-a65d-815d7d283dc4@ipfire.org> To: Adolf Belka Hello, If you have set the local/remote ID in the connection it has to be part = of the certificate which does not happen automatically in IPFire. If you didn=E2=80=99t set this, then NetworkManager was sending some = sort of ID. Is there a way to remove it from there imported = configuration? -Michael > On 24 Mar 2025, at 13:25, Adolf Belka wrote: >=20 > Hi Michael, >=20 > On 23/03/2025 13:09, Michael Tremer wrote: >> Hello, >>> On 22 Mar 2025, at 17:22, Adolf Belka = wrote: >>>=20 >>> Hi, >>>=20 >>> I have tested my fix for bug13737 and found that it works fine when = a new ipsec x509 root/host certificate set is created. >=20 > What I hadn't tested was checking if an existing working ipsec cert = connection still worked after doing the renew of the host cert. >=20 > I just did that test and the connection fails to connect. >=20 > Most of the connection elements are successful, such as the = negotiation of the ciphers etc but right at the end it comes up with the = message:- >=20 > Mar 24 13:41:33 laptop charon-nm[1439]: 05[IKE] received end entity = cert "C=3DNL, O=3DIPFire, CN=3Dipfire.domain.local" > Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] using certificate = "C=3DNL, O=3DIPFire, CN=3Dipfire.domain.local" > Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] using trusted ca = certificate "C=3DNL, L=3DHague, O=3DIPFire, CN=3DIPFire CA, = E=3Droot@ipfire.domain.local" > Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] reached self-signed = root ca with a path length of 0 > Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] checking certificate = status of "C=3DNL, O=3DIPFire, CN=3Dipfire.domain.local" > Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] certificate status is = not available > Mar 24 13:41:33 laptop charon-nm[1439]: 05[IKE] authentication of = 'C=3DNL, O=3DIPFire, CN=3Dipfire.domain.local' with = RSA_EMSA_PKCS1_SHA2_384 successful > Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] constraint check = failed: certificate does not confirm identity 'ipfire.domain.local' = (ID_FQDN) > Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] selected peer config = 'laptop ipsec cert to ipfire 2' unacceptable: constraint checking failed > Mar 24 13:41:33 laptop charon-nm[1439]: 05[CFG] no alternative config = found > Mar 24 13:41:33 laptop charon-nm[1439]: 05[ENC] generating = INFORMATIONAL request 2 [ N(AUTH_FAILED) ] >=20 > When the host cert renew is carried out is the intent that existing = connections will still work or do I still have to recreate the client = connections. The latter doesn't seem to be the intent otherwise I might = just as well create a new Root/Host x509 set. >=20 > The 'laptop ipsec cert to ipfire 2' mentioned is the Network Manager = strongswan plugin config. >=20 > Maybe the issue is with the strongswan Network Manager plugin that is = doing some checking somewhere and finding a difference. Obviously the = hostcert.pem has a different signature that before the renewal. >=20 >>>=20 >>> However it doesn't work for existing sets as they already have the = serial file contents at 01. I forgot to add in some code for the = update.sh file to update existing root/host certificates with serial = file contents at 01 to 02. >>>=20 >>> I will put a patch together and submit it for merging and testing. >> Yes please, that makes sense to me, too. >=20 > I will still create the patch for the install.sh script to update the = serial number to 02 for systems that have created the root/host x509 = ipsec certificate set but the problem I have found above suggests that = the ipsec renewal might not work in the expected way for all connection = clients. >=20 > Regards, >=20 > Adolf. >=20 >=20 >>>=20 >>> Regards, >>>=20 >>> Adolf. >>>=20 >>>=20 >>> On 21/03/2025 13:10, Michael Tremer wrote: >>>> Hello Adolf, >>>>> On 20 Mar 2025, at 17:40, Adolf Belka = wrote: >>>>>=20 >>>>> Hi All, >>>>>=20 >>>>> My first findings from CU193 Testing. >>>> Thank you for testing. >>>>> The IPBlocklist sources file and the backup.pl file with the = changes related to removal of the ABUSECH blocklist, did not get into = the filelist file and so that blocklist was not removed. >>>> Thank you. I pushed a commit for this. >>>>> I tested out ipsec. >>>>> A working PSK and cert connection from CU192 were both tested out = with CU193 Testing. >>>>> Both worked in CU192 and also worked without issues when IPFire = was updated to CU193 Testing. >>>>>=20 >>>>> I then created a new ipsec cert connection and tested that out and = it worked but it did not use the post quantum cipher. >>>>>=20 >>>>> Strongswan-6.0.0 is also on my laptop but I am using Network = Manager with a Strongswan plugin and that might not yet be updated with = the post quantum ciphers. >>>> I think this might be quite difficult to test on a client, because = NetworkManager will also need to support this and I am not sure how fast = they will be. >>>> I did however test this myself on a N2N connection and it works = fine. Sadly there is no different feeling to those connections as it = only affects the handshake. We don=E2=80=99t have to worry about any = decreased throughput because of more complex cryptography. >>>>> My laptop and IPFire negotiated a cipher and that connection then = worked. >>>>>=20 >>>>> The other thing that might be getting in the way is that all the = certs currently created in IPSec are legacy based ones,m even if the = Root/Host certificate has been re-created to have the more secure = version with openssl-3.x >>>>>=20 >>>>> I raised a bug on this a while back. >>>>> https://bugzilla.ipfire.org/show_bug.cgi?id=3D13808 >>>>>=20 >>>>> This came about when we updated to OpenSSL-3.x. I added in the = legacy options into the openssl commands in the ovpnmain.cgi page and = did the same thing to the vpnmain.cgi page for IPSec. >>>>>=20 >>>>> Then in the ovpnmain.cgi page I added in the check if the = root/host x509 set was legacy or not and then only used the legacy = option if it was. >>>>>=20 >>>>> However, I never went back to the vpnmain.cgi page to update that = to only use -legacy if the root/host x509 was legacy. >>>>> So currently all client certs are legacy, even if the root/host = x509 is not. >>>>>=20 >>>>> I have assigned that ipsec bug to myself and it will be something = I will have a go at sometime soon. >>>> I don=E2=80=99t like that the entire X.509 situation is becoming = more of a nightmare with every single day that is passing... >>>>> However, main thing, the change to strongswan-6.0.0 has not = negatively impacted the ipsec operation. All existing connections, at = least the ones I had, worked after the CU193 Testing update. >>>> Great! I can confirm the same. >>>> -Michael >>>>> Regards, >>>>> Adolf. >>>>>=20 >>>>> On 19/03/2025 11:57, IPFire Project wrote: >>>>>> Hello Community! Only a few days after releasing the latest = update, we are excited to begin testing the next one. It comes with = support for Post-Quantum Cryptography in IPsec as well as a new = toolchain and a lot of bug and security updates. >>>>>> =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C= =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C = =E2=80=8C =E2=80=8C =E2=80=8C =E2=80=8C >>>>>> IPFire_ >>>>>> IPFire 2.29 - Core Update 193 is available for testing >>>>>> Hello Community! Only a few days after releasing the latest = update, we are excited to begin testing the next one. It comes with = support for Post-Quantum Cryptography in IPsec as well as a new = toolchain and a lot of bug and security updates. >>>>>> Read The Full Post On Our Blog = >>>>>> The IPFire Project, c/o Lightning Wire Labs GmbH, Gerhardstra=C3=9F= e 8, 45711 Datteln, Germany >>>>>> Unsubscribe >>>>>=20 >>>>>=20 >>>=20 >>>=20 >=20 >=20