Security issues and user experience of IPSEC implementation

[schnipp]

I like to restructure my IPSEC VPN endpoints and noticed some inconsistencies in the configuration options which motivated me to have a deeper look into the IPSEC implementation with strongswan. I observed some security relevant issues but there can be even more. Of cource, strongswan is very flexible in its configuration and it's very difficult to map all of its configuration possibilities to the web gui. Currently, the gui lacks of flexibility in configuring the endpoint authentication, which is one of the most important parts of VPN security besides data confidentiality and integrity.

This thread should discuss alternatives to the current implementation to improve security and flexibility.

Observations regarding my IPSEC connections:

• Site-to-Site with IKEv2: Authentication based on "Mutual RSA"
  
  • "My Certificate Authority" has a confusing description and maps to "rightca" configuration option. The parameter should be named to "Remote endpoint authentication CA"
• Roadwarrior with IKEv2: Authentication based on "Mutual RSA + EAP-MSCHAPv2"
  
  • There is no possibility to configure which remote endpoint certificates are acceptable (neither leaf certificates or certification authorities) and no corresponding "rightcert" or "rightca" configuration options are placed in the ipsec configuration file. I do not know, how this is handled by strongswan. I guess, in this situation all remote endpoint certificates which belongs to any trusted CA are accepted. This could be a big security risk.

Recommendations:

• Adapt the gui to follow the strongswan configuration file in ways that parameters like "leftauth, rightauth, leftcert, rightcert, rightca" etc. are configurable on a per connection basis
• Separate authentication rounds for IKEv2 (xauth for IKEv1 respectively), e.g. "Auth 1: Mutual RSA" and "Auth 2: EAP-MSCHAPv2" instead of "Auth: Mutual RSA + EAP-MSCHAPv2"
• Allow configuring multiple dedicated roadwarrior connections with their own IP pools
• Move from deprecated "ipsec.conf" to "swanctl" (swanctl.conf and strongswan.conf")
• Make strongswan aware of revoked certificates (can be challenging). For now, users probably feel secure in case they revoke certificates of compromised private keys within the trust center.

My Opnsense: v.21.7.1-amd64

Maybe, somebody has additional ideas.

[schnipp]

Does nobody concern about security issues of Ipsec configurations? 

[glasi]

• Site-to-Site with IKEv2: Authentication based on "Mutual RSA"
  
  • "My Certificate Authority" has a confusing description and maps to "rightca" configuration option. The parameter should be named to "Remote endpoint authentication CA"

In fact, I think the naming could be improved in some points. The current naming is sometimes confusing.

• ...
• Roadwarrior with IKEv2: Authentication based on "Mutual RSA + EAP-MSCHAPv2"
  
  • There is no possibility to configure which remote endpoint certificates are acceptable (neither leaf certificates or certification authorities) and no corresponding "rightcert" or "rightca" configuration options are placed in the ipsec configuration file. I do not know, how this is handled by strongswan. I guess, in this situation all remote endpoint certificates which belongs to any trusted CA are accepted. This could be a big security risk.

You're right! I checked my ipsec.conf and neither "rightcert" nor "rightca" are configured. 
According to StrongSwan docs any valid certificate issued by one of the trusted CAs in /etc/ipsec.d/cacerts can be used by the peer if no rightca parameter is present.

Indeed, we shouldn't like that.

Recommendations:

• Adapt the gui to follow the strongswan configuration file in ways that parameters like "leftauth, rightauth, leftcert, rightcert, rightca" etc. are configurable on a per connection basis
• Separate authentication rounds for IKEv2 (xauth for IKEv1 respectively), e.g. "Auth 1: Mutual RSA" and "Auth 2: EAP-MSCHAPv2" instead of "Auth: Mutual RSA + EAP-MSCHAPv2"
• Allow configuring multiple dedicated roadwarrior connections with their own IP pools
• Move from deprecated "ipsec.conf" to "swanctl" (swanctl.conf and strongswan.conf")
• Make strongswan aware of revoked certificates (can be challenging). For now, users probably feel secure in case they revoke certificates of compromised private keys within the trust center.

Very good recommendations.

A revision of the StrongSwan implementation and improvement of the configuration options in OPNsense is definitely required. On this occasion we should switch from deprecated ipsec.conf to swanctl.conf.

[franco]

I would propose raising a ticket in GitHub where this naturally goes and not trying to play the "security" card on GUI wording / documentation inconsistencies.


Cheers,
Franco

[schnipp]

Yes, raising a github ticket is the right way to get changes into code. But, first I would like to get a full overview about requirements or ideas for improvement. And there is nothing about playing the "security" card. The current implementation suffers from issues that different Ipsec connections interfere in aspects of authentication, that's a fact. And I guess the majority of Ipsec users is not aware of this. This will lead to a security risk if users or companies configure multiple Ipsec connections.

In my eyes it's good to discuss the basics and ideas here in the forum to get some more input, hopefully  . Afterwards, I'll try to describe the ideas in a comprehensive pull request.

[schnipp]

I have raised some tickets at github, feel free to comment:

• IPSec: Security issues in authenticating connections (#5239)
• IPSec: Fine granular configuration of authentication not possible (#5240)
• IPSec: Parameters and Description in the IPsec configuration dialog should be improved (#5241)

[glasi]

Thanks, schnipp!

I'll take a look at your Github tickets.

[schnipp]

I am puzzled that there is no interest in fixing the security issues of the IPSec implementation. Don't get me wrong, Opnsense is good product and a lot of people are involved to improve and support this project. But, understood as a security component security issues should be solved with a high priority. This is even more the case if Opnsense is recommended for use in business environments.

What about a dedicated process to handle security issues with high priority?