<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Great read on how HTTPS works<div class=""><br class=""></div><div class=""><a href="https://robertheaton.com/2014/03/27/how-does-https-actually-work/" class="">https://robertheaton.com/2014/03/27/how-does-https-actually-work/</a></div><div class=""><br class=""></div><div class="">From reading that, if a client was only to present a ciphersuite of 3DES (or worse) in the initial ClientHello, then it really doesnt matter how strong the ServerCert is in the handshake because once the Client and Server agree on the algo to use (3DES) and symmetric key, then this is where the strength is.... I feel the world is oblivious to this fact. You can have the strongest ServerCert but unless you have a strong algorithm, it is wasted... right?</div><div class=""><br class=""></div><div class="">So if thats correct, how do you find out what the actual algorithm used for the data messaging is :/ On to my continued studies.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 19 Jul 2018, at 09:38, Tobias Brunner <<a href="mailto:tobias@strongswan.org" class="">tobias@strongswan.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Christian,<br class=""><br class=""><blockquote type="cite" class="">I am also<br class="">limited to the native OSX/Windows VPN clients which currently support a<br class="">maximum of aes256-sha256-prfsha256-ecp256-modp2048 (Windows does not<br class="">support ecp)<br class=""></blockquote><br class="">It does (at least on Windows 10), you just have to enable it via<br class="">PowerShell (see [1]).<br class=""><br class=""><blockquote type="cite" class="">Apart from IPSEC being Layer 3 and HTTP being Layer 6, meaning that<br class="">should a VPN client be infected with a worm, it is easier for that worm<br class="">to infect the network, I’m struggling to see another security argument.<br class=""></blockquote><br class="">Probably depends on the IPsec policies (e.g. if split tunneling is used<br class="">or even only single protocols/ports are allowed) and the firewall rules<br class="">on the remote end vs. what is available via HTTPS connection (e.g. if<br class="">the latter creates a VPN too or the malware can hijack the VDI somehow).<br class=""><br class=""><blockquote type="cite" class="">Data encrypted over RSA 4096 SHA-2 on paper seems a secure connection.<br class=""></blockquote><br class="">Nobody encrypts large amounts of data via RSA, if anything it's used to<br class="">encrypt a symmetric key that's then used to encrypt the data, but mostly<br class="">only for authentication (digital signatures). The key exchange usually<br class="">happens via ephemeral DH (in IKE always and nowadays in TLS too).<br class=""><br class=""><blockquote type="cite" class=""> Whereas IKE also uses a certificate to do the KeyExchange before<br class="">logging in <br class=""></blockquote><br class="">No, the key exchange is done via DH, the certificate is used for<br class="">authentication only (to prevent MITM attacks).<br class=""><br class=""><blockquote type="cite" class="">and then encrypting the data with ESP, so the ciphers used on<br class="">ESP I feel is the comparison that needs to be made.<br class=""></blockquote><br class="">The cryptographic strength of all ciphers in a cipher suite should be<br class="">consistent. For instance, using AES-256 for ESP is basically wasted<br class="">when using MODP-2048 because that has only an estimated strength of 112<br class="">bits (same for ECP-256 whose estimated strength is 128 bits).<br class=""><br class=""><blockquote type="cite" class="">I will have a read of that Cipher suites page, but if I remember<br class="">correctly, it is not a comparison but a standpoint.<br class=""></blockquote><br class="">It mainly documents the available options (there are some warnings/notes<br class="">though). [2] has some general pointers regarding the security of<br class="">IKE/IPsec connections.<br class=""><br class="">Regards,<br class="">Tobias<br class=""><br class="">[1]<br class=""><a href="https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients#AES-256-CBC-and-MODP2048" class="">https://wiki.strongswan.org/projects/strongswan/wiki/WindowsClients#AES-256-CBC-and-MODP2048</a><br class="">[2]<br class="">https://wiki.strongswan.org/projects/strongswan/wiki/SecurityRecommendations<br class=""></div></div></blockquote></div><br class=""></div></body></html>