Hi, Raghu, > On Sep 10, 2024, at 00:35, Raghu Saxena <poiasdpoi...@live.com> wrote: > > I'm still not sure what specific benefit this has compare to a TLS HTTPS > connect proxy + HTTP CONNECT. > > In both cases, we need to modify the User-Agent behavior a little bit (e.g. > tell browser to use HTTPS proxy, vs. configure a "custom" DoH server to do > the hijacking), and configure a remote server a bit (setup HTTPS proxy, vs. > setup the ECH-based SNI proxy). > > In fact, I'd argue looking at the common HTTP User-Agents today, the support > for configuring an HTTPS proxy is already very widely supported, so it would > have a better reach immediately. > > I'd like to hear if you have any ECH specific benefits of this proposed proxy > design, maybe I'm missing something.
It could simplify the configuration. Suppose we need to proxy traffic according to one list. If we use the classical CONNECT methods, we need install some web extension like Proxy Switcher in chrome. Then we need to setup the proxy server's host/port and auth data. Then we need setup the proxy rule list. It's too complicate to use for normal people who are not familiar with computer or network. If we can use the ECH-based proxy, we could transfer all these tasks to the server side. The only task that the end user need to do is to setup a custom DoH URL, which is personalized to this user only with auth data in the URL. The proxy list is maintained on the server side, and the server works as both DoH and ECH-based SNI proxy. Once the DoH has been set, the browser will query A/AAAA/ECH records for one domain. The server will response "fake" records according to the proxy list. The public_name of the fake ECHConfig will be used to associate to the target domain and for auth. But the current draft requires the backed server to be ECH-aware, which makes it impossible to implement something like ECH-based SNI proxy. All in all, the ECH-based SNI proxy is not the biggest problem. The biggest problem, in my opinion, is that the backed need to be upgraded to deploy ECH. With the help like Cloudflare, we could deploy HTTPS/HTTP2/HTTP3 without change the backend server. As a result, the deployment rate has been very quick. Big thanks to Chris, I have read through the discussion on https://github.com/tlswg/draft-ietf-tls-esni/issues/274 The reason for the change of backend server is to respond the accept confirmation to simplify the client side implementation without stick out the ECH traffic. The cost of simplifying is to upgrade the server. It is impossible to deploy ECH without changing the client side, and the whole design of ECH is very complicated. If we want to deploy ECH, why we prefer a more simplified client with a must be modified server side? As the ECH its self is already, would it be more easy to deploy ECH if we choose the more complicated client solution without changing backend server? I don't know. Just FYI~ Regards.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
