Dear 涛叔,

On 9/10/24 11:00 PM, 涛叔 wrote:
If we can use the ECH-based proxy, we could transfer all these tasks to the server side. The only task that the end user need to do is to setup a custom DoH URL, which is personalized to this user only with auth data in the URL. The proxy list is maintained on the server side, and the server works
as both DoH and ECH-based SNI proxy.

Once the DoH has been set, the browser will query A/AAAA/ECH records for one domain. The server will response "fake" records according to the proxy list. The public_name of the fake ECHConfig will
be used to associate to the target domain and for auth.

You make a good point, thanks for clarifying. It is an interesting idea that the DoH operator can basically control the proxies which would be used per domain effectively. I'm going to give this idea a bit more thought, seems interesting.

By the way, you may be interested in this project: https://github.com/quininer/nosni-proxy , which has a similar idea, but instead to completely strip SNI, and relying on TLS interception. One could think of an alternative, basically like the Cloudflare MiTM model you mentioned, except self-hosted with certificates manually trusted. Then the DoH server would return the IP of this server, which would allow an ECH-TLS connection to it, but then performs a separate TLS handshake with the real origin server.

It is not as elegant as what you mentioned since now there is a need to manually trust certificates, but could still be an approach.

Regards,

Raghu Saxena

Attachment: OpenPGP_0xA1E21ED06A67D28A.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Reply via email to