Hey 涛叔,Sorry for the late reply. Was taking time to read through and try to understand completely what you were saying.
On 9/5/24 17:53, 涛叔 wrote:
Yes, the native HTTPS Proxy with CONNECT has similar feature. However, the ECH based SNI Proxy still has some benefits. First, we setup one DNS over HTTPS server, and let the user agent use the DoH server. Second, we setup the client-facing ECH server as SNI proxy. .... If we can implement ECH-based SNI proxy, we can "deploy" ECH to all TLS server without upgrading the HTTPS server software of the backend server. All we need is to do some kind of "DNS hijacking". This hijacking will result in no security problem because the client-facing server will only see the ClientHelloInner and can not monitor the real plain traffic under TLS. If we can implement ECH-based SNI proxy, the user agent setup will be simplified as much as possible. All it needs to do is setup a proper DoH server, and let all other configuration in the remote side of ECH client-facing server and DoH server.
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.
Regards, Raghu Saxena
OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
