Re: [strongSwan] Trouble configuring vpn connection to strongswan using smartcard

[Nathan Hüsken]

Hey,

OK, in the end my mistake was, that I believed the pkcs#11 Plugin was enabled 
in charon-nm, as it was only enabled in strongswan itself. It works now.
Thanks for pointing that out and thanks for all the help!

Nathan


​--

Dr. Nathan Hüsken

Cloud Developer

nat...@wintercloud.de

+49 151 703 478 84

wintercloud GmbH & Co. KG

Emil-Maier-Str. 16

69115 Heidelberg

wintercloud.de

Sitz der Kommanditgesellschaft: Heidelberg, Registernummer der 
Kommanditgesellschaft im Handelsregister: AG Mannheim HRA 707268

Komplementärin: junah GmbH, Sitz der Komplementärin: Heidelberg, Registernummer 
der Komplementärin im Handelsregister: AG Mannheim HRB 726538, Geschäftsführer 
der Komplementärin: Julian Wintermayr und Dr. Nathan Hüsken

USt-IdNr.: DE815676705​

‐‐‐ Original Message ‐‐‐

On 19 July 2018 7:50 PM, Tobias Brunner  wrote:

> ​​
> 
> Hi Nathan,
> 
> > I wanted to use the network-manager (in the end, the config has to be 
> > usable by people scared of the command line).
> > 
> > There is an option: "Smartcard". If choose it, it asks me for the pin of 
> > the smart card (but complains, that there are not usable certificates on 
> > the smartcard).
> > 
> > If charon-nm doest not support reading the private key from the smartcard, 
> > what is the point of this option?
> > 
> > What am I missing here?
> 
> You are confusing charon-cmd and NM/charon-nm (and perhaps charon).
> 
> charon-nm supports private keys on smartcards (with the already
> 
> mentioned limitations), as does charon (with more flexibility),
> 
> charon-cmd does not.
> 
> Regards,
> 
> Tobias

Re: [strongSwan] Security Comparison

[Marco Berizzi]

Hi Andreas,

> actually X25519 DH group 31 has a security strength of 128 bits, similar
> to ECP-256, although the Curve25519 characteristics are much better
> than those of the ECP-256 NIST curve.

thanks for the correction.

Re: [strongSwan] Security Comparison

[Andreas Steffen]

Hi Marco,

actually X25519 DH group 31 has a security strength of 128 bits, similar
to ECP-256, although the Curve25519 characteristics are much better
than those of the ECP-256 NIST curve.

The "Goldilocks" X448 (DH group 32) has a security strength of 224 bits
which is half-way between 192 bits and 256 bits. strongSwan doesn't
support X448 yet.

Best regards

Andreas

On 20.07.2018 14:43, Marco Berizzi wrote:
> Hi Tobias,
> 
> I think this is an underestimated point. Deserves more attention.
> 
>> The cryptographic strength of all ciphers in a cipher suite should be
>> consistent.  For instance, using AES-256 for ESP is basically wasted
>> when using MODP-2048 because that has only an estimated strength of 112
>> bits (same for ECP-256 whose estimated strength is 128 bits).
> 
> Adding your above remark to [3] would be extremely useful.
> 
> According to this paper [1] MODP-1536 is broken (< 112 bits of security
> strength), and according to this nist publication [2], the only way to
> be consistent with AES-256 is ECP-521 (diffie hellmann group 21) or x25519
> (diffie hellmann group 31).
> 
> The MODP-3072 or ECP-256 is the minimum for being consistent with AES-128.
> 
> So a simple consistent table could be:
> 
> AES-128 ==>> MODP-3072 or ECP-256
> AES-192 ==>> MODP-8192 or ECP-384
> AES-256 ==>> ECP521 or x25519
> 
> [1] 
> https://csrc.nist.gov/csrc/media/publications/sp/800-131a/rev-1/final/documents/sp800-131a_r1_draft.pdf
> [2] 
> https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf
> [3] 
> https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations
> 

-- 
==
Andreas Steffen andreas.stef...@strongswan.org
strongSwan - the Open Source VPN Solution!  www.strongswan.org
Institute for Networked Solutions
HSR University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===[INS-HSR]==



smime.p7s
Description: S/MIME Cryptographic Signature

[strongSwan] Config check

[Christian Salway]

Can someone please confirm that this config makes sense. I want to use vici and 
only have eap-radius as the authentication with clients connecting with 
username/password MSCHAPv2.  It works but I don't want to install (or have 
installed) unnecessary modules.

./configure --prefix=/usr --sysconfdir=/etc \
  --enable-systemd --enable-swanctl \
  --disable-charon --disable-stroke --disable-scepclient \
  --enable-eap-identity --enable-eap-radius --enable-openssl



Kind regards,

Christian Salway
IT Consultant - Naimuri

T: +44 7463 331432
E: christian.sal...@naimuri.com
A: Naimuri Ltd, Capstan House, Manchester M50 2UW

[strongSwan] Security Comparison

[Marco Berizzi]

Hi Tobias,

I think this is an underestimated point. Deserves more attention.

> The cryptographic strength of all ciphers in a cipher suite should be
> consistent.  For instance, using AES-256 for ESP is basically wasted
> when using MODP-2048 because that has only an estimated strength of 112
> bits (same for ECP-256 whose estimated strength is 128 bits).

Adding your above remark to [3] would be extremely useful.

According to this paper [1] MODP-1536 is broken (< 112 bits of security
strength), and according to this nist publication [2], the only way to
be consistent with AES-256 is ECP-521 (diffie hellmann group 21) or x25519
(diffie hellmann group 31).

The MODP-3072 or ECP-256 is the minimum for being consistent with AES-128.

So a simple consistent table could be:

AES-128 ==>> MODP-3072 or ECP-256
AES-192 ==>> MODP-8192 or ECP-384
AES-256 ==>> ECP521 or x25519

[1] 
https://csrc.nist.gov/csrc/media/publications/sp/800-131a/rev-1/final/documents/sp800-131a_r1_draft.pdf
[2] 
https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-57pt1r4.pdf
[3] https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations

Re: [strongSwan] Security Comparison

[Noel Kuntze]

Hello Christian,

The cryptographic strength is only of tertiary importance in your threat 
scenario. Adhere to the recommendations from your apropriate standardization 
body (e.g. NIST, BSI, ...)
and you'll be off just fine. The primary threat comes from bugs. This needs to 
be mitigated through constant patching. The secondary threat is through social 
engineering and related attacks. After that, it's threats from inadequately 
maintained networks (lack of firewall rules, no network segmentation, ...). 
Then comes cryptography.

For VDI, the use case and the requirements are important. strongSwan scales 
better than OpenVPN and is capable of active-active redundancy, but OpenVPN 
goes through restrictive coffee shop firewalls, which IKE can't do, because it 
doesn't look like TLS.

Kind regards

Noel

On 20.07.2018 13:36, Christian Salway wrote:
> Hi Noel,
> 
> Thank you for adding input.  I went away since that email and understood how 
> the initial handshake worked for HTTPS and it all makes sense now.  I am not 
> interested in using OpenVPN (in any way). The comparison was to using a 
> Virtual Desktop secured with HTTPS (TLS) to VPN and having an argument to 
> give to the client on which was stronger for data messages.
> 
> You have taught me a few points in your last paragraph which is very much 
> appreciated but OpenVPN is not even in question.
> 
> Kind regards,
> 
> *Christian Salway*
> IT Consultant - *Naimuri*
> 
> T: +44 7463 331432
> E: christian.sal...@naimuri.com 
> A: Naimuri Ltd, Capstan House, Manchester M50 2UW
> 
>> On 20 Jul 2018, at 12:27, Noel Kuntze 
>> > > wrote:
>>
>> Hello Christian,
>>
>> I have some more points to make, additionally to what you already discussed 
>> with Tobias.
>>> Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that should 
>>> a VPN client be infected with a worm, it is easier for that worm to infect 
>>> the network, I’m struggling to see another security argument.
>> That is entirely irrelevant and wrong. OpenVPN just puts the IP packets in 
>> its own transport protocoll, which to the outside looks like TLS, but it's 
>> _not_ TLS. They implemented their own handshake. Also, there is not a single 
>> bit of HTTP in it and the layer differentiation here is irrelevant. Both are 
>> layer three VPNs. IPsec can also work as a layer 4 VPN, if you use transport 
>> mode. Thus any difference is irrelevant for any kind of malicious software 
>> trying to attack over the/a VPN.
>>
>>>
>>> Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection.  
>>> Whereas IKE also uses a certificate to do the KeyExchange before logging in 
>>> and then encrypting the data with ESP, so the ciphers used on ESP I feel is 
>>> the comparison that needs to be made.
>> As Tobias already work, that's not what is happening. RSA is extremely slow 
>> compared to symmetric ciphers. RSA is only used for proving the identity of 
>> the peers by use of signing and verification of a signature. DH or ECDH is 
>> used for the key exchange. After that, symmetric ciphers and HMACs or AEAD 
>> algorithms are used for encryption and authentication. IPsec is historically 
>> stronger than TLS, because it does not use Mac-Then-Encrypt, which TLS does. 
>> That lead to attacks like Bleichenbacher's attack where the error handling 
>> with invalid padding (and other data) in the handshakes leads to 
>> vulnerabilities that can be used to decrypt data. IPsec uses 
>> Encrypt-Then-Mac. Attacks like Bleichenbacher's don't work on IPsec.
>>
>> Kind regards
>>
>> Noel
>>
>> On 19.07.2018 09:33, Christian Salway wrote:
>>> Hi Robert,
>>>
>>> Thank you for coming back to me.  I have a client who is pushing for VDI 
>>> (HTTPS) instead of VPN (IPSEC) and I’m wondering whether there is a 
>>> security standpoint I can argue or if its just as secure.  I am also 
>>> limited to the native OSX/Windows VPN clients which currently support a 
>>> maximum of aes256-sha256-prfsha256-ecp256-modp2048 (Windows does not 
>>> support ecp)
>>>
>>> Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that should 
>>> a VPN client be infected with a worm, it is easier for that worm to infect 
>>> the network, I’m struggling to see another security argument.
>>>
>>> Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection.  
>>> Whereas IKE also uses a certificate to do the KeyExchange before logging in 
>>> and then encrypting the data with ESP, so the ciphers used on ESP I feel is 
>>> the comparison that needs to be made.
>>>
>>> I will have a read of that Cipher suites page, but if I remember correctly, 
>>> it is not a comparison but a standpoint.
>>>
>>> C
>>>
 On 19 Jul 2018, at 05:51, Robert Leonard >>>  > wrote:

 I don't really know where to start with this article.  It appears to be 
 

Re: [strongSwan] Security Comparison

[Christian Salway]

Hi Noel,

Thank you for adding input.  I went away since that email and understood how 
the initial handshake worked for HTTPS and it all makes sense now.  I am not 
interested in using OpenVPN (in any way). The comparison was to using a Virtual 
Desktop secured with HTTPS (TLS) to VPN and having an argument to give to the 
client on which was stronger for data messages.

You have taught me a few points in your last paragraph which is very much 
appreciated but OpenVPN is not even in question.

Kind regards,

Christian Salway
IT Consultant - Naimuri

T: +44 7463 331432
E: christian.sal...@naimuri.com
A: Naimuri Ltd, Capstan House, Manchester M50 2UW

> On 20 Jul 2018, at 12:27, Noel Kuntze 
>  wrote:
> 
> Hello Christian,
> 
> I have some more points to make, additionally to what you already discussed 
> with Tobias.
>> Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that should a 
>> VPN client be infected with a worm, it is easier for that worm to infect the 
>> network, I’m struggling to see another security argument.
> That is entirely irrelevant and wrong. OpenVPN just puts the IP packets in 
> its own transport protocoll, which to the outside looks like TLS, but it's 
> _not_ TLS. They implemented their own handshake. Also, there is not a single 
> bit of HTTP in it and the layer differentiation here is irrelevant. Both are 
> layer three VPNs. IPsec can also work as a layer 4 VPN, if you use transport 
> mode. Thus any difference is irrelevant for any kind of malicious software 
> trying to attack over the/a VPN.
> 
>> 
>> Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection.  
>> Whereas IKE also uses a certificate to do the KeyExchange before logging in 
>> and then encrypting the data with ESP, so the ciphers used on ESP I feel is 
>> the comparison that needs to be made.
> As Tobias already work, that's not what is happening. RSA is extremely slow 
> compared to symmetric ciphers. RSA is only used for proving the identity of 
> the peers by use of signing and verification of a signature. DH or ECDH is 
> used for the key exchange. After that, symmetric ciphers and HMACs or AEAD 
> algorithms are used for encryption and authentication. IPsec is historically 
> stronger than TLS, because it does not use Mac-Then-Encrypt, which TLS does. 
> That lead to attacks like Bleichenbacher's attack where the error handling 
> with invalid padding (and other data) in the handshakes leads to 
> vulnerabilities that can be used to decrypt data. IPsec uses 
> Encrypt-Then-Mac. Attacks like Bleichenbacher's don't work on IPsec.
> 
> Kind regards
> 
> Noel
> 
> On 19.07.2018 09:33, Christian Salway wrote:
>> Hi Robert,
>> 
>> Thank you for coming back to me.  I have a client who is pushing for VDI 
>> (HTTPS) instead of VPN (IPSEC) and I’m wondering whether there is a security 
>> standpoint I can argue or if its just as secure.  I am also limited to the 
>> native OSX/Windows VPN clients which currently support a maximum of 
>> aes256-sha256-prfsha256-ecp256-modp2048 (Windows does not support ecp)
>> 
>> Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that should a 
>> VPN client be infected with a worm, it is easier for that worm to infect the 
>> network, I’m struggling to see another security argument.
>> 
>> Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection.  
>> Whereas IKE also uses a certificate to do the KeyExchange before logging in 
>> and then encrypting the data with ESP, so the ciphers used on ESP I feel is 
>> the comparison that needs to be made.
>> 
>> I will have a read of that Cipher suites page, but if I remember correctly, 
>> it is not a comparison but a standpoint.
>> 
>> C
>> 
>>> On 19 Jul 2018, at 05:51, Robert Leonard >>  >> >> wrote:
>>> 
>>> I don't really know where to start with this article.  It appears to be 
>>> sponsored by OpenVPN, and is written from the perspective of a home user, 
>>> not a security standpoint.  I
>>> I would suggest taking a look at the documentation for the Cipher suites 
>>> rather than taking this article at face value.
>>> 
>>> https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites 
>>> 
>>> 
>>> Most importantly, what is your use case?  
>>> 
>>> 
>>> 
>>> On Wed, Jul 18, 2018 at 6:23 PM Christian Salway 
>>> mailto:christian.sal...@naimuri.com> 
>>> >> >> wrote:
>>> 
>>>I was just doing some research focusing on the security of the data over 
>>> a VPN connection - and the chap in the following link has marked OpenVPN, 
>>> which uses RSA, as being more secure than IKEv2 IPSEC
>>> 
>>>https://thebestvpn.com/pptp-l2tp-openvpn-sstp-ikev2-protocols/ 
>>> 

Re: [strongSwan] Security Comparison

[Noel Kuntze]

Hello Christian,

I have some more points to make, additionally to what you already discussed 
with Tobias.
> Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that should a 
> VPN client be infected with a worm, it is easier for that worm to infect the 
> network, I’m struggling to see another security argument.
That is entirely irrelevant and wrong. OpenVPN just puts the IP packets in its 
own transport protocoll, which to the outside looks like TLS, but it's _not_ 
TLS. They implemented their own handshake. Also, there is not a single bit of 
HTTP in it and the layer differentiation here is irrelevant. Both are layer 
three VPNs. IPsec can also work as a layer 4 VPN, if you use transport mode. 
Thus any difference is irrelevant for any kind of malicious software trying to 
attack over the/a VPN.

>
> Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection.  
> Whereas IKE also uses a certificate to do the KeyExchange before logging in 
> and then encrypting the data with ESP, so the ciphers used on ESP I feel is 
> the comparison that needs to be made.
As Tobias already work, that's not what is happening. RSA is extremely slow 
compared to symmetric ciphers. RSA is only used for proving the identity of the 
peers by use of signing and verification of a signature. DH or ECDH is used for 
the key exchange. After that, symmetric ciphers and HMACs or AEAD algorithms 
are used for encryption and authentication. IPsec is historically stronger than 
TLS, because it does not use Mac-Then-Encrypt, which TLS does. That lead to 
attacks like Bleichenbacher's attack where the error handling with invalid 
padding (and other data) in the handshakes leads to vulnerabilities that can be 
used to decrypt data. IPsec uses Encrypt-Then-Mac. Attacks like 
Bleichenbacher's don't work on IPsec.

Kind regards

Noel

On 19.07.2018 09:33, Christian Salway wrote:
> Hi Robert,
>
> Thank you for coming back to me.  I have a client who is pushing for VDI 
> (HTTPS) instead of VPN (IPSEC) and I’m wondering whether there is a security 
> standpoint I can argue or if its just as secure.  I am also limited to the 
> native OSX/Windows VPN clients which currently support a maximum of 
> aes256-sha256-prfsha256-ecp256-modp2048 (Windows does not support ecp)
>
> Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that should a 
> VPN client be infected with a worm, it is easier for that worm to infect the 
> network, I’m struggling to see another security argument.
>
> Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection.  
> Whereas IKE also uses a certificate to do the KeyExchange before logging in 
> and then encrypting the data with ESP, so the ciphers used on ESP I feel is 
> the comparison that needs to be made.
>
> I will have a read of that Cipher suites page, but if I remember correctly, 
> it is not a comparison but a standpoint.
>
> C
>
>> On 19 Jul 2018, at 05:51, Robert Leonard > > wrote:
>>
>> I don't really know where to start with this article.  It appears to be 
>> sponsored by OpenVPN, and is written from the perspective of a home user, 
>> not a security standpoint.  I
>> I would suggest taking a look at the documentation for the Cipher suites 
>> rather than taking this article at face value.
>>
>> https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites
>>
>> Most importantly, what is your use case?  
>>
>>
>>
>> On Wed, Jul 18, 2018 at 6:23 PM Christian Salway 
>> mailto:christian.sal...@naimuri.com>> wrote:
>>
>> I was just doing some research focusing on the security of the data over 
>> a VPN connection - and the chap in the following link has marked OpenVPN, 
>> which uses RSA, as being more secure than IKEv2 IPSEC
>>
>> https://thebestvpn.com/pptp-l2tp-openvpn-sstp-ikev2-protocols/
>>
>> So my question is, in your opinion, do you rate IKEv2 IPSEC more secure 
>> than an RSA encrypted VPN like OpenVPN
>>
>>
>>
>> -- 
>> Rob Leonard
>> RJL Contracting
>> Cell:  (248)  403 4817
>> E-Mail:  rjlcontract...@gmail.com 
>



signature.asc
Description: OpenPGP digital signature

Re: [strongSwan] Problem with active-active cluster and traffic handling

[Tobias Brunner]

Hi Jean-Daniel,

> I found an hint in the swanctl logs:
> 
> 07[CFG] installed HA CHILD_SA net{3} 0.0.0.0/0 ::/0 === 10.192.3.3/32
> (segment in: 2*, out: 1)
> 
> strongswan explicitly choose different segments for input and output.
> The segment where the connection was established here is the segment 1.
> 
> As it defines segment 2 for input traffic, it obviously does not works.

Why shouldn't that work?  The same thing happened in our regression
testing framework [1].  Since the hashes for ESP traffic include the
SA's SPI and destination address the SAs might be handled by different
nodes in the active-active scenario (for IKE traffic only the client's
IP is hashed), refer to [2] for some background.

Regards,
Tobias

[1]
https://www.strongswan.org/testing/testresults/ha/both-active/moon.daemon.log
[2] https://wiki.strongswan.org/projects/strongswan/wiki/HighAvailability