Dear Raghu, The MiTM solution may works for self-host, because the user controls both the browser and the proxy node. However, it is not acceptable for public proxy, because the middle node could see all the plain traffic between the user and the target, which is a far more serious problem than the leak of SNI.
The only obstacle of my envisioned ECH-based SNI proxy is that the server side accept confirmation must be placed in the SH.random field, which will be further used to generate the master secret. As a result, the middle proxy node can't respond this confirmation on behalf of the backed server. The ECH-based SNI proxy is just a possible by-product of ECH. It's not a big problem if we can not implement such proxy. However, my real concern is the deployment rate of the current draft. The current design requires both the client and backend server to be modified to be ECH-aware. For solo web site, as the administrator has the full control and there is no inter node, they may upgrade quickly. But there are far too many sites using some proxy service, for example, Cloudflare, AWS ALB, etc. For stability consideration, service provider like AWS does not upgrade their infrastructure very quickly. If web site use AWS LB as their TLS terminal edge server, it may cost too long time to deploy ECH. Apart from technical issues, deploy ECH does almost no benefit to this business. I doubt if they are interested in ECH. On the other hand, let's recall the origin of the server side confirmation. According to the original discussion https://github.com/tlswg/draft-ietf-tls-esni/issues/274 > In the current spec, the server provides no indication of whether the inner > or outer ClientHello (CH) was used. This means the client must do trial > decryption to make this determination, which creates complexity and > potentially raises security concerns. It seems that the main consideration of the accept_confirmation is just to simplify the client side logic. This simplification may cause a slow deployment of ECH. I am wondering if it really make sense. The ECH is very complicated itself. The purpose of such an complicated protocol is to protect the privacy of the Internet, so we should in favor of the easy deployment instead of of the simplified implementation. If the simplification is the first consideration, the ECH should not be considered at all. > On Sep 11, 2024, at 15:16, Raghu Saxena <poiasdpoi...@live.com> wrote: > > By the way, you may be interested in this project: > https://github.com/quininer/nosni-proxy , which has a similar idea, but > instead to completely strip SNI, and relying on TLS interception. One could > think of an alternative, basically like the Cloudflare MiTM model you > mentioned, except self-hosted with certificates manually trusted. Then the > DoH server would return the IP of this server, which would allow an ECH-TLS > connection to it, but then performs a separate TLS handshake with the real > origin server. > > It is not as elegant as what you mentioned since now there is a need to > manually trust certificates, but could still be an approach.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
