Private Diffie/Helman Tokens [LWN.net]

Private Diffie/Helman Tokens

Posted Dec 5, 2024 21:47 UTC (Thu) by daroc (editor, #160859)
In reply to: Private Diffie/Helman Tokens by eharris
Parent article: Let's Encrypt sets date for ending OCSP support

Certificate Authorities are a solution to the problem of distributing public keys between everybody who might want to communicate over the internet in a way that ensures that not just anyone can claim to have the key for any domain. If your group can already distribute public keys amongst themselves, then you actually don't need LetsEncrypt. But if you want someone from outside your group to be able to trust that your key corresponds to the legitimate owner of a domain ... well, that's the problem that having Certificate Authorities is meant to solve.

to post comments

Private Diffie/Helman Tokens

Posted Dec 5, 2024 22:21 UTC (Thu) by eharris (guest, #144549) [Link] (11 responses)

No....we don't distribute keys. The whole idea behind Diffie/Helman is that there are NO keys ever published. D/H means that users share tokens...and then at encrypt or decrypt time they calculate the secret key...and then throw the key away once it has been used.

Keys only exist for a very very short time. The next communication uses DIFFERENT keys...also for a very short time. There are no "public keys" ever used in our group.....ever. My question still stands...Why do we need "Let's Ecrypt"?

Private Diffie/Helman Tokens

Posted Dec 5, 2024 22:34 UTC (Thu) by dskoll (subscriber, #1630) [Link]

You don't need Let's Encrypt if your communications are purely internal.

However, if you have a public facing server that needs to "prove" its identity, to the extent that such proof boils down to "Let's Encrypt has verified as best it can that this server is really foo.example.com, or is in the *.example.com domain, and hey, we hope the server admins haven't negligently leaked their private key...", then you need Let's Encrypt or some other CA.

Private Diffie/Helman Tokens

Posted Dec 5, 2024 22:34 UTC (Thu) by roc (subscriber, #30627) [Link]

How are you preventing MitM attacks?

Private Diffie/Helman Tokens

Posted Dec 5, 2024 22:34 UTC (Thu) by pitb0ss (subscriber, #137324) [Link] (4 responses)

It has more to do with knowing that the DH token you are negotiating a short lived key with is at least somewhat "authentic". On the web through let's encrypt this is done through proving ownership (or at least control) over the domain, or server that the host name points to. Without that assurance you could just as easily use my DH token for Google's or your bank's. You should verify it's correctness at some level. The domain model isn't perfect but it's good enough.

Private Diffie/Helman Tokens

Posted Dec 6, 2024 13:10 UTC (Fri) by epa (subscriber, #39769) [Link] (3 responses)

It does seem a bit circular. If my browser connects to foo.com then whoever is at the other end does control the foo.com domain in some sense (at least from my view of the network). So if the only thing proven by the certificate is "they control the domain", that's redundant. In practice Let's Encrypt requires that they controlled the domain at some point in the past, and so you can be reasonably sure the same person still controls it today. Indeed, you could argue for a *minimum* age of certificates, so that if an attacker took control of a domain and managed to get certificates, enough time would have passed for somebody (hopefully) to notice the attack.

Private Diffie/Helman Tokens

Posted Dec 6, 2024 13:16 UTC (Fri) by daroc (editor, #160859) [Link]

Let's Encrypt also checks that whoever requests a certificate appears to control the domain from multiple endpoints in different countries. So it is at least harder for an attacker to intercept all of Let's Encrypt's viewpoints than it is to intercept your single viewpoint.

Private Diffie/Helman Tokens

Posted Dec 6, 2024 13:18 UTC (Fri) by dskoll (subscriber, #1630) [Link]

... at least from my view of the network

I think that's the key attack that SSL certificates are supposed to prevent. LetsEncrypt goes to some lengths to avoid being misled when it verifies domain ownership. While not perfect, the measures make it a bit harder for attackers to use DNS or BGP spoofing attacks against LetsEncrypt.

Private Diffie/Helman Tokens

Posted Dec 9, 2024 2:18 UTC (Mon) by azumanga (subscriber, #90158) [Link]

It's a lot easier for me to "take control" of the wifi hotspot in a coffee shop you are sat in, and pretend to be foo.com, than it is to trick Let's Encrypt, which tries connecting from multiple networks across the internet.

Private Diffie/Helman Tokens

Posted Dec 5, 2024 23:40 UTC (Thu) by excors (subscriber, #95769) [Link]

Diffie-Hellman guarantees you have a secure channel between you and somebody else, but it tells you nothing about who that somebody is. Maybe it's the person you wanted to talk to; maybe it's a MitM who's relaying messages between the two of you; maybe it's an attacker who's completely faking the responses. You need another protocol to figure out who the person on the other end of the channel is, and TLS certificates (like Let's Encrypt) are one way of implementing that.

Private Diffie/Helman Tokens

Posted Dec 6, 2024 12:38 UTC (Fri) by alarsen (subscriber, #4585) [Link]

Diffie/Helman is completely orthogonal to X.509 certificates – a certificate, e.g. from LetsEncrypt, is used to prove your identity, whereas D/H is used for key exchange when encrypting communication.

So yes, you don't need LetsEncrypt to encrypt internal communication, but you do need LetsEncrypt (or some other CA) when you securely identify yourself ("you" being an Internet host) to other entities *even* if no encrypted communication is going to take place.

Private Diffie/Helman Tokens

Posted Dec 6, 2024 13:50 UTC (Fri) by cesarb (subscriber, #6266) [Link]

> My question still stands...Why do we need "Let's Ecrypt"?

You need it to protect against active attackers.

Doing a Diffie-Hellman is enough to protect against passive attackers, who can only observe but not modify the traffic. But against an active attacker, who can modify the packets being exchanged, that's not enough; the attacker can replace the "tokens" (which, from what I understand, are what you are calling the "public key" part of the Diffie-Hellman key exchange) with some of their own, and sit in the middle pretending to be the other side of the exchange. To prevent that, you have to somehow validate that these "tokens" actually came from the real other side of the exchange.

That's where systems like Let's Encrypt fit: they validate that the "public key" received from the peer actually came from them, and not from an attacker intercepting and modifying the connection.

Private Diffie/Helman Tokens

Posted Dec 8, 2024 6:17 UTC (Sun) by ssmith32 (subscriber, #72404) [Link]

> My question still stands...Why do we need "Let's Ecrypt"?

TLDR; For authentication. It's not a hard question.

If you don't understand that, you shouldn't be managing security infrastructure. So I really hope your question is about a hypothetical system.. and not an actual setup.

You can claim the auth TLS provides is not great, but it does provide it. DH key exchange does not.