【ECH / Encrypted Client Hello】フィルタリング殺しの暗号化技術がChrome, Chromiumに実装された件

ECH / Encrypted Client Helloとは？

ECH / Encrypted CLient Hello（暗号化されたClient Hello）は、アメリカの大手CDNであるCloudFlareなどが中心となって策定され、TLS 1.3においての拡張機能として標準化されました。
普段私達が何気なく使っているhttpsですが、（https://で始まるURL、よく見ますよね？）これによる暗号化をより範囲を広げ、強化する機能です。
大まかに言うと、「ネットで見てる先をわからなくする」技術です。仮に通信を盗み見られても、「どこと通信しているのか」をも暗号化し、わからなくすることで、より安全になります。

❓より詳しく

ECHは元々はESNI / Encrypted SNI¹という名前でした。
現在すっかり普及したhttps (サイトのURLにも昔はhttp://でしたが、https://がつくものが今では大多数でしょう）ですが、これはサイトを見ているとき、そのサイトのサーバーとの通信を暗号化し、盗聴されても読み取れないようにする、というものです。

例えばサイトへのログインなどでは、サイトにパスワードを送信するわけですが、Free Wi-Fiは悪意ある人がテザリングなどでそれっぽくなりすましている場合があります。その場合、通信の間に入れてしまうので、通信内容を見れてしまうのです。
そこでhttpsによって暗号化されていれば、見ても無意味な文字列になっている...というわけです。
しかし現状ではhttpsでも「通信先の名前」（ドメイン）までは暗号化できていません。郵便でいうところの「宛先」のようなものですから、それを暗号化するのは簡単ではないです。郵便局が困っちゃいます。
そしてそれを暗号化してしまおうというのが「ESNI」というもの。

SSL/TLS通信²では、最初に「暗号化・復号化するための鍵」や「どのように暗号化するのか」などをやり取りしなければなりません。そうしないと暗号化したやり取りができません。

そのため最初には3-Way Handshakeと呼ばれるやり取りをします。これによって通信を確立するわけです。その最初の段階がClientHelloというわけ。そしてその中にSNIと呼ばれる情報があり、これが先程言った、暗号化されていない「通信先の名前」にあたり、ドメインが書かれています。

これを暗号化するのがESNI。そして拡張して先程のClientHelloまで暗号化したのが今ではECH / Encrypted Client Helloと呼ばれているものになります。
ECHにより全くドメインが平文でやり取りされない（＝盗聴されても見ているサイトがわからない）ためには、DNSとの接続においてDoT/DoHとDNSSECに対応している必要があります。（DNSとの間の通信で攻撃されると意味がない）

仕組みについてはこのサイトが詳しいですが、要するに
実際のClientHelloは暗号化で格納され、また互換性のためにまた別の平文で見れるダミーのClientHeloという2つが同時に送られるということ。

❗ブラウザで有効化してみよう

このECH、ブラウザ・サイト、双方が対応している必要があります。
前まではFireFoxくらいしか対応していませんでしたが、Chrome 105においてECHが実装されました！ ただし実験機能という位置づけであり、これはユーザーが有効にする必要があります。
chrome://flags/#encrypted-client-helloから、Enabledにしてください。

再起動を促されますので再起動することで有効化完了です。Androidでも同様の方法で有効化可能です（iOSは対応していません。）
なお、ECHはDNSを利用した技術であり、DNSの暗号化技術であるDoH/DoTが出来ていないと無意味になります。DNSを設定からDoH/DoTに対応しているものにするなど、設定しておきましょう。（Google Public DNSの8.8.8.8 / 8.8.4.4や、CloudFlareの1.1.1.1 / 1.0.0.1など）
こちらも対応できているかがこちらで確認できます。（Secure DNSのところ）

🔍実際に暗号化されているのを確かめてみる

この検証では、defo.ieというサイトを使用してみようと思います。ECHがしっかりとブラウザで適用されているかを確認することのできるサイトです。

まずは、Encrypted ClientHelloを無効化してアクセスしてみます。そうすると..？

このようにSSL_ECH_STATUS: not attemptedとなっており、ECHは適用できていないことがわかります。パケット監視ソフト³、WireSharkを用いて通信内容を覗いてみましょう。

ご覧の通り、Server Name: defo.ieと通信先が見えるようになっていることがわかります。これが一部の国では検閲のため使われるなど、セキュリティ上の懸念となっているわけです。

---

では次は、ECHを有効化してアクセスしてみましょう！

SSL_ECH_STATUS: successとなっています！適用されているようですね。また、SSL_ECH_OUTER_SNI: cover.defo.ie SSL_ECH_INNER_SNI: defo.ieと書かれています。これは「実際に君がアクセスしてるのはdefo.ieだよ。ただ、外から盗聴したときに見えるのはcover.defo.ieだよ。という意味。さて、実際にWireSharkにて確認してみましょう。

確かにServer Name: cover.defo.ieになっていることが確認できます！
実際にはこの欄は、CloudFlareといったあらゆるところ見られるような巨大CDNなどの名前になるわけです。そうすればとても推測などできないというわけ。

また、この意味不明な文字列。これが暗号化されたInnorClientHelloです。この中に実際のSNIも格納されているわけです。

✅利点

フリーWiFiは危険じゃない

フリーWiFiはセキュリティ的に危ないとよく言われますが、
それはフリーWiFi内での通信は不特定多数の人に見られる可能性⁴があるからです。

ただし、今では情報の中身についてはいわゆる「https」の普及によって、暗号化されていることで基本的に安全になっています。（覗いても第三者には解読が不可能な文字列になっている）
例えば、httpsで保護されていればパスワードを入力して送信しても盗まれて流出することはありません。

そして、ECHは更に通信先も暗号化されることで、今までhttpsによって保護されているサイトでも、「どこと通信しているのか」は見えてしまっていたのが、
今後はこれも見えなくなります。
ドメインにもセンシティブな情報（特定の会社のドメインが多ければ「働き先か？」などが予測できる）があることがあるので、これが暗号化されるとこれも分からなくなります。

情報統制・検閲の回避につながる

情報統制を行う国の政府は時にSNIによって接続先を判断し、アクセスを遮断しています。
これが暗号化されることでできなくなるので、いわゆる情報統制への対処法になりうるでしょう。
しかし、これを対策するため中国ではいわゆるグレートファイアウォールにより、ESNI/ECHを使った通信を全て怪しいとみなし遮断されています。韓国でも同様に遮断されています。

また、これはフィルタリングソフトや、ペアレンタルコントロールにも影響を与えます。
SNIでの接続先の参照は検閲と同じく、フィルタリングにも使われているのです。こういった面での懸念もあります。

しかし、DNSSECが普及していない

ECH自体はCloudFlareが中心となり普及のため活動しており、そのおかげで標準化にもこぎつけたところです。
しかし、これにより完全な通信の安全が担保されるには、DNSSECとDoT/DoHの存在が不可欠です。仮
また、IPアドレスからの逆引き（そもそもSNI自体が一つのIPアドレスで複数のドメインを扱うためのものなのではあるが...）などの穴もあるにはあります。
いずれにせよ、今後のセキュリティの発展に期待しましょう。

1. Server Name Indicationの略。直訳すると「サーバー名表示」。 ↩

2. httpsに使われている技術のことで、httpsはhttp+SSL/TLSで成り立っている。現在の最新は2018年8月10日に公開されたTLS 1.3 ↩

3. WireSharkは正確に言うと「ネットワーク・アナライザ・ソフトウェア」と言い、ネットワーク上の通信を確かめるためのソフトウェア。アプリが想定通りの挙動をしているか、ネットワークのトラブル時に原因を特定するためなど、至ってまともなエンジニアリングに使われている技術。時々「通信盗聴用ソフト」として言われる時があるが、それはあまりにも誤解である。 ↩

4. いわゆる中間者攻撃のこと。詳しくは調べてみて。 ↩