3 ms·
Since this takes human operations out of the loop on the origin for certs I could see an opportunity to add one more privacy step until ECH is universally suppo
by LinuxBender 2y ago
Since this takes human operations out of the loop on the origin for certs I could see an opportunity to add one more privacy step until ECH is universally supported on all the things. Their origin side daemon could sign a cert with a name that Cloudflare trusts but does not in any way match the domains on the origin server. Thus anyone intercepting traffic can not tell via ESNI handshake what domains that origin server is serving. The translation to the actual domain(s) could occur on the origin side. Alternatively their daemon could configure Wireguard so that all traffic is encapsulated in a VPN between Cloudflare and the origin, or perhaps some WAN optimized VPN daemon that can re-route around circuit outages similar to how tinc-vpn can be configured and one of the WAN optimizer daemons that uses FEC and multiple streams.
- ashconnor 2y agoECH TLS Encrypted Client Hello - https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-08 https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-08 https://blog.cloudflare.com/encrypted-client-hello https://blog.cloudflare.com/encrypted-client-hello
- LinuxBender 2y agoYes I mentioned ECH. Correct me if I am wrong but none or almost none of the origin servers support it. Openssl, nginx, apache, haproxy, caddy AFAIK do not support it. The flow I am talking about is from Cloudflare to the origin server.