Hey everyone, I just wanted to chime in and mention that I am also disappointed that split-mode ECH can't be implemented without the backend server being ECH aware, and this has prevented me from deploying ECH on my network.
I have a small homelab of servers that I run behind a reverse proxy, which uses the SNI extensions to direct inbound connections to the backend server, and I have wildcard DNS records setup to direct all subdomains on my network to the reverse proxy. It works great, I don't have to touch my DNS provider to add new services, but it does leak the serer names to an eavesdropper. So, I was hoping to upgrade the reverse proxy to support ECH, I was hoping that I could add an ECH record and have the reverse proxy decrypt the ClientHelloInner and forward it off to the backend server. Unfortunately, this doesn't work if the backend server doesn't support ECH as it won't know that it needs to generate the accept_confirmation and the client will mistakenly think that the handshake is proceeding with the ClientHelloOuter even if the proxy can decrypt the ClientHelloInner just fine. I'm sure I could make this work anyways, either by adding exceptions for the backends that don't support ECH or having the reverse proxy terminate the TLS connections. But I am disappointed that I couldn't realize the privacy gains of ECH without having to upgrade the backend servers first. Anyways, thank you for all the effort put into this draft, it's a great step forward for privacy. Thanks, Naomi _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
