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 4ZK1VY05vlz331h for ; Fri, 21 Mar 2025 12:10:29 +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 4ZK1VT2xntz32vw for ; Fri, 21 Mar 2025 12:10:25 +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 4ZK1VS5tPyz7jb; Fri, 21 Mar 2025 12:10:24 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1742559024; 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=iVdCkL5q/k2hcOhAa8BR3Qjc6cNV2UI+HbN1LPPa1T0=; b=ChDdOs1s62NnZUGgkaMC/h+fLmYJ+w1XWc5MseOmSbDqnfj1U3bpRw1LdhseAGUE9FcBIB Fe9gMZPxEzvgBSBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1742559024; 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=iVdCkL5q/k2hcOhAa8BR3Qjc6cNV2UI+HbN1LPPa1T0=; b=WaYAUg2xPPAk3XGXscICOFxcn3qO/mhYmtsdxni/Tyd/xW1GQxtDiiG8FeSqt0rf8ANjsc E7yFOGgDLXQ/vG8awpu1oEqQeEo9bzxjZurYcSPIKiv7vKnrKI1ZNcvp8KNzW631JcI4hD PtdEO7/mPLeckyECWDj/gUHkk9/jmQl24IV92/3IU0BVnxrb8GXqwFHFWkaz0KWzHWMgOc vCClHeSpkbCWpLjBW8w4mKm6OnIylaV0XwimAvHv3hiBebra2QGIC0IsVS9GZkABwwxRF4 AzEqcjzZN1SFYu5ZGJ1BPO4mIvw/kuPoZxhIpnX+nbMqa4HqwINOuJzwtySVDA== 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: Fri, 21 Mar 2025 12:10:24 +0000 Cc: "IPFire: Development-List" Content-Transfer-Encoding: quoted-printable Message-Id: References: <174238111584.1720815.10275774082881760962.ipfire@ipfire.org> To: Adolf Belka 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=9Fe = 8, 45711 Datteln, Germany >> Unsubscribe >=20 >=20