[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.salway at naimuri.com <mailto:christian.salway at naimuri.com>
> A: Naimuri Ltd, Capstan House, Manchester M50 2UW
> 
>> On 20 Jul 2018, at 12:27, Noel Kuntze <noel.kuntze+strongswan-users-ml at thermi.consulting <mailto:noel.kuntze+strongswan-users-ml at thermi.consulting>> 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 <rjlcontracting at gmail.com <mailto:rjlcontracting at gmail.com> <mailto:rjlcontracting at gmail.com>> 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 <christian.salway at naimuri.com <mailto:christian.salway at naimuri.com> <mailto:christian.salway at 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:  rjlcontracting at gmail.com <mailto:rjlcontracting at gmail.com> <mailto:rjlcontracting at gmail.com>
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180720/7a1c0f43/attachment.sig>