Hi, > On Sep 4, 2024, at 11:28, Raghu Saxena <poiasdpoi...@live.com> 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. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
