How HTTPS Handshake Happens
As others have already pointed out, this explanation focuses on the RSA key exchange, which has been deprecated. It&#x27;s not recommended for use with the current line of protocols (TLS 1.2 and earlier) and it&#x27;s been completely removed from TLS 1.3 (work in progress, but close to being finished). The key weakness of the RSA key exchange is that session encryption keys are transported over the network encrypted with the server&#x27;s public key. When the server&#x27;s private key is compromised in some way, the attacker can passively decrypt all traffic, they can also &quot;go back in time&quot; to decrypt all previous conversations they might have recorded and kept.<p>For a more secure handshake approach, consider the Diffie-Hellman key exchange, which is a way for two parties to agree on a secret number (a very large number when used for encryption, of course) that third party can&#x27;t discover from looking at the network traffic. It&#x27;s a very simple and intuitive algorithm; there&#x27;s a great video that explains it here: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=YEBfamv-_do" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=YEBfamv-_do</a> Today, we generally use the ephemeral elliptic curve DH variant (ECDHE), which has better security characteristics and works much faster.<p>However, DH is not sufficient, you must also authenticate the other party. Otherwise you could be negotiating your key exchange with the attacker and not the real recipient. This is where public cryptography comes in. After the key exchange, both parties use their private keys to sign the transcripts of the entire conversation up until that point. When this is verified you know that (1) you&#x27;re talking to the right person and (2) that you have a secret (session keys) that you can use to efficiently protect the conversation.<p>Disclosure: I am the author of Bulletproof SSL and TLS, already mentioned in another comment here. Feel free to ask me anything.