search

tlswg / draft-ietf-tls-esni

TLS Encrypted Client Hello
https://tlswg.github.io/draft-ietf-tls-esni/#go.draft-ietf-tls-esni.html
Other
231 stars 56 forks source link

Use Session ID and/or PSK in Client Hello to transfer enctypred SNI #605

Closed 0x391F closed 4 months ago

0x391F commented 4 months ago

Sorry, I sent this message in mailing list on July 26, 2023, but nobody discover it.

Is it possible to use Session ID in Client Hello, which is obsoleted in TLS 1.3, to transfer enctypred SNI? If it looks random enough, attacker could't distinguish Session ID is encrypted SNI or not.

It may have some restrictions, for example, the SNI maybe couldn't longer than Session ID (32 bytes).

So we could also additional use TLS 1.3's PSK. It may break the limit of 32 bytes when using Session ID and able to transfer the whole SNI, but it may more distinguishable compare with using Session ID. In thi situation, Session ID is a "signal" that ECH is enabled, the real SNI is in PSK.

ekr commented 4 months ago

A few points here:

  1. You can't use session ID to carry ESNI because the minimum size of ESNI far exceeds 32 octets. Just the public key in the HPKE is 32 octets or more. Moreover, there's no point in having encrypted SNI in TLS < 1.3 because the certificate is in the clear.

  2. It's not really possible to conceal the fact that you are sending something that is vaguely ECH shaped, because the CH is going to be really enormous compared to a regular CH, and in particular quite a bit larger than the usual PSK. This is one reason why we do GREASE ECH.

In any case, we already have a nontrivial amount of deployment experience, so I think it's too late to consider this kind of reboot of the specification. If you'd like to propose a different design in a separate draft, that's of course still possible.

0x391F commented 4 months ago

Moreover, there's no point in having encrypted SNI in TLS < 1.3 because the certificate is in the clear.

Yes, this is the reason why use Session ID - it has been obsoleted in TLS 1.3. 

2. It's not really possible to conceal the fact that you are sending something that is vaguely ECH shaped, because the CH is going to be really enormous compared to a regular CH, and in particular quite a bit larger than the usual PSK. This is one reason why we do GREASE ECH.

No, in fact, in this situation, we only need to transfer encrypted SNI, not the whole client hello. AFAIK domian name couldn't longer than 63 btyes, the whole length should't longer than 253 bytes, it may not too big in most situation.

ekr commented 4 months ago

We started out with designs that just encrypted the SNI but it turned out to be too difficult to protect against active attacks, which is why we now encrypt the entire ClientHello. I don't see why the situation would be any different with this way of adding the encrypted SNI to the CH.

0x391F commented 4 months ago

How about using "early data"? It's it possible to transfer encrypted client hello in "early data", and Session ID indicate that in fact it is a ECH.

richsalz commented 4 months ago

How about using "early data"? It's it possible to transfer encrypted client hello in "early data", and Session ID indicate that in fact it is a ECH.

And what is the benefit of that?

What is it you are trying to do? Fit ECH into something smaller so the clientHello message doesn't grow much?

ekr commented 4 months ago

How about using "early data"? It's it possible to transfer encrypted client hello in "early data", and Session ID indicate that in fact it is a ECH.

This would also be a major change. We're trying to get this document finished, so absent there being something really wrong with this design I think we should be focused on shipping rather than looking at alternatives. TLS is extensible, as is ECHConfig, so if you were to write up a full proposal that people agreed was better, there's nothing precluding us considering it in the future.

sftcd commented 4 months ago

+1 to ekr's points here, such designs were considered but superseded by the current design, so I think this issue would be best closed as I know of nobody else who would like to change to something other than the current design. I certainly have no such plans, and would be surprised if other implementers had.

That said, I do have a couple of students experimenting with what we're calling "stealthy ECH" and who are thinking about such designs afresh. However, that's very much not intended to be a replacement for ECH, rather that work is to see if we can figure out some possible fallbacks (for co-operating clients/servers) should ECH "fail," i.e. not see widespread deployment for technical or political reasons. I'll be happy to discuss that work later in the year when the students have had a chance to work on it.

0x391F commented 4 months ago

How about using "early data"? It's it possible to transfer encrypted client hello in "early data", and Session ID indicate that in fact it is a ECH.

And what is the benefit of that?

It will be helpful to bypass goverment's censorship, for example, some country, such as China may block ECH in the future, like how they treat ESNI (they have been block ESNI), so use somehing like PSK might more undectable.

What is it you are trying to do? Fit ECH into something smaller so the clientHello message doesn't grow much?

See above.

x0wllaar commented 4 months ago

As it is, ECH will still have a ton of distinguishers, like having crypto.cloudflare.com in the outer SNI anyway. It's also enough to block DoH to completely break ECH.

The real way to resist censorship here is to make ECH mandatory for a significant part of the internet, so that it becomes too big to block (although this does not always work sadly).

Also, we have an actual case where a big censorship target (Telegram) tried to hide behind CDNs. In the end, the CDNs (well, a couple million of Amazon/Azure IPs) ended up blocked in Russia for some time, and then almost all of them disabled domain fronting. I'm not sure whether anyone wants to go this route again, only this time with a more official implementation of the same domain fronting idea.

Andrew-419 commented 4 months ago

How about using "early data"? It's it possible to transfer encrypted client hello in "early data", and Session ID indicate that in fact it is a ECH.

And what is the benefit of that?

It will be helpful to bypass goverment's censorship, for example, some country, such as China may block ECH in the future, like how they treat ESNI (they have been block ESNI), so use somehing like PSK might more undectable.

What is it you are trying to do? Fit ECH into something smaller so the clientHello message doesn't grow much?

See above.

IIRC TLS 1.3 is blocked in China too, so this is much more complex than just trying to reduce the footprint of ECH.

davidben commented 4 months ago

I've heard this claim before but I'm pretty sure it's an urban legend, stemming from people conflating TLS 1.3 and early iterations of ESNI. Enough of the Internet now is TLS 1.3 that, if this were true, far far too many things would be broken that those of us who work professionally in the space would definitely have run into it by now. Remember that blocking TLS 1.3 does not mean you get TLS 1.2. It means the connection does not work.

Andrew-419 commented 4 months ago

You prompted me to check the original stories as it is a little while since this came up. There's a helpful post from ISoc from August 2020 at https://www.internetsociety.org/news/statements/2020/internet-society-blocking-tls-1-3-in-china-makes-the-internet-less-secure/ that in turn references coverage of this in ZD-Net. It seems that the Great Firewall was blocking traffic using TLS 1.3 in combination with eSNI. [As an aside, I'm not convinced that overblocking was a major concern for the Great Firewall :-) ]

ekr commented 4 months ago

Not seeing any more support for this, so closing it.