Christian, I believe the issue that we are currently observing with "blocked ECH" is specific to how public SNI is constructed. A given CDN uses a certain pre-defined public name for all ECH enabled resources - hence an inline filtering party that wants to prevent ECH can match on that specific public name and presence of ECH extension in ClientHello.
Ed, I don't think there is much ECH spec can do about this - versatility of public name construction depends on many internal operational details of the hosting service. On top of that, public SNI is used by some intermediaries to perform their own DNS lookup and replace destination IP. This is often done to optimise traffic routing by cloud security providers as the closest CDN node from cloud security provider perspective could be different than the one resulting from client DNS lookup. It is also a technique to prevent certain kinds of domain fronting attacks without invasive TLS inspection. Hence, replacing public SNI with a random string that would not be resolvable to the correct destination is likely to create another set of access issues. Best Regards, Yaroslav On Sat, Nov 16, 2024 at 2:12 AM Christian Huitema <huit...@huitema.net> wrote: > > On 11/15/2024 9:57 AM, Raghu Saxena wrote: > > Hey Ed, > > > > On 11/16/24 1:08 AM, evasi...@yandex.ru wrote: > >> Actually, it is not a problem for them, not at all. > >> As I stated in the message that you did not copy in the quote: they > >> would filter out any Hello that has nested InnerHello. > >> It is pretty automatic solution. As soon as implemented on DPI, this > >> feature would not need any configuration or manual intervention. > >> Only people that upgraded their browser would be punished (not the > >> whole population) - they would have to look how to downgrade the > >> browser or disable feature. > > > > Well yes, any new TLS extension can be directly blocked by DPI if they > > want. I think practically the best way around such stuff would be to > > use existing TLS stuff which is too mainstream, e.g. an HTTPS proxy. > > Ed, > > This issue was flagged from the beginning of the SNI/ECH effort. Having > a specific TLS extension makes the usage of ECH stand out. But on the > other hand, it is pretty difficult to design an ESNI/ECH extension that > does not standout, is compatible with standard TLS processing, and is > not subject to attacks -- like for example replay attacks. Instead of > trying to have ECH engineered to be discreet, the WG picked a design > with robust engineering, and then argued that "you do not stand out if > everybody does it". Suppose that every TLS Client Hello contains an ECH > extension, whether they want to encrypt the SNI or not. If we had that, > then your hypothetical censor would have to block every TLS connection, > and that would be a very hard choice. > > The ECH draft specifies a greasing mechanism that achieves exactly that. > Clients can insert an ECH extension with fake values -- but only the > client and the front end server know it is fake. The on-path attackers > cannot tell -- they just see an ECH extension with a bunch of random > bytes in it, which is not different from an ECH extension with encrypted > data in it. If they block these packets, they are going to block way > more that their desired targets. > > You assume that the censorship will be deployed before the next browser > versions are deployed, and that a browser that systematically grease the > ECH extension would become immediately unusable. But blocking new > versions of browsers will be very costly for the censor -- users do want > the security, features and bug fixes of the new versions. We have no > evidence of that happening yet. > > -- Christian Huitema > > > > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
