#22 HTTPSでも見えているドメイン名 — ECHとインターネットの未来

ECH（Encrypted Client Hello）は、TLSのClientHelloをInnerとOuterに分け、実際のSNIなどを含むClientHelloInnerを暗号化する仕組みです。ただ、いざ自分のサーバーで有効にしようとすると、思っていたよりずっと奥が深い世界が待っていました。 前半では、なぜHTTPSでもドメイン名が見えていたのかをSNIから振り返り、ESNIがなぜうまくいかなかったのか、ClientHelloInner／Outer、GREASE ECHといった現在のECHの仕組みまで整理します。暗号化すれば検閲できなくなるわけではなく、中国やロシアでは残された情報を使ったブロックも実際に行われています。 後半はいよいよ運用編です。DNSのHTTPSリソースレコードでECHConfigListを配る仕組み、ECH keyを定期的にローテーションするとDNS cacheとの間で世代がずれる問>題を扱います。複数世代の鍵から復号候補を絞る1 byteのconfig_id、古いECHConfigを持ったclientへ最新のECHConfigListを返せるretry_configs、さらにnginxのssl_ech_fileでは最初に指定した鍵だけがretry用になるという暗黙的な挙動まで掘り下げます。 OpenSSLでECH keyを生成し、nginxで実際に設定すると何が必要なのか。DNSが広告するECHConfigと各Edgeに配置されたprivate keyをどう同期させるのか。CloudflareのようにDNSとTLS Edgeの両方を持つ事業者では、この複雑な仕組みをどう自動化しているのかも考えます。 最後は、サブドメインでテナントを分けるサービスではECHが何を隠せるのか、企業ネットワークのDNSやSNI監視とはどうぶつかるのか、そしてプライバシーを高めよ>うとすると、なぜ大規模なDNS・CDN事業者が有利になるのかまで話が広がります。 ECHの仕様を追っていくと、TLSだけではなく、DNS、CDN、検閲、そしてこれからのインターネットの構造まで見えてきます。インフラやCDN、TLSの運用に関わる人はぜひ本編で。 ## 関連リンク - RFC 9849 TLS Encrypted Client Hello（ECH）: https://www.rfc-editor.org/info/rfc9849/ - RFC 9848 Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings: https://www.rfc-editor.org/info/rfc9848/ - RFC 6066 TLS Extensions（SNI）: https://www.rfc-editor.org/info/rfc6066/ - RFC 9460 SVCB and HTTPS Resource Records: https://www.rfc-editor.org/info/rfc9460/ - RFC 8484 DNS Queries over HTTPS（DoH）: https://www.rfc-editor.org/info/rfc8484/ - RFC 7858 DNS over TLS（DoT）: https://www.rfc-editor.org/info/rfc7858/ - nginx ngx_http_ssl_module（ssl_ech_file）: https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ech_file - OpenSSL openssl ech: https://docs.openssl.org/4.0/man1/openssl-ech/ - Cloudflare ECH Protocol: https://developers.cloudflare.com/ssl/edge-certificates/ech/ - GFW Report — ESNI Blocking: https://gfw.report/blog/gfw_esni_blocking/en ───────────── YouTube: https://youtu.be/gMfsXOksIPc Web: https://yaoyorozu-oss.henteko07.com/ X: https://x.com/yaoyorozu_oss