From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <development+bounces-107-archive=lists.ipfire.org@lists.ipfire.org> Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4ZLFNr6XJrz333G for <archive@lists.ipfire.org>; Sun, 23 Mar 2025 12:09:48 +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 4ZLFNn2JfTz32vy for <development@lists.ipfire.org>; Sun, 23 Mar 2025 12:09:45 +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 4ZLFNm67RKz66; Sun, 23 Mar 2025 12:09:44 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1742731784; 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=Vi6eqsslPUsUpCRekIbOYgah56gL3t1VojmaZekDbjs=; b=Cg57DORFlr9EpvuaiiPbm5V/O5QIGAy1GmQi9xwGODeAoUHvYxwxzQV8dxp0mcMzt8pKfO TOyvKX1nUiAnhFCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1742731784; 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=Vi6eqsslPUsUpCRekIbOYgah56gL3t1VojmaZekDbjs=; b=kUrQ7cNCENOvkarPo/whYxqNTK6dmc02FeDD26Usj3CkW6lHDAq3AJ0zl+MGKPIEncuF0r ADnU0ER4g7LFzP5IQ66E+ll91O5q7fSScRRUBfT4lfGkDrRk3FHRXBTDOEfkh9aYZVANHl hIuOCun5XHshgNAFhOdDRwl3hIyNpLFwPLVbOZYxjTALZKDRHTLFzxbvNI7asJx7ZxJBwb TkT5TMGiG0yLzz9gbgNkg9W/is0/jYhcRsSRQpRHXYfVXZ9nRjjj5D8ANiTrb8g8hC1CQU PBpTQznEhyadCzC3Gj6DnmAocXSzslx1OMvKSOY0uYwWbEAUm4WexpQOvv0IDQ== Content-Type: text/plain; charset=utf-8 Precedence: list List-Id: <development.lists.ipfire.org> List-Subscribe: <https://lists.ipfire.org/>, <mailto:development+subscribe@lists.ipfire.org?subject=subscribe> List-Unsubscribe: <https://lists.ipfire.org/>, <mailto:development+unsubscribe@lists.ipfire.org?subject=unsubscribe> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development+help@lists.ipfire.org?subject=help> Sender: <development@lists.ipfire.org> Mail-Followup-To: <development@lists.ipfire.org> Mime-Version: 1.0 Subject: Re: IPFire 2.29 - Core Update 193 is available for testing From: Michael Tremer <michael.tremer@ipfire.org> In-Reply-To: <2c4d9fcd-6cde-4bcd-a65d-815d7d283dc4@ipfire.org> Date: Sun, 23 Mar 2025 12:09:44 +0000 Cc: development@lists.ipfire.org Content-Transfer-Encoding: quoted-printable Message-Id: <D848285E-C769-4672-BAFF-7251110342B9@ipfire.org> References: <174238111584.1720815.10275774082881760962.ipfire@ipfire.org> <f781d67a-e07a-4916-a39a-0ef2190d38c9@ipfire.org> <BBC1F242-E564-447C-B219-367B2A6B41F0@ipfire.org> <2c4d9fcd-6cde-4bcd-a65d-815d7d283dc4@ipfire.org> To: Adolf Belka <adolf.belka@ipfire.org> Hello, > On 22 Mar 2025, at 17:22, Adolf Belka <adolf.belka@ipfire.org> 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 > 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 > 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 <adolf.belka@ipfire.org> = 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 = <https://www.ipfire.org/blog/ipfire-2-29-core-update-193-is-available-for-= testing?utm_medium=3Demail&utm_source=3Dblog-announcement> >>>> The IPFire Project, c/o Lightning Wire Labs GmbH, Gerhardstra=C3=9Fe = 8, 45711 Datteln, Germany >>>> Unsubscribe <https://www.ipfire.org/unsubscribe> >>>=20 >>>=20 >=20 >=20