HTTPS、DoH、ECH、VPN はそれぞれ別のものを隠す

すでに HTTPS、DoH、ECH を使っているブラウザに VPN を足しても、三つの保護が一つに積み重なるわけではなく、何を誰が観測できるかが変わるだけだ。どの仕組みも、それぞれ別のやり取りから別の当事者を外し、どれも何かを残していく。役に立つ問いはどれが最も強いかではなく、どの観測者を外したいのかであり、その答えがトンネルがそもそも役立つかを決める。残った観測者を比べるほうが、機能の一覧より役に立つ。

四つの仕組み、四つの観測者

四つの関係と、それぞれが外に置こうとする当事者から始める。下の表は私がレビューで使っているもので、会話に技術ではなく観測者の名前を言わせるからだ。

この表の価値は、書かないと決めたことにある。仕組みを順位づけもしないし、四つすべてを使えば四つの観測者がすべて外れるとも主張しない。自前のエッジで TLS を終端しているクラウドのウェブアプリは、そのやり取りについてはアクセス網から守られており、トンネルを足してもこの性質は改善しない。トンネルが変えられるのは、外側のパケットをどの網が見るか、そして経路上にいるのが今どの事業者か、という点だ。

HTTPS が実際に隠すもの

HTTPS は、クライアントと証明書が示す端点の間のアプリケーションのやり取りを守る。宛先のアドレスは隠さず、接続が起きたことも隠さず、ECH が関与しない限り名前も隠さない。証明書の検証は保護の一部であり、その周りの儀式ではない。

VPN がその TLS を終端する必要はなく、転送する出口をアプリケーションの認証済み端点として扱うべきでもない。出口が復号する設計なら、それは別の信頼の表明を持つ別のアーキテクチャだ。

DoH と ECH が動かすもの、残すもの

DoH は DNS のやり取りを HTTPS のリゾルバに移すので、ローカル網のリゾルバの代わりにそのリゾルバがあなたの問い合わせを見る。これは現実的で限定的な変化であり、選んだリゾルバが問い合わせをその後接続するアドレスと関連づけられる当事者になるという点で、RFC 8484 が論じているまさにその相関にあたる。暗号化された転送は、応答する側が問い合わせを知らないことにはしない。

ECH は ClientHello の機微な部分を守り、経路上の受動的な観測者が意図したサーバ名を読めないようにする。対応する配備と、サーバおよび網による受け入れに依存するうえ、他の経路はそのまま残り、宛先アドレスは見えたままで、DNS が名前を明かすこともある。

ECH がやらないもう一つのことは、自らを証明することだ。TLS 1.3 を使う接続は ECH が受け入れられた証拠ではなく、対応しないサーバに ECH を提示するブラウザは静かに退く。プロトコルの版から推測するのではなく、接続の実際の状態を確認する。

この比較全体に共通する形は、各仕組みが自分の層で検証され、どれも他の仕組みの成功によって検証されることはないという点だ。

VPN が動かすもの、加えるもの

ウェブのトラフィックが VPN に入ると、アクセス網は個々のアプリケーション接続ではなく VPN の相手との外側のやり取りを見て、VPN の事業者はその先の経路上に位置を占める。これは信頼の境界を移すことであり、取り除くことではない。事業者は、内容が端から端まで暗号化されたままでも、あなたがどの宛先に届くのかを見る。それが改善かどうかは、この二つの当事者のどちらをより信頼していないかで決まる。

その間も、アプリケーションの HTTPS と意図したリゾルバの保護はそのままにしておく。トンネルは証明書の検証の代わりにはならず、通信がトンネルを通るからといってリゾルバの保護を切るのは、制御を代替なしに外すことだ。

要件から選ぶ

実際の要件を書き出すべきで、それが設計を決める。私的な資源への入場、管理された出口点、アクセス網の特定の脅威、端末の認可は、四つの異なる必要であり四つの異なる答えを持ち、公開クラウドのアプリだけを使う企業でも、認可とデータの扱いは決めなければならない。追加の層は適切でありえても、互いに置き換えられるものではない。より複雑な接続は匿名性の測定ではなく、それ自体が安全の論拠でもない。

ECH の仕様である RFC 9849 は、この仕組みが何を覆い何を覆わないかを知るために読む価値があり、手を付けない経路について正直だ。各仕組みが外す観測者で比べ、その観測者を書き出し、追加の層がそれに対処しているかを決める。その観測者がすでに脅威モデルの外にいたのなら、トンネルは利益のない費用だ。