Hi, 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.
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
