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 4b6s5F2DXPz32yZ for ; Wed, 28 May 2025 14:17:05 +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 4b6s595kNxz30Bt for ; Wed, 28 May 2025 14:17:01 +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 4b6s5768LtzQJ; Wed, 28 May 2025 14:16:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1748441821; 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=neL814kU9fFDG4XLgJ8NQc63bUCPzQ9Jisodo20z5oo=; b=YKE8mxeBd8riTNmA6xChkROST7tCsJFsMB5EEXzWlxqpG1eLjzgUantVwXXaT8kKIrAwlY hpK691mtdLunROSpevkIrnPPud3VKGpjcoboR/K7V82F2PDLxppdzbY0MtlwyU4NEM5zU+ iP17Eq2oEU80w8v+CTzZFDqicZlMsXS/Q1rmMY/6agrbc52uMBThEgLfi3HO/QwHfmf3Va 0oCcykTtOmjxRZRfCTOgLahwknQUWaxGukFmYUDJN74HL7Xdip2+/IJi1dAiIySDtdEadS robXQy6IT/kghEk4dKKYIioRAoGEa/iz/sivFmzNCwlxugQrydAt0D5UnX/88w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1748441821; 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=neL814kU9fFDG4XLgJ8NQc63bUCPzQ9Jisodo20z5oo=; b=kwxBicGrNathHWoZne2zAt7v8SOIIlSiEx/WhXifEi3xBUGDmwVikTL37XbyqJikGaCUou bGtjd4in9pGy9dAA== 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: [PATCH v2 2/2] Core Update 196: Adjust existing IPsec connections using ML-KEM From: Michael Tremer In-Reply-To: Date: Wed, 28 May 2025 15:16:56 +0100 Cc: "IPFire: Development" Content-Transfer-Encoding: quoted-printable Message-Id: References: <3d399f8b-3f71-4ca4-beaa-88c7c4ecbaf7@ipfire.org> To: =?utf-8?Q?Peter_M=C3=BCller?= Hello Peter, Thanks for the updated patch. I applied it, but there were further changes necessary because if an = update has been applied more than once, it would have broken the IPsec = configuration. The update also needed to happen when a backup is being = restored, and vpnmain.cgi needs to be called as nobody only. Please review these changes: = https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D6ed4634be943= fe125b61f0348063016fcacb89ee = https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dcommitdiff;h=3D5d0b4d3b9df0= d93aeb3d2400550c5ee355ba7146 Best, -Michael > On 26 May 2025, at 19:28, Peter M=C3=BCller = wrote: >=20 > This causes existing IPsec connections using ML-KEM to always use it = in > conjunction with Curve 25519, in line with the changes = dfa7cd2bbac3c746569368d70fefaf1ff4e1fed2 > implements for newly configured IPsec connections. >=20 > Again, we can reasonably assume an IPsec peer supporting ML-KEM also > supports Curve 25519. In case such a peer does not support RFC 9370, = and > the IPsec connection was created using our default ciphers, it will = fall > back to Curve 448, Curve 25519, or any other traditional algorithm. >=20 > This patch will break existing IPsec connections only if they are > exclusively using ML-KEM (which means the IPFire user reconfigured = them > manually using the "advanced connection settings" section in the = WebUI), > and the IPsec peer is configured in the same manner, and/or is an = IPFire > machine not yet updated to Core Update 196. Any other IPFire-to-IPFire > IPsec connection will continue working, potentially falling back to > Curve 448 or 25519 until both peers are updated to Core Update 196, > after which ML-KEM in conjunction with Curve 25519 will be used again. >=20 > The second version of this patch modifies IPFire's own configuration > file for IPsec connections, rather than applying these changes = directly > to /etc/ipsec.conf, where they would have been overwritten by the next > WebUI change. >=20 > Signed-off-by: Peter M=C3=BCller > --- > config/rootfiles/core/196/update.sh | 11 +++++++++++ > 1 file changed, 11 insertions(+) >=20 > diff --git a/config/rootfiles/core/196/update.sh = b/config/rootfiles/core/196/update.sh > index 0138fabcf..b8f92322f 100644 > --- a/config/rootfiles/core/196/update.sh > +++ b/config/rootfiles/core/196/update.sh > @@ -32,6 +32,7 @@ for (( i=3D1; i<=3D$core; i++ )); do > done >=20 > # Stop services > +/etc/rc.d/init.d/ipsec stop >=20 > # Remove files > rm -rfv \ > @@ -65,7 +66,17 @@ esac > # Apply SSH configuration > #/usr/local/bin/sshctrl >=20 > +# Change IPsec configuration of existing connections using ML-KEM > +# to always make use of hybrid key exchange in conjunction with Curve = 25519. > +sed -i -e "s@mlkem@x25519-ke1_mlkem@g" /var/ipfire/vpn/config > + > +# Apply changes to ipsec.conf > +/srv/web/ipfire/cgi-bin/vpnmain.cgi > + > # Start services > +if grep -q "ENABLED=3Don" /var/ipfire/vpn/settings; then > + /etc/rc.d/init.d/ipsec start > +fi >=20 > # This update needs a reboot... > #touch /var/run/need_reboot > --=20 > 2.43.0 >=20