新しいプロトコルとエッジインフラでプライバシーを強化

近頃は、誰もが暗号化技術の使用によるコミュニケーションの安全確保とプライバシー強化を求めています。今や HTTPS を使用せずに新しい Web サービスを立ち上げようとする人などいないでしょう。また、従来の SMS やメール、ボイスコールを悪用したスパイ行為やフィッシングを防ぐため、インターネットベースのエンドツーエンド暗号化を使用したダイレクトメッセージも一般的になっています。米国勢調査局のような大規模なデータ収集プロジェクトでも、暗号化技術を使用してプライバシーの強化を試みています。

このようなセキュリティ環境の成熟に伴い、データ保護の複雑さへの理解が高まっています。例えば、保護を必要としているのは転送中のデータだけとは限りません。メタデータが果たす役割についても検討する必要があります。 

メタデータの保護

私はこれに関して、個人的な経験があります。HTTPS が広く普及すると、HTTPS は Web トランザクションのコンテンツのみを保護し、これらのトランザクションを設定するメタデータは保護されないという問題がインターネットに残されました。最大の漏洩源は DNS でした。DNS は、URL 内に表示されるホスト名を接続先の IP アドレスに変換するために使用されます。undefined

従来の DNS リクエストはスヌーピングされる可能性があり、攻撃者は本物のレスポンスを独自のレスポンスに置き換えることができます。ユーザーは任意の DNS サーバー (通常は信用できる DNS サーバー) を選択できますが、通信ネットワーク上の攻撃者がリクエストを自分が選んだサーバーにルーティングすることがよくあります。このようなハイジャックでは、クライアントのデータがデータブローカーのビジネスモデルをサポートするために使用されたとしても、ユーザーが違いに気づくのは難しいでしょう。

DNS トラフィックの保護

その後、私は HTTPS を介した DNS に関する仕様 (別名 DoH RFC 8484) を共同執筆しました。現在、クライアントが DNS トラフィックを保護する一般的な方法のひとつとして採用されています。DoH を使用するクライアントは、DNS サーバーとの通信がクライアントとサーバー間のみに制限されているため安心できます。これは、安全が確保されてなかった従来の DNS に比べると飛躍的な進歩です。HTTPS 自体の Server Name Indication には依然としてメタデータに関する問題がありますが、IETF は Encrypted Client Hello と呼ばれる独自の取り組みを通じてこの問題に対応しています。

しかし、これら2つのテクノロジーを使用したとしても、100%安全とは言えません。テキストメッセージなどの対話には、安全な二者間通信が理想的です。この場合、両者は互いを信用していますが、両者を繋ぐネットワークのことは信用できない可能性があります。DNS サーバーは、これとは大分異なる状況にあります。クライアントは、サーバーへの接続に使用されるネットワークを信用できないだけでなく、サーバーも完全には信用できない可能性があります。DoH はネットワーク上の攻撃者からプライバシーを保護し、HTTPS や DNSSec はサーバーが不当なレスポンスを返すのを阻止できますが、誰からどの DNS リクエストが送信されたのかをサーバー自体が追跡できないようにする術がプロトコルにはありません。

次のステップ：Oblivious DNS

次なる DNS の進歩として、Oblivious DNS (別名 ODoH) が挙げられます。私は、この DNS プロトコルの共同執筆に携わり、RFC 9230 として公開されるのを支援しました。ODoH では、二重暗号化と単一リレーを使用して IP ブラインディング技術を DoH に適用し、DNS リクエストのコンテンツとクライアントの ID を切り離すことが可能になります。要するに、クライアントはリレーを使用してクライアントの IP アドレスが DoH サーバーから見えないようにすることができるのです。二重暗号化を利用するこの方法では、リレーには ID しか見えず、DNS サーバーはクライアントと直接やり取りしないので、DNS データしか見えません。

プライバシーに配慮したネットワークでは、IP ブラインディングの採用が増えています。この技術は ToR により初めて注目を浴び、最近ではプライベートリレーサービスにも使用されています。両者とも、IP ブラインディングをトランスポートレイヤー (任意のインターネットデータのストリーム) に適用しています。一方、ODoH は DNS 固有であり、アプリケーションレイヤーで動作します。アプリケーション固有のプロトコルの方が、汎用的なトランスポートプロトコルよりも大規模に管理を行いやすい場合があります。そのため、複数のアプローチを使用して問題に対処でき、アーキテクチャの観点から見ても優れています。

進行中：Oblivious HTTP

第3のアプローチとして Oblivious HTTP (別名 OHTTP) が挙げられます。OHTTP は現在、IETF でまだ標準化されていないドラフトです。リレーでコンテンツを見えないようにしつつ、サーバーに対してクライアントの ID を隠すことができる形で任意の HTTP 交換を処理するために ODoH を汎用化する見込みです。OHTTP は、単一のトランザクションにクライアント、リレー、ゲートウェイ、サーバーの4つのノードを必要とします。この結果、ODoH より多少リソースの負荷が高くなりますが、より柔軟な成果が期待できます。

Fastly のようなエッジクラウドプラットフォームは、プライバシーに配慮した最先端のネットワークを実現するインフラを提供する上で、重要な役割を果たしています。私たちは日々、より多くのパートナーと協力し、Fastly のエッジクラウドがプライバシーを保護するアプリケーションのニーズを満たせるよう常に新たな方法を模索しています。このような枠組みにおいて理想的な Fastly のプログラム可能なネットワークは、非常に優れたスケーラビリティを備えた分散型アプリケーションプラットフォームです。世界中で CPU、帯域、低レイテンシのサービスをご利用いただけます。さらに優れている点として、Fastly のエッジクラウドプラットフォームは、HTTP 配信プラットフォームとして最適化され、高性能なインフラには欠かせない高度な TLS、ルーティング、接続管理が可能です。

この記事は、プライバシーに関するプラクティスやテクノロジーをインターネットの構造に統合する Fastly の取り組みをご紹介する Privacy Week の一環として書かれたものです。