[strongSwan] Security Comparison

[Christian Salway]

Now I understand how the handshake works (maybe), I used Wireshark to see the cipher suites and the selected one for HTTPS to our companies website

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

As taken from [1] to mean:

TLS - the protocol used
ECDHE - the key exchange mechanism
RSA - the algorithm of the authentication key
AES - the symmetric encryption algorithm
256 - the key size of the above
GCM - the mode of the above
SHA384 - the MAC used by the algorithm

AES_256_GCM being the cipher

This seems like a strong encryption for message data, and dare I say, stronger than the default ciphers available to native VPN clients on OSX and Windows 10.  Although both seem adequately strong for todays standards.

[1] https://scotthelme.co.uk/https-cheat-sheet/ <https://scotthelme.co.uk/https-cheat-sheet/> 


> On 19 Jul 2018, at 09:38, Tobias Brunner <tobias at strongswan.org> wrote:
> 
> Hi Christian,
> 
>> 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)
> 
> It does (at least on Windows 10), you just have to enable it via
> PowerShell (see [1]).
> 
>> 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.
> 
> Probably depends on the IPsec policies (e.g. if split tunneling is used
> or even only single protocols/ports are allowed) and the firewall rules
> on the remote end vs. what is available via HTTPS connection (e.g. if
> the latter creates a VPN too or the malware can hijack the VDI somehow).
> 
>> Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection.
> 
> Nobody encrypts large amounts of data via RSA, if anything it's used to
> encrypt a symmetric key that's then used to encrypt the data, but mostly
> only for authentication (digital signatures).  The key exchange usually
> happens via ephemeral DH (in IKE always and nowadays in TLS too).
> 
>>  Whereas IKE also uses a certificate to do the KeyExchange before
>> logging in 
> 
> No, the key exchange is done via DH, the certificate is used for
> authentication only (to prevent MITM attacks).
> 
>> and then encrypting the data with ESP, so the ciphers used on
>> ESP I feel is the comparison that needs to be made.
> 
> 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).
> 
>> I will have a read of that Cipher suites page, but if I remember
>> correctly, it is not a comparison but a standpoint.
> 
> It mainly documents the available options (there are some warnings/notes
> though).  [2] has some general pointers regarding the security of
> IKE/IPsec connections.
> 
> Regards,
> Tobias
> 
> [1]
> https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients#AES-256-CBC-and-MODP2048
> [2]
> https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180719/0cc90f63/attachment.html>