public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Reason why we do not set rigthca  in the strongswan conf
Date: Wed, 12 Feb 2025 09:26:12 +0000	[thread overview]
Message-ID: <C42A86D4-F755-4532-9A4C-B03EB177A1F1@ipfire.org> (raw)
In-Reply-To: <47de53fca244e7ad2f5b780942ecf2192c49e3a7.camel@ipfire.org>

[-- 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


  reply	other threads:[~2025-02-12  9:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-08 20:50 Jonatan Schlag
2025-02-12  9:26 ` Michael Tremer [this message]
2025-02-14 20:48 Jonatan Schlag
2025-02-18 17:44 ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C42A86D4-F755-4532-9A4C-B03EB177A1F1@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox