HN Theater @HNTheaterMonth

When reading the title, this came to mind: https://youtu.be/YEBfamv-_do (Diffie-Hellman key exchange explained using paint).

There is also this one by Computerphile: https://youtu.be/NmM9HA2MQGI

Here is another video from "Art of the Problem" that uses the same analogy that really helped me understand this better:

https://www.youtube.com/watch?v=YEBfamv-_do

The paint example is what made it click for me too. via this video . https://www.youtube.com/watch?v=YEBfamv-_do

Interesting, thanks for sharing (I too was curious).

This is my favorite video on Diffie-Hellman key exchange which is a slightly different problem (sharing a secret, without the constraint of dividing the key): https://www.youtube.com/watch?v=YEBfamv-_do (oh, hey, same channel! Guess I'll need to check out more videos from here!)

And here is an elegant explanation of the Diffie-Hellman protocol https://www.youtube.com/watch?v=YEBfamv-_do

⬐ fermienrico

Absolutely amazing. This is one of those instances when analogy is exact (mixing colors) and doesn't dilute the original motif (One way function).

⬐ thijsvandien

Another explanation that is not as technically accurate, but really clicked on me to understand how it's possible to establish private communication in the open, is the following:

You put your secret message in a box, put a lock on it that only you have the key to, and send it to the other party. They, unable to open it, put on a second lock of their own, and send it back. You remove your lock, leaving theirs, and once again send it to the other party. Finally, they remove their lock too and can open the box without anyone else having had that possibility.

What can also be inferred from this, is how DH is vulnerable to a man-in-the-middle attack. Someone involved in the delivery could pretend to you to be the other party and to them to be you.

There's also this. The paint mixing analogy starts around 3 minutes in.

https://www.youtube.com/watch?v=YEBfamv-_do

⬐ None

None

Interesting explanation - thanks for sharing. I find it easier to visualise, through colours of paint, for a high-level metaphor of the DH key exchange process, which may be useful - https://youtu.be/YEBfamv-_do?t=2m48s

If you haven't seen it, there's a pretty neat video that outlines how public-key cryptography works using paint colors [1]. It's focused on Diffie-Hellman key exchange, but it's a great intro for beginners to be able to visualize the concepts, and I think helps provide some context before jumping right into the GPG command line.

[1] https://www.youtube.com/watch?v=YEBfamv-_do&t=2m25s

⬐ helloasdfasdf

The colour analogy is a bit off, despite being a good way to get the basis of the protocol across.

The problem is with what he explains as a one-way function: https://s3.amazonaws.com/static.kaytor.ca/screenshots/incorr...

While it's true that it's not possible to derive the input colours given only the output, in the case of DH both the output and the yellow (common) colour is available to Eve, which makes it trivial to reverse the other input.

The actual property a one-way function needs to be suitable for DH is to remain hard to reverse when both the output and one of the inputs is known.

⬐ WhoBeI

Their 8 part series on cryptography is also very good.

https://www.youtube.com/watch?v=lICOtR078Gw&list=PLB4D701646...

As others have already pointed out, this explanation focuses on the RSA key exchange, which has been deprecated. It's not recommended for use with the current line of protocols (TLS 1.2 and earlier) and it'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's public key. When the server's private key is compromised in some way, the attacker can passively decrypt all traffic, they can also "go back in time" to decrypt all previous conversations they might have recorded and kept.

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't discover from looking at the network traffic. It's a very simple and intuitive algorithm; there's a great video that explains it here: https://www.youtube.com/watch?v=YEBfamv-_do Today, we generally use the ephemeral elliptic curve DH variant (ECDHE), which has better security characteristics and works much faster.

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're talking to the right person and (2) that you have a secret (session keys) that you can use to efficiently protect the conversation.

Disclosure: I am the author of Bulletproof SSL and TLS, already mentioned in another comment here. Feel free to ask me anything.

⬐ schoen

Can you suggest any compelling resource to encourage people to switch away from RSA key exchanges in their server configurations, assuming that they're not asking us? (When people ask me, I point them to the Mozilla configuration generator at https://mozilla.github.io/server-side-tls/ssl-config-generat...)

I just noticed two days ago that my bank, for example, uses an RSA key exchange and I was kind of dismayed about the non-forward-secret sessions. But I don't know what I could tell them as a customer that would make them care about this problem. (I don't think my theoretical knowledge of why their key exchange method is bad will really help, compared to some kind of industry or governmental guidance that says "this technology is obsolete and everyone should stop using it", or, even better, "this technology is obsolete and banks should stop using it".)

⬐ ivanr

I think SSL Labs could be an option, but its penalty for configurations that don't support forward secrecy is not strong enough. That's my fault (sorry!), but I'll hopefully fix it soon.

Ultimately, I think the only way to kill the RSA key exchange is via a protocol revision, which is exactly what they've done in TLS 1.3. Sure, it will take a few years, but it will happen eventually.

I think banks like the RSA key exchange because it allows them to deploy transparent TLS traffic decryption via private key sharing.

⬐ schoen

> I think SSL Labs could be an option, but its penalty for configurations that don't support forward secrecy is not strong enough.

It's amazing how strong a motivation a grade or ranking can sometimes be. We saw this a lot with EFF's privacy practices report

https://www.eff.org/who-has-your-back-government-data-reques...

where companies were sometimes willing to make real changes to earn an extra star.

> I think banks like the RSA key exchange because it allows them to deploy transparent TLS traffic decryption via private key sharing.

Oh yeah, that was something they complained about a lot with mandatory PFS in the TLSWG. :-(

Why do they need this for their consumer-facing sites, though? The theory over in the working group was about monitoring activities of bank employees on third-party web sites (I thought), rather than about monitoring activities of bank customers on the bank's own web site.

⬐ britcruise

Hey Ivan, thanks for sharing my video :)

⬐ ivanr

Hey, thanks for creating it. It's fantastic!

⬐ Xeoncross

> After the key exchange, both parties use their private keys to sign the transcripts of the entire conversation up until that point.

I don't see how this proves anything as a MITM attack would be able to do this just fine. Perhaps you mean this is where the CA-Cert comes in as the client can then verify that the process has not be tampered as the attacker can not sign with the matching CA-cert?

⬐ ivanr

No, the attacker can't sign anything using either client's or server's private keys. The process assumes these keys haven't been compromised. But, as a client, you do need to be able to reliably verify that the private key used for the signing genuinely belongs to the server. That's where certificates come in. In the certificate there is a public key. The server has a matching private key. As part of the handshake, the client verifies that the two match. That's why the MITM can't interfere.

But that's only where the chain of trust begins. As the next step, the client must now verify that the certificate had been issued by a CA they trust, and they do that by recursively verifying the signature of each issuer in the certificate chain (along a few other things) until they reach a CA that's trusted by default (because it's in the client's root store).

Just to complicate things further: TLS 1.2 and earlier support many key exchange options, which implement key agreement and authentication in potentially different ways. For example, some key exchanges don't use certificates but rely on pre-shared keys. Another example, in the RSA key exchange the server proves ownership of the private key by being able to successfully handshake, and so on. TLS 1.3 made some improvements in this area and the key exchange process has been streamlined. My point here is that there are many other details to take into account, but I am trying to keep my explanations at a higher level.

⬐ schoen

As someone who's help create a certificate authority and helps people get certificates from it every day, I'm kind of amazed at how few people who are getting certificates know what they're for or could explain what they do, even at the level of "certificates protect site visitors against man-in-the-middle attacks". (Or even know that they possess private keys, which they've promised in their subscriber agreements to safeguard.)

⬐ thr0w__4w4y

Ivan - I have your book, I've read it (at least a year ago, if not more) - so sorry if this is covered and/or I should know the answers, but:

(1) Seems like the argument against RSA is "what happens when the server's private key is leaked?" But with ephemeral DH, it also requires private keys to be protected (now 2 of them!), these being signing keys. So isn't it simply trading one problem for another? Or perhaps the difference is that at least with DH, in theory only /new/ sessions can be attacked (MitM impersonating going forward), but older sessions can't be opened up.

(2) Doesn't this mean that now the client needs a keypair & certificate? Otherwise, how does the client sign? And where does the client key pair come from? I'm pretty sure my browsers (i.e., clients) don't have their own keys & certificates.

TIA for answering my silly questions.

⬐ ivanr

(1) Yes, that's the argument against the RSA key exchange. I can break into your server, bribe or blackmail your system administrators, or take you to court to get your private key. This last case happened to Lavabit, for example.

Handshake integrity validation is always done, no matter which key exchange is used, and with effectively throw-away keys. So there's nothing there to protect long-term; those keys are going to disappear after the TLS session is complete.

The key difference with the RSA key exchange is that it forever leaves behind a piece of data encrypted with the private key (that can be recovered). Other key exchange methods use signatures, which have no value once the TLS session is complete.

(2) Public cryptography is not well suited for dealing with high volumes of data. Abstracting a little bit, handshake integrity is done via a HMAC, using keys that are negotiated for each session separately. Once the session is complete, these keys also disappear.

⬐ hueving

Note that in most browser to web server communications that both sides don't usually sign the conversation during authentication, only the server does. This means the client knows it's the right server but the server doesn't know who the client is, which is why you have to use a username/password in some crappy web form for authentication.

⬐ ivanr

Right. As you say, on most web sites the client is anonymous as far as TLS is concerned, and the server proves its right to respond to the requested hostname with a CA-backed certificate (and proof that it holds the private key that corresponds to the public key embedded in the certificate).

To drill deeper in the the handshake, however, both client and server do sign the initial handshake (with the final negotiated session secret, effectively). The idea is that you need to ensure that the handshake hasn't been tampered with. An active network attacker could have changed the original TLS connection request (ClientHello) to force usage of a particular cryptographic component they know how to break. For example, SSL v2 had no handshake protection which is why someone in control of the network could always enforce the weakest encryption (only 40 bits).

⬐ bengale

Would you recommend your book for someone with a rough understanding of how this works, but very light on detail?

⬐ ivanr

In short, yes! But just to be 100% sure, I would encourage you to read the detailed table of contents (it's can be downloaded along the free first chapter from the book's homepage, in the right column: https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ ).

One important point I would make is that my book doesn't dissect the protocols in detail. There is only one chapter (about 50 pages) dedicated to the protocol and I wanted to cover it at a level that virtually everyone will want to understand. If you want more than that, hundreds of pages won't be enough; in the end you will have to dive into the dozens of RFCs, and so on. What I do do, is point to those RFCs so that you at least know where to find the additional documentation. IIRC there are more than 600 links in the book and they can all be found here (automatically extracted from the DocBook XML manuscript): https://fsty.uk/bulletproof-ssl-and-tls

My realisation was that, in practice, actual protocol flaws are not the weakest link. Instead, there are hundreds of different problems everywhere in the ecosystem, so you need to look at the issues in the protocol, but also in the certification authorities and the certificate issuance process, SSL/TLS stacks, clients, browsers, servers, libraries, development and configuration practices, and so on. My book is thus very practical and examines all these aspects that you need to understand at at least some level if you want to use TLS.

BTW, please note that I will send you a free digital copy of the book if you buy the paperback _anywhere_ and send me the receipt. The benefit of the digital edition is that it's typically much more current than the paperback. In fact, the digital edition is fully up to date at the moment. I published a complete revision just yesterday.

⬐ WhiteSource1

How much lag and delays do SSL handshakes take and what are some ways to remain secure while minimising latency.

⬐ ivanr

Technically, a full handshake adds 2 RTTs, and it's only one RTT on a successful resumption. In practice, I think that most modern browsers currently use something called False Start, where they cheat and send some data early, so even the full handshake takes only one RTT. False Start works only with a well-configured server.

In TLS 1.3, the full handshake is one RTT without any tricks; resumption also. There is also a 0-RTT resumption, but it sacrifices security for speed. Lots of people are unhappy about it.

⬐ novaleaf

curious, do you know where I can find out how proxy servers negotiate/relay SSL without eavesdropping? I'm trying to figure out how secure proxies communicate but can't find details :)

⬐ ivanr

Well, the default is that TLS traffic cannot be decrypted or interfered with without detection, so no eavesdropping. A proxy can relay traffic at the TCP layer, but it won't be able to see any of the information (except for the parts that are not encrypted).

If you do want to eavesdrop, you have several options. For one, you can terminate the TLS traffic, access it, then create another entirely separate TLS session to send it elsewhere. This is easier with a reverse proxy, in which case the proxy is the server. If you want to transparently intercept client-initiated sessions you have to install your root CA key in each client device.

Going back to servers, another option is private RSA key sharing, which allows for passive decryption, but works only with the RSA key exchange. Finally, you can also play with session ticket keys. If you share those, and enable session tickets, you'll also be able to passively decrypt. This last option works even with DHE/ECDHE key exchanges.

⬐ novaleaf

thanks, i don't want to eavesdrop, but looking for technical docs on how a https proxy server really works :) .. something i can use to learn how to implement one.

⬐ MyDogHasFleas

Ivan, I bought your book "Bulletproof SSL and TLS". It's excellent, and I recommend it to those who are charged with building, deploying, or managing a real world deployment that includes TLS.

⬐ schoen

I have yet to buy it, but I've recommended it to five or six people who said they wanted to understand TLS, because I've never heard of someone being disappointed by it!

I think I'll buy my own copy today. :-)

⬐ schoen

As an update, I've ordered a copy and look forward to reading it.

I recommend beginning at the fundamentals. For example here's a video that walks through Diffie Hellman, so that anybody can follow, you can probably sprint through it, but by taking it slow they avoid accidentally forgetting anything important.

https://www.youtube.com/watch?v=YEBfamv-_do

Grasping the fundamentals means that when it comes to policy decisions (e.g. in the management of certificates) you can see what the consequences of a particular decision are, rather than just hoping that whoever proposed that policy knew what they were doing.

For example, I think a lot of people today use Certificate Signing Request (CSR) files without understanding them at all. But once you have a grounding in the underlying elements you can see at once what the CSR does, and why it's necessary without needing to have that spelled out separately.

Or another example, understanding what was and was not risky as a result of the known weakness of SHA-1. I saw a lot of scare-mongering by security people who saw the SHA-1 weakness as somehow meaning impossible things were now likely, but it only affected an important but quite narrow type of usage, people who understood that could make better, more careful decisions without putting anybody at risk.

For idiots like myself, I found this video, Public key cryptography - Diffie-Hellman Key Exchange (full version), to be completely enlightening using mixed colors to explain the most basic features of a cryptography algorithm.[0]

[0] https://www.youtube.com/watch?v=YEBfamv-_do

This is a great pair of videos that intuitively explain Diffie-Helman key exchange and then the RSA algorithm in a way that requires no previous knowledge of cryptography:

"Public key cryptography - Diffie-Hellman Key Exchange" https://www.youtube.com/watch?v=YEBfamv-_do

"Public Key Cryptography: RSA Encryption Algorithm" https://www.youtube.com/watch?v=wXB-V_Keiu8

Good coverage of the fundamentals before attempting a deeper understanding of PGP specifically.

made a video inspired by this work: https://www.youtube.com/watch?v=YEBfamv-_do

⬐ baby

Ah that was a cool video! I was showing that to my girlfriend the other day to explain DH to her :)