[strongSwan] Security Comparison
christian.salway at naimuri.com
Thu Jul 19 15:01:37 CEST 2018
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
As taken from  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.
 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 ).
>> 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).  has some general pointers regarding the security of
> IKE/IPsec connections.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users