[TLS] Encrypted Client Hello - SNI leaks via public name?

2023-10-06 Thread Raghu Saxena 

Hello All,

I've been a huge proponent of ESNI (as a consumer, not developer) back 
when it was introduced as a draft, with firefox support (albeit behind a 
flag), and it being enabled for Cloudflare customers. For me (and people 
I introduced it to), the purpose was to bypass SNI based blocking 
utilized by Jio, an ISP in India. By enabling DoH, ESNI in Firefox, 
several websites previously blocked by DPI would now work. It was 
unfortunate when ESNI was "dropped" for working on ECH, since the ESNI 
trick to bypass the blocks stopped working.


However, now that ECH is nearing completion, I've been trying it out, 
and was wondering - what is the best way (as either a client / a server 
operator), to address SNI leaks? Specifically, I am concerned about the 
"public name" field in the ECHConfig. For services such as cloudflare, 
they can "hide" everything behind a single domain (e.g. 
"cloudflare-ech.com"). However, for someone who just owns a single 
domain (e.g. "hub.com"), what would the "suggested value" be?


Section 6.1.7 implies it should NOT be an IPv4 address. If I do not wish 
to leak the real domain, is it "acceptable" to use something like 
"fakedomain.com"?


If the public_name leaks domain in anyway, I think it would be quite 
unfortunate, at least for bypassing DPI-blocks. From what I understand, 
the purpose of public_name is only if the server doesn't support ECH, 
but if a client retrieved an ECHConfig, why shouldn't the client just 
skip this field? I fear it will become a situation like the initial SNI 
extension - even when websites do not need it, browsers' TLS stacks send 
it anyway, causing leakage.


For instance, in India, a popular website, let's call it "hub.com", is 
blocked via SNI. However, the website itself does NOT rely on SNI, It is 
possible to open a pure TLS connection to it via IP, it serves the TLS 
cert for "hub.com" so the handshake can be completed, and then the 
website will load as normal. I verified this by manually using "openssl 
s_client", WITHOUT SNI. But since Firefox/Chrome will always send SNI, 
the ISPs can block it.


Wondering if you guys have any thoughts about the public name field, or 
perhaps I am misunderstanding it.


Regards,

Raghu Saxena



OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted Client Hello - SNI leaks via public name?

2023-10-06 Thread Dennis Jackson 

Hi Raghu,

On 06/10/2023 10:45, Raghu Saxena wrote:
Specifically, I am concerned about the "public name" field in the 
ECHConfig. For services such as cloudflare, they can "hide" everything 
behind a single domain (e.g. "cloudflare-ech.com"). However, for 
someone who just owns a single domain (e.g. "hub.com"), what would the 
"suggested value" be?


Section 6.1.7 implies it should NOT be an IPv4 address. If I do not 
wish to leak the real domain, is it "acceptable" to use something like 
"fakedomain.com"?
The server needs to be able to answer a TLS connection for the ECH 
public name or you risk an outage if the ECHConfigs get out of sync as 
then clients will get a TLS error page if they can't get through to the 
public name.


If the public_name leaks domain in anyway, I think it would be quite 
unfortunate, at least for bypassing DPI-blocks. From what I 
understand, the purpose of public_name is only if the server doesn't 
support ECH, but if a client retrieved an ECHConfig, why shouldn't the 
client just skip this field? I fear it will become a situation like 
the initial SNI extension - even when websites do not need it, 
browsers' TLS stacks send it anyway, causing leakage.


For instance, in India, a popular website, let's call it "hub.com", is 
blocked via SNI. However, the website itself does NOT rely on SNI, It 
is possible to open a pure TLS connection to it via IP, it serves the 
TLS cert for "hub.com" so the handshake can be completed, and then the 
website will load as normal. I verified this by manually using 
"openssl s_client", WITHOUT SNI. But since Firefox/Chrome will always 
send SNI, the ISPs can block it.


If the server can answer with the correct certificate without SNI, then 
it must be the only site hosted at that IP. This means that the ISP can 
also just block the IP without any collateral damage. The same thing is 
true if ECH connections didn't expose an SNI at all, they'd stick out 
and could be blocked for that reason.


I would describe ECH primarily as a technology for improving privacy. 
Unfortunately, I don't think it's any kind of silver bullet for 
censorship resistance.


Best,
Dennis



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls