Re: [TLS] Possible blocking of Encrypted SNI extension in China

It's important to note that the Firefox Nightly client does not implement
GREASE of any form, so only the connections to sites that are known to
support the ESNI could be blocked by this method. These connections
stick out like a sore thumb among connections from this browser since ESNI
is supported by a minority of sites.

If ECH is deployed in a client with GREASE enabled, then every client hello
from the supporting client will contain the ECH extension whether the site
supports ECH or not. The traffic from the supporting user agent would stick
out, but simple filters that check for the presence of specific extensions,
would not be able to differentiate between connections to sites with ECH
enabled and to those without ECH.

On Thu, Jul 30, 2020 at 11:18 AM Christian Huitema <huitema@huitema.net>
wrote:

>
> On 7/30/2020 8:45 AM, onoketa wrote:
> > Hi,
> >
> > The Great Firewall of China may have identified and blocked
> > Cloudflare's ESNI implementation.
> >
> > I have found that when using a TLS client hello with ESNI extension to
> > connect to servers behind Cloudflare's CDN, the connection will be cut
> > off after the whole TLS handshake is done. And then that IP address
> > will be blocked at the TCP level for several minutes.
>
>
> Thanks for the report. I think this relates to our ambivalence about the
> requirement for ESNI to not "stick out". That requirement is hard to
> meet, and designs have drifted towards an acceptation that it is OK to
> stick out as long as a sufficiently large share of the traffic does it.
> If that share is large, goes the reasoning, it would be too costly for
> censors to just "drop everything that looks like ESNI". Well, given
> actors like the Great Firewall, one wonders.
>
> -- Christian Huitema
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>