Re: Reason why we do not set rigthca in the strongswan conf

Re: Reason why we do not set rigthca in the strongswan conf

[Jonatan Schlag]

[-- Attachment #1: Type: text/plain, Size: 3664 bytes --]


Hi,

> Am 12.02.2025 um 10:26 schrieb Michael Tremer <michael.tremer(a)ipfire.org>:
> Hello Jonatan,
> 
> That is a good question. I am aware of the certificate pinning problem that 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.
> 
> Long term, I would like to think how to move away from X.509 for IPsec, but that is a story for another day.

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’m happy to use this one. And we both don’t need to turn further time into how this strongswan feature works.
> 
> What are the disadvantages of just using the CA? I suppose there is the problem that most people don’t use the FQDN of the remote side to establish 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 believe that we cannot even perform any solid validation based on the certificate’s subject/hostname.
> 
> 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 accept *any* certificate that has ever been issued (even some road warrior certificates that might have been issued); or in case of a public CA like Let’s Encrypt, this could be a large chunk of the internet.
> 
The remote side id is also checked, isn’t it? So we could somehow pin to one certificate even if the hostname does not match. And if Let’s Encrypt provides you with a cert which has a subject alternative name set to something random, I would be very surprised.

> 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 usually 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.

It’s kind of interesting. I’ve just read the documentation one more time and apparently you are supposed to set this option to the distinguished 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.

Jonatan

> 
> 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 outlined here are not a concern at all; that would need to be tested. Are you up for that?


> 
> -Michael
> 
>> On 8 Feb 2025, at 20:50, Jonatan Schlag <jonatan.schlag(a)ipfire.org> wrote:
>> 
>> Hi list,
>> 
>> recently I had to renew the host cert of my IPFire system for
>> strongswan. As we currently write:
>> 
>> rightcert =
>> 
>> into the config (see for this:
>> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/vpnmain.cgi;h=3541aaa29393091258456cf787fefe3ec5ca3cb4;hb=refs/heads/master#l379
>> I have to change the cert of the remote system as well. Is there a
>> reason for this? When I use
>> 
>> rightca=
>> 
>> the connection works out of the box. Is there a reason why we make not
>> use of this option?
>> 
>> Jonatan

Re: Reason why we do not set rigthca in the strongswan conf

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 5038 bytes --]

Hello,

> On 14 Feb 2025, at 20:48, Jonatan Schlag <jonatan.schlag(a)ipfire.org> wrote:
> 
> 
> Hi,
> 
>> Am 12.02.2025 um 10:26 schrieb Michael Tremer <michael.tremer(a)ipfire.org>:
>> Hello Jonatan,
>> 
>> That is a good question. I am aware of the certificate pinning problem that 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.
>> 
>> Long term, I would like to think how to move away from X.509 for IPsec, but that is a story for another day.
> 
> 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’m happy to use this one. And we both don’t need to turn further time into how this strongswan feature works.

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 IPFire, we are setting up an extra CA which then connects all tunnels to the same 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 independent 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 one that was envisioned by the people back then. I think that we are practically using the host certificates as shown in the example above.

>> 
>> What are the disadvantages of just using the CA? I suppose there is the problem that most people don’t use the FQDN of the remote side to establish 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 believe that we cannot even perform any solid validation based on the certificate’s subject/hostname.
>> 
>> 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 accept *any* certificate that has ever been issued (even some road warrior certificates that might have been issued); or in case of a public CA like Let’s Encrypt, this could be a large chunk of the internet.
>> 
> The remote side id is also checked, isn’t it? So we could somehow pin to one certificate even if the hostname does not match. And if Let’s Encrypt provides you with a cert which has a subject alternative name set to something random, I would be very surprised.

No, the ID is not being used when a certificate is in use. The “ID” will become the subject line of the certificate which includes many things and the hostname.

Proper host certificates for IPFire would be absolutely great. I just doubt that 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 usually 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.
> 
> It’s kind of interesting. I’ve just read the documentation one more time and apparently you are supposed to set this option to the distinguished 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
> 
>> 
>> 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 outlined here are not a concern at all; that would need to be tested. Are you up for that?
> 
> 
>> 
>> -Michael
>> 
>>> On 8 Feb 2025, at 20:50, Jonatan Schlag <jonatan.schlag(a)ipfire.org> wrote:
>>> 
>>> Hi list,
>>> 
>>> recently I had to renew the host cert of my IPFire system for
>>> strongswan. As we currently write:
>>> 
>>> rightcert =
>>> 
>>> into the config (see for this:
>>> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/vpnmain.cgi;h=3541aaa29393091258456cf787fefe3ec5ca3cb4;hb=refs/heads/master#l379
>>> I have to change the cert of the remote system as well. Is there a
>>> reason for this? When I use
>>> 
>>> rightca=
>>> 
>>> the connection works out of the box. Is there a reason why we make not
>>> use of this option?
>>> 
>>> Jonatan

Re: Reason why we do not set rigthca in the strongswan conf

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]

Hello Jonatan,

That is a good question. I am aware of the certificate pinning problem that 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.

Long term, I would like to think how to move away from X.509 for IPsec, but that is a story for another day.

What are the disadvantages of just using the CA? I suppose there is the problem that most people don’t use the FQDN of the remote side to establish 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 believe that we cannot even perform any solid validation based on the certificate’s subject/hostname.

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 accept *any* certificate that has ever been issued (even some road warrior certificates that might have been issued); or in case of a public CA like Let’s Encrypt, this could be a large chunk of the internet.

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 usually 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.

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 outlined here are not a concern at all; that would need to be tested. Are you up for that?

-Michael

> On 8 Feb 2025, at 20:50, Jonatan Schlag <jonatan.schlag(a)ipfire.org> wrote:
> 
> Hi list,
> 
> recently I had to renew the host cert of my IPFire system for
> strongswan. As we currently write:
> 
> rightcert =
> 
> into the config (see for this:
> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/vpnmain.cgi;h=3541aaa29393091258456cf787fefe3ec5ca3cb4;hb=refs/heads/master#l379
> I have to change the cert of the remote system as well. Is there a
> reason for this? When I use 
> 
> rightca=
> 
> the connection works out of the box. Is there a reason why we make not
> use of this option?
> 
> Jonatan

Reason why we do not set rigthca in the strongswan conf

[Jonatan Schlag]

[-- Attachment #1: Type: text/plain, Size: 521 bytes --]

Hi list,

recently I had to renew the host cert of my IPFire system for
strongswan. As we currently write:

rightcert =

into the config (see for this:
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/vpnmain.cgi;h=3541aaa29393091258456cf787fefe3ec5ca3cb4;hb=refs/heads/master#l379
I have to change the cert of the remote system as well. Is there a
reason for this? When I use 

rightca=

the connection works out of the box. Is there a reason why we make not
use of this option?

Jonatan