暗号化して安全に保つ：ESNI、DoH、およびDoTの操作
公開: 2022-03-11インターネット上のプライバシー保護の最新の開発には、暗号化されたTLSサーバー名表示（ESNI）とDNS over HTTPS（DoH）の形式の暗号化されたDNSが含まれ、どちらもデータコレクターによって非常に物議を醸していると見なされています。
そこで、それらが存在する理由、それらが何であるかについての詳細、およびそれらがどのように機能するかの背後にあるテクノロジーについて簡単に説明します。
DNSは正しく機能する必要があります
スプリットトンネル仮想プライベートネットワーク（VPN）接続、Webプロキシ自動検出（WPAD）プロトコル、ゼロ構成マルチキャストDNS（mDNS）、リアルタイムブラックリスト（RBL）、およびその他の広く展開されている多くのテクノロジは、DNSが機能しない場合に機能しなくなります。 t正しく動作します。
利益と名声のためにインターネットを壊す
2003年までさかのぼると、インターネットユーザーは、 .comトップレベルドメイン（TLD）を運営していた会社がNXDOMAIN応答の発行を停止することを選択したときに、世界規模でDNSの重要性について学びました。 代わりに、存在しないドメインになりすまして、より多くの広告を配信し、より多くのドメインを販売し、最終的にはより多くの収益を生み出そうとしました。 予期せぬノックオン効果により、ICANNのセキュリティおよび安定性諮問委員会（SSAC）からの公開討論と忌まわしい報告が発生しました。 このプロジェクトは実際にシャットダウンされましたが、技術的な観点からは、脆弱性は存続していました。
2008年の後半、最大規模のISPの一部が、文字通りあらゆるWebサイトに対するクロスサイトスクリプティング攻撃にさまざまな手段を導入することになったときに、利益のためにDNSを操作する別の試みが公に呼び出されました。 脆弱性の性質上、プライベートネットワークでホストされ、インターネットからアクセスできないWebサイトでさえ悪用される可能性があります。
見つかった問題は、コアインターネットプロトコルではなく、特定のDNS機能の不適切な現金化によって悪化した問題です。
Paul Vixie、インターネットシステムコンソーシアム（ISC）
プロトコル自体が実際には問題の原因ではないことは事実ですが、これらのプロトコルが悪意のある攻撃者によるシステムの悪用を防止しないことも事実です。 したがって、技術的な観点からは、脆弱性は存続しました。
監視と検閲のためにインターネットを破る
2016年には、イランのISPがDNSを操作していることが確認されました。 今回は、広告を挿入する代わりに、インターネット上の上位10,000ドメインのうち139の電子メールサーバーへのアクセスをブロックしていました。 これが、これらの特定のドメインに対するサービス拒否の意図的なポリシーであるかどうかは明らかではありません。これは、中国で世界的に有名な検閲に似ています。あるいは、DNSクエリを傍受しているシステムの悪い技術的実装の単なる例です。
参照：
- ISPがDNSトラフィックを乗っ取っていますか？
- 私のISPはディープパケットインスペクションを使用しています。 彼らは何を観察できますか？
DNSが傍受されている理由を知らないことが重要です。包括的監視と検閲に関する道徳的および法的な質問を脇に置いても、これを行うために使用されるテクノロジーは、その性質上、標準に準拠しておらず、干渉する可能性が非常に高くなります。インターネットの通常の、日常の、合理的な、そして合法的な使用。
しかし、技術的な観点からは、脆弱性は存続しました。
不正な目的のためにインターネットを壊す
もちろん、独自の手段でインターネットトラフィックを傍受しようとしているのは、営利団体や政府だけではありません。 通常、ユーザーデータを盗んだり、ユーザーをだまして重要なアクセス資格情報を明らかにしたりする目的で、接続を乗っ取ろうとする犯罪者の例はたくさんあります。 最も顕著なのは、DNSキャッシュポイズニングが、ユーザーをフィッシングサイトに誘導したり、ランサムウェアを展開したり、ボットネットを展開したり、特定のWebサイトへのサービスを拒否したりするために使用されてきたことです。
誰が誰に接続するかというTLSリーク
トランスポート層セキュリティ（TLS）は、HTTPSの背後にあるテクノロジーです。HTTPSは、私たち全員が毎日依存しているHTTPの安全なバージョンです。 TLS接続を確立するには、いくつかの手順が必要です。その間に、サーバーは証明書を提示してIDを証明し、新しい暗号化キーが交換されます。
証明書の一部は非対称の公開暗号化キーであるため、サーバーに証明書を使用してそのIDを証明させることは非常に重要なステップです。
クライアントがこのキーを使用してメッセージを送信すると、関連付けられた秘密キーを所有しているサーバーのみがメッセージを読み取ることができます。 その結果、接続を傍受または傍受するユーザーはロックアウトされ、コンテンツを読み取ることができなくなります。
ただし、その最初の交換は暗号化なしで平文で行われるため、オブザーバーは常にサーバーのIDを知っています。
ドメインフロンティング
いくつかの検閲防止タイプのツールは、ドメインフロンティングと呼ばれる手法を使用して、TLSのこのリークを一定期間回避しました。 これは、HTTPS接続が確立されると、ほとんどの大規模なホスティングプロバイダーが、各HTTPリクエストで提示されるホスト名がTLSハンドシェイクで使用されるホスト名と一致するかどうかを確認しないという事実を利用しています。 プライバシーツールの観点から、これは隠されたサイトとの秘密の通信を可能にする便利な機能と見なされていました。 ホスティングプロバイダーとデータコレクターにとって、これは仕様が実装された方法の乱用と見なされていました。
これはそれ自体が脆弱性であり、AWSを含むいくつかの主要なホスティングプロバイダーによって修正されています。
標準を変更して問題を解決する：暗号化されたSNI（ESNI）
ESNIの背後にある考え方は、最初のClient Helloメッセージを含むすべてのメッセージを暗号化することにより、TLSがデータをリークするのを防ぐことです。 これにより、サーバーが提示しているサーバー証明書について、オブザーバーは完全に暗闇になります。
これを行うには、クライアントは接続を確立する前に暗号化キーを必要とします。 したがって、ESNIでは、特定のESNI暗号化キーのセットをDNSのSRVレコードに配置する必要があります。
ただし、仕様はまだ確定していないため、この詳細はまだ流動的です。 それにもかかわらず、ESNIの実装はすでにMozillaFirefoxとCloudflareによって本番環境に導入されています。
DNSの保護と暗号化
ESNIキーが傍受されることなく配信されるためには、DNSの改ざんから保護することが重要です。
1993年までさかのぼって以来、インターネットコミュニティはDNSの保護を試みてきました。 IETFは、初期の問題解決会議で次のことが議論されたと述べています。
- 許可されていない関係者へのDNSデータの開示からの保護
- データの整合性の確保
- データ発信元認証
これらの会議の結果、1997年にドメインネームシステムセキュリティ拡張機能（DNSSEC）標準が作成されました。設計チームがデータ開示のすべての脅威を明示的に範囲外に支配することを明示的に決定したため、標準はこれらの懸念の3つのうち2つに対処することを選択しました。
そのため、DNSSECは、ユーザーがDNSクエリへの回答がドメイン所有者の意図したものであると信頼できることを意味します。 ESNIのコンテキストでは、これは、受け取ったキーが改ざんされていないことを認識していることを意味します。ありがたいことに、DNSSECを使用すると、上記の多くの脆弱性がなくなります。 ただし、プライバシーは保証されないため、監視および検閲システムによって発生する問題に対して脆弱です。
残念ながら、「安全でないDNS」との完全な下位互換性があり、正しく実装するのは非常に難しいため、DNSSECの採用は非常に少ないです。 多くのドメイン所有者は、実際に見られる多数の無効で半分セットアップされた構成によって証明されるように、それを構成しようとする途中で諦めています。
DNS over HTTPS（DoH）
ウォッチャーがどのサイトにアクセスしようとしているのかを知らずにESNIキーを配信するには、DNSの盗聴を防ぐことが重要です。 そのため、暗号化されたDNS （DoHなど）が良いことであると言うのは非常に論理的で理解しやすいことです。 しかし、現在のところ、DNSは暗号化されていません。
これを変更するために、Mozilla、Google、APNIC、Cloudflare、Microsoftなどによる動きがあります。
理想的な暗号化されたユーザーエクスペリエンス
上記のテクノロジーを活用したいユーザーは、暗号化を使用する実際のUXの詳細に関して、かなり長い要件のリストを持っている可能性があります。 おそらく、彼らは次のようなものを避けたいと思うでしょう：
- 特定のDNSサービスプロバイダーを使用することを余儀なくされている（それがどれほど優れていても）、または選択が見えないか、見つけるのが難しい
- DNSを処理するデバイス上のアプリごとに異なります（たとえば、FirefoxはSafariでは検出できないものを見つけることができます）
- デバイス上のすべてのアプリは、それ自体の中に独自の安全なDNS実装を作成する必要があります
- DNSを手動で複数回構成する必要がある
- プライバシーとセキュリティを選択する必要がある
- ユーザーの同意なしに安全でない操作にフォールバックするアプリ
プライバシーを重視するユーザーは、代わりに次のことを望んでいます。
- 誰による不当な監視からのプライバシー
- 彼らが同意していないターゲット広告からの保護
- 他の視聴者への途中で変更または操作されないように、自分の公開コンテンツ（個人のWebサイトなど）を保護する
- 自分の公開コンテンツの視聴者が、単にコンテンツにアクセスするだけで問題が発生しないことを保証します
- 独自のネットワークでDNSを制御するオプションを引き続き使用するには（場合によっては、スプリットホライズンDNSは、内部リソースのスコープを内部ユーザーに維持するのに適しているため）
- DNSレベルでのフィルタリングをオプトインまたはオプトアウトする機能（Quad9、CleanBrowsing、OpenDNS Family Shieldなど）
- 簡単で手間のかからない構成（つまり、DHCP）
- 暗号化せずにDNSを使用することに同意するよう求められる
- ブラウザトラフィックだけでなく、電子メール、Slack、VoIP、SSH、VPNなどのすべてのタイプのトラフィックを保護します。
現在の暗号化の取り組み
上記の目標を持つユーザーにはどのようなオプションがありますか？
Mozillaのソリューションは始まりですが、理想からはほど遠いです。 彼らはFirefoxを保護しているだけです。 デフォルトでは、OS設定を上書きして、プロバイダー（Cloudflare）の選択を優先します。これは、安全でない状態にサイレントにフォールバックします（暗号化されたDNSがブロックされている場合など）。
Googleのソリューションはより良いアプローチです。 すべてのアプリに適用されるAndroid9以降を保護しています。 （Chrome OSの計画についてはよくわかりませんが、作業中であると思われます。）また、すべてのプラットフォームでChromeを保護していますが、セキュリティをサポートするプロバイダーを使用するようにホストプラットフォームが構成されている場合にのみ、セキュリティがトリガーされます。 これはユーザーの選択という点では優れていますが、安全でない状態に静かにフォールバックするため、理想的ではありません。
他のすべての主要なブラウザもサポートを実装しています。
ユーザーにとって理想的な状況では、ソフトウェアおよびOS開発者のより広いコミュニティは次のようになります。
- アプリケーションレベルでの新しいDNSセキュリティ機能の実装を停止します
- OSレベルでの実装を開始します
- OSレベルの構成を尊重するか、ユーザーの同意を得る
OSレベルで暗号化されたDNSを実装することで、DNSリゾルバーに対して現在使用しているものと同じ分散モデルを引き続き使用できます。 独自のネットワーク上で独自のDNSサーバーを実行し、そのリゾルバーを安全にすることができることは、集中型プロバイダーを使用する場合と同様に、オプションであり続けることは理にかなっています。
LinuxとBSDにはすでにこの機能があり、さまざまなオプションを利用できます。 残念ながら、私が知る限り、デフォルトでそれらのいずれかを有効にしているディストリビューションはありません。 glibcにプラグインするだけのものが必要な場合は、nss-tlsを確認してください。
Android 9以降でのGoogleのDNS-over-TLS実装も、すでにこれを行っています。 DNSサーバーの暗号化サポートをテストすることで機能します。 それがあれば、それを使用します。 そうでない場合は、Chromeの場合と同様に、同意を求めることなく、安全でない方法で続行します。
ほとんどのネットワークは暗号化をサポートしないDNSサーバーを使用するように構成されているため、Androidに組み込まれているソリューションは、ほとんどのユーザーにとってまだ何も変更されていないことに注意してください。 分散型が暗号化をサポートしていない場合は、集中型の暗号化DNSにフォールバックすることを提案したほうがよいかもしれません。
AppleおよびMicrosoftフレーバーデバイスの場合、暗号化されたDNSのサポートは、この記事の執筆時点ではまだ正式に提供されていません。 Microsoftが2019年11月に暗号化されたDNSをサポートする意向を発表したことで、Appleがすぐに続くことを願っています。
暗号化されたDNSの回避策
ローカルで実行できるプロキシの形式でいくつかの回避策があります。 これらを使用すると、ユーザーのコンピューターは暗号化されていないDNSを自分自身に話し、次に暗号化されたDNSを使用するように構成されているプロバイダーに話します。 これは理想的な解決策ではありませんが、回避策が進むにつれて、それはまともです。
この記事を書くためのインスピレーションは、非常に安定していて、たくさんのベルとホイッスルがあり、クロスプラットフォームであるDNSCryptプロキシです。 古いDNSCryptプロトコルに加えて、新しいDNS over TLS（DoT）およびDNS over HTTPS（DoH）プロトコルをサポートします。
Windowsユーザー向けに、Simple DNSCryptと呼ばれるインストーラーとGUIがあります。これは、機能が完備されており、非常に使いやすいものです。
私はそれをお勧めしますが、世界はおそらくまだ準備ができていないことに注意してください。時々、それを無効にする必要があるかもしれません（たとえば、お気に入りのカフェやLANでキャプティブポータルを使用する必要がある場合）パーティ）。
他のオプション
さらに、暗号化されたDNSをサポートし、クロスプラットフォーム（Windows、MacOS、Linux on ARM / Raspberry Pi）であり、洗練されたWebインターフェイスを備えたTechnitiumDNSサーバーがあります。 これは、この問題に固有のソリューションというよりも、万能のツールであるため、「その他」の下にあります。 （自宅でRaspberry Pi DNSサーバーを実行する場合は、おそらく良い選択です。以下のコメントで、Raspberry Pi DNSサーバーを試してみる人々からのフィードバックを聞きたいと思います。）
AndroidまたはiOS（iPhone、iPadなど）デバイスには、1.1.1.1アプリもあります。これにより、Cloudflare暗号化DNSサービスを介してすべてのDNSクエリが強制されます。 Intraなど、より柔軟なアプリもあると聞きましたが、まだテストに時間を費やしていません。
もちろん、FirefoxとChromeの両方で暗号化されたDNSを有効にすることもできます。上記で説明したすべての注意事項に注意してください。
DNSの信頼性：ジョブナンバーワン
インターネットプライバシー技術については多くの論争があります。 ただし、セキュリティとプライバシーの対策を実装する場合、問題のテクノロジーは主に秘密を守ることではありません。 それは、信頼性を確保し、他の人の行動にもかかわらずテクノロジーが正しく機能し続けることを保証することです。 ただし、プライバシーセーフガードのないテクノロジーが悪いのと同じように、適切に実装されていないセーフガードは状況を悪化させるだけであることに注意する必要があります。