[jwcrux]

I love seeing comics like this that aim to show concepts in simple ways. Kudos!

Worth noting that "The Handshake" episode [0] covers the key exchange using RSA. This has the downside that it doesn't support forward secrecy, meaning if an attacker ever compromises the server's private key they can retroactively decrypt traffic they previously captured.

It's more common these days to use an ECDHE exchange in which the client and server exchange keys that are generated just for this session (or at least, they should be [1]) and use those to generate the "shared secret".

In fact, in TLS 1.3 ECDHE is the only key exchange mechanism. [2]

The server then uses its long term keypair corresponding to the certificate to sign all the handshake messages that were seen previously [3].

[0] https://howhttps.works/the-handshake/

[1] https://raccoon-attack.com/

[2] https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/

[3] https://tools.ietf.org/html/rfc8446#section-4.4.3

[hannob]

Yeah, it's a bit of a pet peeve of mine to complain that so many people who start "easy crypto explanations" basically explain things that are outdated or sometimes simply wrong.

This is not how HTTPS works, it's how HTTPS used to work long ago. What makes it even more frustrating is that they do mention that there are different versions and the very latest version is 1.3, but don't mention that what they just explained is a variant of TLS 1.2 that most people have deprecated long ago.

[iso1631]

> variant of TLS 1.2 that most people have deprecated long ago.

I agree with most of your post, but not this part. 1.2 is still out there on a large number of sites, but even worse 1.0 and 1.1 are there on many of the most popular sites. Google.com for example, despite all major browsers now having deprecated 1.0 and 1.1.

[tialaramex]

It's true that most sites support TLS 1.2, but between clients and servers the no-FS RSA kex is rarely negotiated. Any vaguely modern browser can do better given the opportunity and only a very small fraction of sites that do TLS 1.2 (and so would actually talk to a modern browser out of the box) don't prefer ECDHE.

My guess is that we're a year or three, or one major related security incident from browsers either removing RSA kex or gating it behind default-off enterprise feature switches. We know it's a bad idea, but a bunch of organisations that lay people think of as "secure" (like banks) do it anyway, mostly for really stupid reasons. If an incident makes it necessary to pick between real security versus imagined, the browsers are going to pick real as they have before, even if that means First Bank of Springfield doesn't work in your browser. Normal churn means the banks are slowly adopting Forward secret capable upgrades anyway, so that's where my other timeline comes from. Three years from now products that once treated RSA kex as the bees knees will have aged out, capex justification to replace them is just "it's rusted" rather than explaining to somebody who control your budget that you picked a deliberately poor key exchange method because you're bad at your job and trusted a sales person.

[kyawzazaw]

Check this out!

https://maggieappleton.com/api

[beaker52]

This is really great. I was flapping around trying to explain this to my curious, yet-not-technical wife just the other day. This'll do nicely as a follow up, thank you!

[upofadown]

Well it does have a separate "generate shared secret" step. Perhaps it is an amalgamation of both methods...

[tialaramex]

This is a simplification of a subsequent step. The Pre Master Secret is actually used to derive several keys (exactly how many varies depending on other choices in the handshake) which are all shared between the client and server.

For example, both client and server can send messages at the same time or asynchronously, and so they need separate keys for each direction. Let's call these two keys A and B, the client encrypts data with A, sends it, and the server decrypts with A, but the server encrypts data with B, sends that and the client decrypts with B. If they just use the same keys lots of things go wrong, including an adversary can now give the client back messages it just sent and it can decrypt them believing they are from the server.

[deepstack]

probably ed25519 would be better if you don't need to support old servers: https://medium.com/risan/upgrade-your-ssh-key-to-ed25519-c6e...