DNS暗号化について

ドメインネームシステム（DNS）はインターネットのアドレス帳に相当します。cloudflare.com、あるいはその他のサイトにアクセスする際、ブラウザーは DNSリゾルバーに対しそのウェブサイトの IP アドレスを要求します。この時のDNSクエリと応答は残念なことに通常無防備です。DNSを暗号化することにより、ユーザーのプライバシーとセキュリティは向上します。この記事では、DNS を暗号化する 2 種類の方式、つまり DNS over TLS (DoT) および DNS over HTTPS (DoH) について説明します。また、その仕組みについても説明します。

ドメイン名を IP アドレスに変換するアプリケーションでは、通常、DNS を使用します。これは通常、アプリケーションを作成したプログラマーが明示的に実行させるわけではありません。プログラマーは単にフェッチ（たとえば"https://example.com/news"）を書き込むのみで、ソフトウェアライブラリーが "example.com" を IP アドレスに変換することを想定しています。

その背後で、ソフトウェアライブラリーが外部の 再帰的DNSリゾルバーを検出して接続し、DNSプロトコル（下図を参照）の交換を行い、アプリケーションが要求した名前の変換を実行します。外部DNSリゾルバーの選択と、プライバシーやセキュリティ提供の有無については、アプリケーションではコントロールできません。これらは、使用しているソフトウェアライブラリーとソフトウェアを実行するデバイスのオペレーティングシステムが提供するポリシーに依存します。

外部DNSリゾルバー

オペレーティングシステムは通常、Dynamic Host Configuration Protocol (DHCP) を使用してローカル ネットワークからリゾルバーのアドレスを取得します。ホームネットワークおよびモバイルネットワークでは、通常、インターネットサービスプロバイダー（ISP）のリゾルバーを使用することになります。企業ネットワークでは、リゾルバーの選択は通常、ネットワーク管理者の管理下にあります。必要であれば、そのデバイスを制御できるユーザーは、特定のアドレス、例えばGoogle の 8.8.8.8 や Cloudflare の 1.1.1.1などのパブリックリゾルバーアドレスにオーバーライドすることができますが、ほとんどのユーザーは、コーヒーショップや空港で公共の Wi-Fi ホットスポットに接続する際に、リゾルバーを変更する手間をかけることはありません。

外部リゾルバーの選択は、エンドユーザーのエクスペリエンスに直接影響を与えます。ほとんどのユーザーはリゾルバーの設定を変更せず、ネットワークプロバイダーのDNSリゾルバーを使用しています。その相違が最も顕著で明白に現れるプロパティは、名前の変換の速度と精度です。プライバシーやセキュリティを向上する機能は、直ちに目には見えない場合があるでしょうが、他のユーザーがブラウジングアクティビティをプロファイリングしたり妨害したりすることを防御するのに役立っています。このことは、物理的に近接する誰もがワイヤレスネットワークトラフィックを捕捉したり復号化し得る公共Wi-Fiネットワークにおいては特に重要です。

未暗号化状態のDNS

DNSは1987年に作成されて以来、ほとんどの場合未暗号化状態にありました。デバイスとリゾルバーの間に存在するあらゆる任意の人は、DNSクエリや応答をスヌープしたり、改ざんすることも可能です。これには、ローカルWi-Fiネットワーク内の任意の人、インターネットサービスプロバイダー（ISP）、トランジットプロバイダーが含まれます。その結果、あなたがアクセスしているドメイン名があばかれ、プライバシーが侵害される可能性が生じます。

何をのぞき見られるのか？ここで、ホームネットワークから接続しラップトップPCで取得した下記のネットワークパケットキャプチャーを見ていきましょう。

次の事項が観測可能です。

• UDPソースポートは、未暗号化DNSの標準ポート番号である53です。なので、UDP ペイロードは DNS 応答である可能性が高いでしょう。
• このことは、ソースIPアドレス192.168.2.254がDNSリゾルバーであり、宛先IPアドレス192.168.2.14がDNSクライアントであることを示唆しています。
• UDPペイロードは事実上DNS応答として解析でき、ユーザーがtwitter.comにアクセスしようとしていたことがうかがわれます。
• 仮に、後で104.244.42.129または 104.244.42.1への接続があった場合、それは「twitter.com」に向けられたトラフィックである可能性が高いと言えます。
• 仮にこのIPに対する暗号化されたHTTPSトラフィックがDNSクエリによりさらに多く実行された場合、それはWebブラウザーがそのページから追加のリソースを読み込んだ可能性を示唆しています。これで、ユーザーがtwitter.comにアクセスしているときに閲覧していたページをあばける可能性があるということになります。

DNSメッセージは保護されていないため、次のような攻撃が起こり得ます。

• クエリがDNSハイジャックを実行しうるリゾルバーに送信される可能性があります。たとえば、英国では、Virgin MediaとBTは、存在しないドメインに対して偽の応答を返し、同時にユーザーを検索ページにリダイレクトします。このリダイレクトが可能となる理由は、コンピューター/携帯電話がISP提供のゲートウェイ ルーターによる DHCP を使用して広告されたDNSリゾルバーを盲目的に信頼していることによります。
• ファイアウォールはポート番号のみを頼りに、暗号化されていないDNSトラフィックを容易に傍受、妨害、改ざんすることが可能です。プレーンテキスト検査は可視性目標を達成するための特効薬ではないことに注意してください。DNSリゾルバーは常にバイパス可能だからです。

DNSの暗号化

DNS を暗号化することにより、スヌーパーがDNSメッセージをのぞき見たり、転送中に破損させたりすることは困難になります。Webが未暗号化状態のHTTPから暗号化されたHTTPSに移行したときのように、DNS自体を暗号化する DNSプロトコルへのアップグレードが可能となりました。Webを暗号化したことで、プライベートでセキュリティの高い通信や商取引を活発に行うことが可能になりました。DNS を暗号化することにより、ユーザーのプライバシーはさらに強化されます。

ユーザーとリゾルバー間の DNS トランスポートを高いセキュリティで保護する 2 つの標準化されたメカニズムが存在します。一つはDNS over TLS（2016年）そしてもう一つはDNS Queries over HTTPS（2018年）です。ともにTransport Layer Security（TLS）を基礎としています。TLSはまた、HTTPS を使用し、ユーザーとウェブサイト間の通信を高いセキュリティで保護することにも使用されています。TLSでは、サーバー（ウェブサーバーかDNSリゾルバーかを問わず）が証明書を使用し、クライアント（あなたのデバイス）に対して自身を証明します。これにより、第三者がサーバー（リゾルバー）を偽装することができなくなります。

DNS over TLS（DoT）では、元のDNSメッセージは高いセキュリティで保護されたTLSチャネルに直接埋め込まれます。外部からは、問い合わせられた名前を知ることも、それを改ざんすることもできません。専用のクライアントアプリケーションでTLSを復号化することは可能です。それは次のようになります。

未暗号化状態のDNSのパケットトレースでは、明らかにDNS要求がクライアントから直接送信され、その後にリゾルバーからのDNS応答が続きます。しかしながら、暗号化されたDoTの場合、暗号化されたDNSメッセージを送信する前に、ある一定のTLSハンドシェイクメッセージが交換されます。

• クライアントはClient Helloを送信し、サポートされているTLS機能を告知します。
• サーバーはServer Helloで応答し、接続のセキュリティ保護に使用される TLSパラメータに同意します。証明書メッセージにはサーバーのIDが含まれ、証明書確認メッセージには、クライアントがサーバー証明書を使用して検証可能なデジタル署名が含まれます。通常、クライアントはこの証明書を信頼のおける証明機関のローカル リストと照合します。ただし、DoT仕様書では公開鍵ピンニングなどの代替信用メカニズムに触れています。
• クライアントとサーバーの両方がTLSハンドシェイクを終了した時点をもって、暗号化されたメッセージの交換を開始することができます。
• 上図にはDNSクエリと応答が1つづつ含まれていますが、実際にはセキュリティで保護されたTLS接続はOpenを維持し、未来のDNSクエリで再利用されます。

新しいポートの上にTLSをスラップして未暗号化状態のプロトコルをセキュリティで保護することは、以下のようにすでに実行済みです。

• ウェブトラフィック：HTTP（tcp/80） -> HTTPS（TCP/443）
• 電子メールの送信：SMTP（tcp/25） -> SMTPS（tcp/465）
• 電子メールの受信：IMAP（tcp/143） -> IMAPS（tcp/993）
• 現状：DNS（tcp/53 または udp/53） -> DoT（tcp/853）

新しいポートを導入する際の問題は、既存のファイアウォールがそれをブロックする可能性があることです。その理由は、新しいサービスを明示的に有効にするホワイトリストアプローチを採用しているか、あるいはネットワーク管理者がサービスを明示的にブロックするブロックリストアプローチを採用しているためです。高セキュリティオプション（DoT）が低セキュリティオプションに比較し導入される可能性が低い場合、ユーザーあるいはアプリケーションは未暗号化状態のDNSにフォールバックすることを選択する可能性があります。するとこれに引き続き、攻撃者はユーザーを低セキュリティバージョンに強制的に誘導する可能性が生じます。

ただし、このようなフォールバック攻撃はあまり理にかなっているとはいえません。最近ではHTTPSウェブサイトをHTTPにダウングレードするSSL ストリッピングが使用されつつあります。これは攻撃者がパスワードを盗んだり、アカウントをハイジャックすることを可能にします。

もう1つのアプローチであるDNS Queries over HTTPS（DoH）は、次の2つの主要なユースケースをサポートするように設計されています。

• オンパスデバイスがDNSと干渉を起こす上記の問題を回避する。これには、上記のポートブロックの問題が含まれます。
• ウェブアプリケーションが既存のブラウザー APIを介してDNSにアクセスできるようにする。
  DoHは本質的にHTTPSであり、ウェブが使用するものと同様の暗号化標準を採用し、同じポート番号（tcp/443）を再利用します。ウェブブラウザ側ではすでに、HTTPS を支持し、非安全保護のHTTPを非難しています。これにより、HTTPSはDNSメッセージを安全に転送するための優れた選択肢となりました。このようなDoH要求の例は、ここを参照してください。

一部のユーザーは、HTTPS の使用は、それが追跡目的でCookieを使用する可能性があることから、プライバシー保護を弱める可能性があると懸念しています。DoH プロトコルの設計者は、さまざまなプライバシー問題を考慮し、特にトラッキングを避けるためにHTTPクッキーの使用を明示的に非推奨としています。そのことは広く市場から受け入れられています。TLSセッションの再開により、TLS 1.2のハンドシェイクパフォーマンスは向上しました。しかし同時にTLS接続の関連付けに使用される可能性が生じました。幸いにも、TLS 1.3を使用することで、デフォルトでラウンド トリップの数が減ったことにより、関連するプライバシー懸念事項に効果的に対処することが可能となり、TLSセッション再開の必要性を排除することができました。

さらに、HTTPSを使用することによりHTTP ロトコルが改善され、そのことがDoHにメリットをもたらす可能性があります。たとえば、開発中の HTTP/3 プロトコルは、QUICの上に構築されており、ヘッドオブラインブロックがないために、パケットロスが発生した際のパフォーマンス低下問題を改善する可能性があります。つまり、1つのパケットが失われたときに互いをブロックすることなく、セキュリティで保護されたチャネルを介して複数のDNSクエリを同時に送信することが可能となるのです。

また、DNS over QUIC（DNS/QUIC）のドラフトも存在します。それは DoT に類似しますが、QUIC の使用によるヘッドオブラインブロックの問題は生じません。ただし、HTTP/3とDNS/QUICの両者は共にアクセス可能なUDPポートを必要とします。理論的には、どちらもそれぞれDoH over HTTP/2かDoTにフォールバックする可能性があります。

DoTとDoHの展開

DoTとDoHはどちらも比較的新技術であり、まだ汎用化に至っていません。サーバー側では、Cloudflareの1.1.1.1やGoogle DNSなどの主要なパブリックリゾルバーがサポートしています。しかしながら、多くの ISP リゾルバーは未だサポートを提供していません。DoHをサポートするパブリックリゾルバーの一覧表は、DNSサーバーソースを参照してください。DoTとDoHをサポートする別のパブリックリゾルバーの一覧表はDNSプライバシーパブリックリゾルバーを参照してください。

エンドユーザーのデバイス側でDoTまたはDoHを有効にする方法は次の 2 通りの方法があります。

• オペレーティング システムからリゾルバー サービスをバイパスし、アプリケーションにサポートを追加する。
• オペレーティング システムにサポートを追加し、透過的にアプリケーションをサポートする。

通常、クライアント側のDoTまたはDoHには次の3つのコンフィギュレーションモードがあります。

• オフ：DNSは暗号化されません。
• 適時モード：DNSにセキュリティで保護されたトランスポートの使用を常に試みますが、これが使用不可の場合は未暗号化状態のDNSにフォールバックします。このモードは、攻撃者がデバイスに未暗号化状態の DNS を強制使用ささせるダウングレード攻撃に対して脆弱です。このモードは、オンパスのアクティブな攻撃者がいないときにプライバシーを提供することを目的としています。
• 厳密モード：常にセキュリティで保護されたトランスポート経由での DNS使用を試行します。これが使用不可の場合は、致命的失敗となり、ユーザーにエラーを表示します。

セキュリティで保護されたトランスポート経由でのDNSに関するシステムワイドコンフィグレーションの現状：

• Android 9：自身の「プライベートDNS」機能を介してDoTをサポートしています。モード：
• デフォルトで、適時モード（"自動"）が使用されています。ネットワーク設定（通常は DHCP）からのリゾルバーが使用されています。
• 厳密モードは、明示的なホスト名を設定することにより構成が可能です。IP アドレスは許可されず、ホスト名はデフォルトのリゾルバーを使用して変換され、またそれは証明書の検証にも使用されます。（関連するソース コード）
• また、iOSおよびAndroidユーザーは、1.1.1.1 アプリをインストールし、厳密モードでDoHまたはDoTのサポートを有効にすることもできる。内部的には、セキュリティで保護されたチャネルを介して転送される前に、 VPNプログラミング インターフェイスを使用し、未暗号化状態のDNSトラフィックの傍受を有効にする。
• systemd 239によりsystemd変換されたLinux：DNSOverTLSオプション経由のDoT。
• デフォルトはオフです。
• 適時モードは構成できますが、証明書の検証は実行されません。
• 厳密モードはsystemd 243以降で使用可能となりました。信頼された証明機関によって署名された証明書は有効に受け入れられます。ただし、OpenSSLバックエンドがIPアドレスを想定している場合、GnuTLSバックエンドとの間でホスト名検証はできません。
• いずれの場合も、Server Name Indication（SNI）は送信されません。証明書名が検証されないことで中間攻撃者を弱体化させます。
• Linux、macOS、Windows は、各々DoHクライアントを厳密モードで使用することができます。Cloudflared proxy-dnsコマンドはデフォルトでCloudflare DNSリゾルバーを使用します。また、ユーザーはproxy-dns-upstreamオプションを使用して上書きすることができます。

ウェブブラウザがDoTの代替としてDoHをサポートする：

• Firefox 62はDoHをサポートします。また、いくつかのTrusted Recursive Resolver（TRR）設定を提供しています。デフォルトではDoHは無効になっています。ただし、Mozillaは実験として米国の一部のユーザー向けにDoHを有効にしています。この実験では現在、Cloudflareの1.1.1.1リゾルバーを使用しています。当社がMozilla が要求する厳密リゾルバーポリシーに準拠する唯一のプロバイダーであることがその理由です。多くのDNSリゾルバーが未だに暗号化されたDNSトランスポートをサポートしていないため、このMozillaのアプローチにより、より多くのユーザーがDoHを使用した保護の恩恵を受けることになるでしょう。
• この実験を介し、あるいはネットワーク設定の「Enable DNS over HTTPS」オプションを経由して有効化すると、Firefoxは適時モード（network.trr.mode=2 at about:config）に切り替わります。
• 厳密モードはnetwork.trr.mode=3で有効化できますが、明示的なリゾルバーIPを指定する必要があります（たとえば、network.trr.bootstrapAddress=1.1.1.1）。
• Firefoxがシステムのデフォルトリゾルバーを無効化しているとき、代替のリゾルバーを設定することができます。また、DoHをサポートしないリゾルバーを使用したエンタープライズデプロイメントには、DoHを無効化するオプションが与えられます。
• Chrome 78では、システム リゾルバーアドレスが ハードコーディングされたDoHプロバイダー（ソースコード変更）の1つと一致する場合に、適時 DoH を有効にします。この実験は、LinuxとiOSを除くすべてのプラットフォームで有効化されています。ただし、デフォルトではエンタープライズデプロイメントは除外されています。
• Opera 65では、Cloudflareの1.1.1.1リゾルバーを介したDoHの有効化がオプションとして追加されています。この機能はデフォルトではオフとなっています。これを有効化したとき、適時モード1.1.1.1:443（SNIなし）が使用可能な場合は、適時モードが使用されます。それ以外の場合は、デフォルトリゾルバーである未暗号化状態にフォールバックします。

カールプロジェクトのDNS over HTTPSページで、DoHプロバイダーと追加実装の包括的一覧を参照できます。

デバイスと外部DNSリゾルバー間のネットワーク パスを完全に暗号化する方法の代替策として、次のような中間的方策を取ることが可能です。つまり、デバイスとローカルネットワークゲートウェイの間に未暗号化状態のDNSを使用しつつ、ゲートウェイ ルーターと外部DNSリゾルバー間のすべてのDNSトラフィックを暗号化するという方法です。セキュリティで保護された有線または無線ネットワークの場合、この方法はローカル ネットワーク内のすべてのデバイスをスヌーパーISPやその他のインターネット上の敵対者から保護することを可能にします。公共のWi-Fiホットスポットは安全とは見なされないため、この方法はオープンなWi-Fiネットワークでは安全とは言えません。WPA2-PSKでパスワード保護されている場合でも、依然として他者が未暗号化状態のDNSをスヌープして改ざんすることが可能です。

その他のセキュリティに関する考慮事項

前のセクションでは、セキュリティで保護されたDNSトランスポート、DoH、およびDoTについて説明しました。これらの方法によってのみ、クライアントがDNSリゾルバーから改ざんされていない応答を受け取ることを保証できます。しかしながらこれらの方法は、リゾルバーが不正な応答（DNSハイジャック攻撃やDNSキャッシュポイゾニング攻撃を介した応答）をした際に防御することはできません。「真実」の応答は、権限のあるネームサーバーの報告により、ドメインまたはゾーンの所有者によって決定されます。DNSSECにより、クライアントは返ってきたDNS応答の整合性を確認することができ、また、クライアントと権限のあるネームサーバー間のパスで生じた不正な改ざんを発見することができます。

しかしながらDNSSECの導入は、ミドルボックスが誤ってDNSメッセージを転送することで妨害されることがあります。そしてさらに、情報が使用可能であったとしても、アプリケーションが使用しているスタブリゾルバーがその結果を検証すらしない場合もあります。2016年の報告書によると、DNSSEC検証リゾルバーを使用しているユーザーは 26% に過ぎませんでした。

DoHとDoTは、クライアントとパブリックリゾルバー間のトランスポートを保護します。パブリックリゾルバーは、名前を変換するために、追加で権限のあるネーム サーバーに連絡することが必要となる可能性があります。伝統的に、リゾルバーと権限のあるネームサーバーの間のパスは、未暗号化状態のDNSを使用します。これらのDNSメッセージを保護することを目的として、当社はFacebookと共に実験を行いました。1.1.1.1とFacebookが採用している権限のあるネームサーバーとの間にDoTを使用するというものです。TLSを使用してセキュリティで保護されたチャネルを設定することにより遅延が増加しますが、それはクエリ数が増すごとに緩和することが可能です。

トランスポートを暗号化することにより、リゾルバーの結果とメタデータが確実に保護されます。たとえば、DNSクエリに含まれる EDNS Client Subnet（ECS）情報は、DNSクエリを開始した元のクライアント アドレスを晒してしまう可能性があります。その情報をパスに沿って非表示にできればプライバシーが向上します。また、DNS転送時に発生するDNSSEC無効化の問題から生じるミドル ボックス損壊を回避することも可能となります。

DNS暗号化に関する運用上の問題

DNS暗号化にあたり、DNSトラフィックの監視または変更に依存する個人や組織は多くの課題に直面することでしょう。受動的監視に依存するセキュリティ 製品は、機械やネットワークの端で発生するすべての送受信ネットワークトラフィックを監視しています。未暗号化状態にあるDNSクエリを頼りにして、たとえばマルウェアに感染している機械を特定できる可能性があります。仮にDNSクエリが暗号化されている場合、受動性監視ソリューションはドメイン名を監視することはできません。

一部の人は、DNSリゾルバーが次のような目的でコンテンツ フィルターを適用することを期待しています。

• マルウェアディストリビューションに使用されるドメインをブロックする。
• 広告をブロックする。
• 保護者制限フィルター処理を実行し、アダルトコンテンツ関連のドメインをブロックする。
• 地域の規制に違反するコンテンツを提供するドメインへのアクセスをブロックする。
• スプリット ホライズンDNSを提供して、送信元ネットワークに応じた異なる応答をする。

DNSリゾルバーを介してドメインへのアクセスをブロックする方法の利点は、一つ一つのアプリケーション単位で再実装する必要がなく、すべてを一元的に実行できることにあります。しかしながら残念なことに、それは極めて粗雑です。あるウェブサイトが複数ユーザー向けにexample.com/videos/for-kids/とexample.com/videos/for-adults/を提供しているとします。DNS リゾルバーは唯一「example.com」のみを識別します。そして、それをブロックするかしないかを選択できるのみです。このケースでは、ブラウザー拡張機能などのアプリケーションに固有の管理機能を活用する方法がより効果的でしょう。この方法をとれば、実際に URL全体を識別し、コンテンツへのアクセスを選択的に排除できるからです。

DNS監視は包括的ではありません。マルウェアは、DNSアドレスとハードコード IP アドレスをスキップしたり、代替方法を使用してIPアドレスを照会することができます。ただし、すべてのマルウェアがそれほど複雑なわけではないため、依然としてDNS監視は多層防御 ツールとして機能することができます。

すべての非受動性監視やDNSブロッキングユースケースは、DNSリゾルバーからのサポートが要求されます。現在のリゾルバーをアップグレード展開する際、適時にDoH/DoTに依存する場合、通常、未暗号化DNSで提供されている機能がそのまま同様に維持されます。残念ながら、これは既に述べた通りダウングレードに対して脆弱です。これを解決するために、システム管理者はエンドポイントに厳密モードでDoH/DoTリゾルバーを指定することにより対処できます。理想的には、これを実行するにあたり、セキュリティで保護されたデバイス管理ソリューション（MDM、Windows上のグループポリシーなど）を使用することが好ましいでしょう。

結論

DNSを使用して名前をアドレスにマッピングすることは、インターネットの基礎の1つとなっています。DNSは、伝統的に安全性に欠けた未暗号化状態のトランスポートを使用してきました。このことは過去においてISPにより悪用され、広告が挿入されてきました。また、それはプライバシー漏洩の原因にもなってきました。せんさく好きな訪問者は、コーヒーショップで未暗号化状態のDNSを利用しあなたの行動を監視しています。これらの問題はすべて、DNS over TLS（DoT）または DNS over HTTPS（DoH）を使用することで解決することができます。ユーザーを保護するためのこれらの手法は比較的新しくはありますが、その適用は増加傾向にあります。

技術的な観点から評価すると、DoHはHTTPSに非常に類似しており、セキュリティを尊重しないオプションが廃止に向かう一般的な業界傾向を踏襲しています。DoTはHTTP層を削除していることから、DoHと比較してより単純なトランスポートモードと言えます。しかしながら、だからこそ故意または事故によりブロックされ易い傾向にあります。

高いセキュリティで保護されたトランスポートを実現するための2次的要素は、DNSリゾルバーの選択にあります。一部のベンダーは、ローカルに構成されたDNSリゾルバーを使用しますが、未暗号化状態のトランスポートをより安全なトランスポート（DoTまたはDoH）に適時にアップグレードする方式を試行しています。しかしながら残念なことに、多くの場合安全なトランスポートをサポートしないISPが提供するDNSリゾルバーにデフォルト設定されているのが現状です。

Mozillaは異なるアプローチを採用しています。DoHすらサポートしていない可能性があるローカルリゾルバーに依存するのではなく、ユーザーが明示的にリゾルバーを選択できるようにしています。Mozilla が推奨するリゾルバーは、ユーザーのプライバシーを保護するための高い基準を満たすことが要求されています。DNSに基づく保護者管理制御機能の継続を確保し、かつスプリットホライズンユースケースをサポートするために、MozillaはプライベートリゾルバーがDoHを無効化できるメカニズムを追加しました。

DoTおよびDoHトランスポートプロトコルにより、私たちはより安全なインターネットに移行する準備を整えました。前述のパケットトレースで見られるように、これらのプロトコルは、アプリケーショントラフィックをセキュリティで保護する既存のメカニズムに類似しています。このセキュリティとプライバシーの課題が解決を見たとき、そこにはより多くのが取り組むべき課題が出現することでしょう。