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
