Hacker News Reader

Comment by cimnine | Hacker News Reader

As I understand, the public key that is used for authenticity is not the same as the one being used for encryption — at least since TLS 1.3, before it depends. The scheme is known as forward secrecy. For the encryption, an ephemeral key pair is used on both sides. These pairs are only used for the Diffie-Helman (or similar) key exchange. Therefore an encrypted connection can be established, then SNI can be exchanged over the encrypted connection, and then the remote can provide the signed nonce together with it's PKI public key, with which it establishes trust respective to the SNI.

View on HN

So the encrypted connection used to exchange SNI isn't authenticated? This hides the SNI from passive eavesdroppers but not from an active MITM, no?

Good point. So there is more to it, which I didn't consider before. As I understand [1], the client uses the public key of the key pair used by the SNI to encrypt the SNI value, additionally to any TLS encryption. Only the actual SNI has the private key to decrypt the SNI value. The client must look up the public key in the DNS (I guess at least if it doesn't know the key already, which it could have in the cache).

This whole thing is still a draft RFC [2] and currently called encrypted client hello.

What I don't get: The client will have to disclose, which public key it used to encrypt the client hello / SNI value. But don't we know "all" the public keys from the certificate transparency logs? Usually a public key is only valid for a limited set of domains, so it would be easy to associate the public key used for encrypting the SNI value with the relevant service. Just look up the public key, read it's SAN or CN, and you pretty much know the SNI value. Or at least the service, which might be good enough. What am I missing?

[1] https://blog.cloudflare.com/encrypted-sni [2] https://www.ietf.org/archive/id/draft-ietf-tls-esni-15.html

> What I don't get: The client will have to disclose, which public key it used to encrypt the client hello / SNI value

Actually, not necessarily, but first...

> But don't we know "all" the public keys from the certificate transparency logs? Usually a public key is only valid for a limited set of domains, so it would be easy to associate the public key used for encrypting the SNI value with the relevant service

The keys used to encrypt ECH are distinct from keys used to prove identity. So, no only are the CT logs irrelevant (they're logs of the identity information which uses separate keys) but also you would usually choose the same keys for all the names hidden behind some particular server.

Suppose I run big.huge.example a hypothetical CDN. We can use the same public key for clown-porn.example, abortion-rights.example, huge-corp.example, government-stuff.example, even though these services may be entirely segmented internally, we're only using that key to keep the names private from everybody else. As big.huge.example we know whether a client uses clown-porn.example or abortion-rights.example, but an on-path adversary doesn't know that and the key used doesn't help them.

Still back to the encryption problem. We don't actually necessarily need to tell people which key was used. So long as the number of possible keys in use is modest they can guess:

Suppose big.huge actually has four keys in use, maybe two sets of customers on different tiers of product, maybe we're switching keys and there's an overlap period of course - we don't need clients to signal necessarily, we can just decrypt with all four keys, incurring a modest 4x decrypt performance penalty and throwing away the 3 which fail in the ordinary case.

Reply on news.ycombinator.com