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 <huit...@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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
