[TLS] Re: ECH Proxy Mode

[涛叔 <[e-mail]>]

Hi,
> On Sep 4, 2024, at 11:28, Raghu Saxena <[e-mail]> wrote:
> 
> On 9/3/24 10:52 PM, 涛叔 wrote:
>> This idea was derived from my attempt to implement encrypted TLS SNI Proxy. The SNI
>> does not only expose privacy information, many ISP use it to block certain web site.
>> Even though the current draft of ECH works to protect the ClientHello, it can only
>> protect the sites that deployed the ECH.
>> 
>> If we can adjust the current design and let the client-facing generate and response
>> the accept_confirmation signal, we can make ECH everywhere without upgrading any of
>> current TLS backend server. Which means the client-facing can work as an encrypted
>> TLS SNI Proxy.
> 
> I'm trying to understand what exactly your use-case here is. Wouldn't a naive HTTPS Proxy w/ CONNECT be sufficient?
> 
> E.g. if we have the proxy domain `https://myproxy.com` , and the website we want to connect to is `https://supersecret.com`, then assuming a classic HTTPS Proxy running on `myproxy.com`, the Client would make a TLS handshake to `myproxy.com` and reveal the Proxy SNI, however once the TLS handshake with the proxy is complete, the `CONNECT` to `supersecret.com` will be inside the TLS tunnel, so it will be private.
> 
> I think this would be sufficient, since even in the split-example with ECH you mention, the `public_name` of the first client-facing server will be visible anyway.


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.

Third, in our DoH server, we "hijack" the A/AAAA record for the original server and point it to the ECH client-facing server,
and add the fake HTTPS/SVCB record to indicate the user agent that the original "support" ECH.

Finally, when the user agent try to negotiate the TLS session to the backend server, it looks up both the A/AAAA and HTTPS
records from the DoH server. Then the user agent will connect to our client-facing server (work as SNI proxy).
Since the user agent also derives our fake HTTPS record with ECH config, the user agent will try to connect the client-facing
server using this config with a proper generate config_id and public_name. We can dynamically generate this ECHConfig
and associate the real original domain name to some dynamic public_name.

When the client-facing server accept the ECH handshake, it can decrypt the real domain name of the original server, and then
it will works as a normal SNI-proxy and try to connect to the backend server using the ClientHelloInner.

As the server has no idea of this ECH-based proxy, it will respond a normal ServerHello with normal random field. Once our
ECH client-facing the ServerHello, it has to respond the accept_confirmation on behalf of the original. However, the current
draft requires using the last 8 bytes of random in ServerHello to indicate the accept_confirmation, which can not be modified
by the client-facing server, and this design makes it impossible to implement this ECH-based 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.