[TLS] Re: ECH Proxy Mode

[Raghu Saxena <[e-mail]>]

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