From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: Reason why we do not set rigthca in the strongswan conf Date: Tue, 18 Feb 2025 17:44:49 +0000 Message-ID: <06EB99A4-ADF5-4044-A820-D7F03B849DD6@ipfire.org> In-Reply-To: <29DE9509-29E2-4DFB-9776-88EE24235DCA@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4177344665716854759==" List-Id: --===============4177344665716854759== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, > On 14 Feb 2025, at 20:48, Jonatan Schlag wrot= e: >=20 >=20 > Hi, >=20 >> Am 12.02.2025 um 10:26 schrieb Michael Tremer : >> =EF=BB=BFHello Jonatan, >>=20 >> That is a good question. I am aware of the certificate pinning problem tha= t we have here and that we cannot easily just roll over the host certificate = (which we should be able to!) because it is pinned on the remote side. I did = not have time to look into this in detail, but simply accepting the CA would = be a good solution for this and potentially will make the configuration even = easier. >>=20 >> Long term, I would like to think how to move away from X.509 for IPsec, bu= t that is a story for another day. >=20 > Because the work of maintaining a certificate is too much? Or what are the = reasons? I only need a short explanation. If there is a better alternative to= implement then certificates, I=E2=80=99m happy to use this one. And we both = don=E2=80=99t need to turn further time into how this strongswan feature work= s. Not necessarily the work for the user, but the complexity on the development = side is high. We have had lots of problems in ASN1 parsers in the past. In IP= Fire, we are setting up an extra CA which then connects all tunnels to the sa= me CA. If I have a problem, I suddenly have to touch all tunnels. I think the solution might be a public/private key pair for each connection. = strongSwan supports this, WireGuard is going that way. This would create inde= pendent connections and even reduce the risk of compromising all at the same = time. https://dn42.eu/howto/IPsecWithPublicKeys/strongSwan5Example Instead of having many decentralised CAs, we have ended up with a few public = ones and therefore the world might be a very different one compared to the on= e that was envisioned by the people back then. I think that we are practicall= y using the host certificates as shown in the example above. >>=20 >> What are the disadvantages of just using the CA? I suppose there is the pr= oblem that most people don=E2=80=99t use the FQDN of the remote side to estab= lish their connections. Very often, the firewall does not even have a proper = FQDN that actually resolves to the right IP address at all; therefore I belie= ve that we cannot even perform any solid validation based on the certificate= =E2=80=99s subject/hostname. >>=20 >> Usually within IPFire, this should not be a problem because the CA is not = issuing that many certificates, but in theory it is possible to use a public = CA. Both problems put together would mean that the remote firewall will accep= t *any* certificate that has ever been issued (even some road warrior certifi= cates that might have been issued); or in case of a public CA like Let=E2=80= =99s Encrypt, this could be a large chunk of the internet. >>=20 > The remote side id is also checked, isn=E2=80=99t it? So we could somehow p= in to one certificate even if the hostname does not match. And if Let=E2=80= =99s Encrypt provides you with a cert which has a subject alternative name se= t to something random, I would be very surprised. No, the ID is not being used when a certificate is in use. The =E2=80=9CID=E2= =80=9D will become the subject line of the certificate which includes many th= ings and the hostname. Proper host certificates for IPFire would be absolutely great. I just doubt t= hat we will see this rolled out in large numbers though. >> How does strongswan deal with incoming connections? Just because it has a = CA does not mean that it should find the right connection because this usuall= y is found by the subject of the certificate. Does it simply iterate through = all CAs and go with anything that matches? That would be very broad as well I= suppose. >=20 > It=E2=80=99s kind of interesting. I=E2=80=99ve just read the documentation = one more time and apparently you are supposed to set this option to the disti= nguished name of the certificate authority. I simply provided the file of my = certificate authority certificate and it seems to work also. So we could set = this relatively narrow, to the certificate authority we imported. So, pain? > Jonatan >=20 >>=20 >> So in theory, I like the idea, just the CA should be enough. But I believe= in practice there might be some problems. Maybe some of the things I outline= d here are not a concern at all; that would need to be tested. Are you up for= that? >=20 >=20 >>=20 >> -Michael >>=20 >>> On 8 Feb 2025, at 20:50, Jonatan Schlag wro= te: >>>=20 >>> Hi list, >>>=20 >>> recently I had to renew the host cert of my IPFire system for >>> strongswan. As we currently write: >>>=20 >>> rightcert =3D >>>=20 >>> into the config (see for this: >>> https://git.ipfire.org/?p=3Dipfire-2.x.git;a=3Dblob;f=3Dhtml/cgi-bin/vpnm= ain.cgi;h=3D3541aaa29393091258456cf787fefe3ec5ca3cb4;hb=3Drefs/heads/master#l= 379 >>> I have to change the cert of the remote system as well. Is there a >>> reason for this? When I use >>>=20 >>> rightca=3D >>>=20 >>> the connection works out of the box. Is there a reason why we make not >>> use of this option? >>>=20 >>> Jonatan --===============4177344665716854759==--