Oblivious DNS over HTTPS (ODoH): DNS プライバシーを改善する試み

公開: 2020-12-14

ドメイン ネーム システムまたは DNS は、インターネット上に存在するすべての異なる Web サイトの分散型命名システムです。 これは、インターネットの不可欠な構成要素の 1 つであり、30 年以上にわたって存在しています。 この期間中、このシステムは、実装とそれがもたらすプライバシーの懸念について、正当な理由で批判を受けてきました. その結果、これらの懸念に対処するためのいくつかの試みが行われてきました。

Oblivious DNS over HTTPS (ODoH)

そのような提案の 1 つ (そしてごく最近のもの) は、DNS over HTTPS (DoH) プロトコルの導入です。これは、暗号化された方法で送信することによって DNS 通信を保護することを約束します。 DoH は理論的には有望に見え、DNS に関する問題の 1 つをなんとか解決することができましたが、うっかり別の懸念が明るみに出てしまいました。 これを修正するために、Cloudflare、Apple、および Fastly によって共同開発された Oblivious DNS over HTTPS (ODoH) と呼ばれる別の新しいプロトコルが用意されました。 Oblivious DoH は、基本的に DoH プロトコルの拡張機能であり、DNS クエリを (ユーザーの) IP アドレスから分離して、DNS リゾルバーがユーザーがアクセスするサイトを認識できないようにします。[これについては後で詳しく説明します]。

ODoH の目的は、誰がクエリを作成しているか、およびクエリが何であるかに関する情報を分離することです」と、Cloudflare の研究責任者である Nick Sullivan 氏はブログで述べています。

目次

HTTPS (または ODoH) を介した無意識の DNS

ODoH とは何かを説明する前に、まず DNS とは何か、続いて DNS over HTTPS とは何か、そしてこの 2 つがもたらす制限について理解しましょう。

DNS (ドメインネームシステム)

ドメイン ネーム システムまたは DNS は、インターネット上のすべての Web サイトの記録を保持する分散型システムです。 これは、電話加入者とそれに対応する電話番号のリストを保持する電話番号のリポジトリ (または電話帳) と考えることができます。

DNS working
画像: 総稼働時間

インターネットに関して言えば、DNS は、関連する IP (インターネット プロトコル) アドレスを覚えなくても、ドメイン名を入力するだけで Web サイトにアクセスできるシステムを確立する上で重要な役割を果たします。 そのため、アドレス フィールドに techpp.com を入力してこのサイトを表示すると、IP アドレスを覚えなくても済みます。IP アドレスは 103.24.1.167 [当社の IP ではありません] のようになります。 ご覧のとおり、デバイスとアクセスしようとしている Web サイトとの間の接続を確立するために必要なのは IP アドレスです。 しかし、IP アドレスはドメイン名ほど覚えにくいため、DNS リゾルバーがドメイン名を関連付けられた IP アドレスに解決し、要求された Web ページを返す必要があります。

DNS の問題

DNS はインターネット アクセスを簡素化しますが、いくつかの欠点があります。最大のものは、プライバシー (およびセキュリティ) の欠如です。これは、ユーザー データにリスクをもたらし、ISP によって表示されたり、盗聴されたりする可能性があります。インターネットの悪者。 これが可能な理由は、DNS 通信 (DNS 要求/クエリおよび応答) が暗号化されていないためです。つまり、プレーン テキストで行われるため、途中 (ユーザーと ISP の間) で傍受される可能性があります。 .

DoH (DNS over HTTPS)

最初に述べたように、この (セキュリティ) DNS の問題に対処するために、DNS over HTTPS (DoH) プロトコルが導入されました。 基本的に、このプロトコルが行うことは、DNS 通信 (DoH クライアントと DoH ベースのリゾルバーの間) をプレーン テキストで行う代わりに、暗号化を使用して通信を保護することです。 そうすることで、ユーザーのインターネットへのアクセスを保護し、中間者攻撃のリスクをある程度軽減することができます.

DNS over HTTPS (DoH) working

DoHの問題

DoH は、DNS を介した暗号化されていない通信の問題に対処しますが、DNS サービス プロバイダーがネットワーク データを完全に制御できるようにするというプライバシー上の懸念を引き起こします。 DNS プロバイダーは、ユーザーとアクセスする Web サイトとの間の仲介者として機能するため、IP アドレスと DNS メッセージの記録を保持します。 ある意味で、それは 2 つの懸念を引き起こします。 1 つ目は、ネットワーク データへのアクセス権を持つ単一のエンティティを残すことです。リゾルバーがすべてのクエリを IP アドレスにリンクできるようにします。2 つ目は、最初の懸念により、通信が単一障害点 (攻撃) になりやすいままになります。 .

ODoH プロトコルとその仕組み

Cloudflare、Apple、Fastly が共同開発した最新のプロトコル ODoH は、DoH プロトコルによる集中化の問題を解決することを目的としています。 このため、Cloudflare は、ユーザーを除く単一のエンティティが両方の情報を同時に表示できないように、新しいシステムで IP アドレスを DNS クエリから分離することを提案しています。

ODoH は、2 つの変更を実装することでこの問題に取り組みます。 クライアント (ユーザー) と DoH サーバーの間に、公開鍵暗号化の層とネットワーク プロキシを追加します。 そうすることで、一度に DNS メッセージと IP アドレスの両方にアクセスできるのはユーザーだけであることを保証すると主張しています。

ODoH working

簡単に言えば、ODoH は、次のことを達成することを目的とした DoH プロトコルの拡張機能のように機能します。

私。 クライアントのアドレスを削除するためにプロキシ経由でリクエストをチャネリングすることにより、どのクライアントがどのドメイン名をリクエストしたかを DoH リゾルバーが認識できないようにします。

ii. プロキシがクエリと応答の内容を認識できないようにし、リゾルバーがクライアントのアドレスを認識できないようにするために、接続をレイヤーで暗号化します。

ODoH を使用したメッセージ フロー

ODoH でのメッセージ フローを理解するには、クライアントとターゲットの間にプロキシ サーバーが配置されている上の図を検討してください。 ご覧のとおり、クライアントがクエリ (example.com など) を要求すると、同じことがプロキシ サーバーに送られ、プロキシ サーバーがそれをターゲットに転送します。 ターゲットはこのクエリを受け取り、それを復号化し、(再帰的な) リゾルバにリクエストを送信してレスポンスを生成します。 戻る途中で、ターゲットは応答を暗号化し、プロキシ サーバーに転送します。その後、プロキシ サーバーはそれをクライアントに送り返します。 最後に、クライアントは応答を復号化し、要求されたクエリに対する応答を返します。

この設定では、通信 (クライアントとプロキシ、およびプロキシとターゲットの間) が HTTPS 経由で行われるため、通信のセキュリティが強化されます。 それだけでなく、両方の HTTPS 接続 (クライアント プロキシとプロキシ ターゲット) で行われる DNS 通信全体がエンド ツー エンドで暗号化されるため、プロキシはメッセージの内容にアクセスできません。 ただし、このアプローチではユーザーのプライバシーとセキュリティの両方が考慮されますが、すべてが提案どおりに機能するという保証は、最終的な条件になります。つまり、プロキシとターゲット サーバーが共謀しないということです。 したがって、同社は「共謀がない限り、攻撃者はプロキシとターゲットの両方が侵害された場合にのみ成功する」と示唆しています。

Cloudflare のブログによると、暗号化とプロキシが保証するものは次のとおりです。

私。 ターゲットには、クエリとプロキシの IP アドレスのみが表示されます。

ii. プロキシは DNS メッセージを認識できず、クライアントから送信されたクエリまたはターゲットから返された回答を識別、読み取り、または変更することはできません。

iii. 目的のターゲットのみが、クエリの内容を読み取って応答を生成できます。

ODoH の可用性

Oblivious DNS over HTTPS (ODoH) は、現時点では提案されたプロトコルにすぎず、Web 全体で採用される前に IETF (Internet Engineering Task Force) によって承認される必要があります。 Cloudflareは、これまでのところ、プロトコルの立ち上げを支援するプロキシパートナーとしてPCCW、SURF、およびEquinixなどの企業を獲得し、1.1.1.1 DNSサービスでODoHリクエストを受け取る機能を追加したことを示唆していますが、問題の真実は、Web ブラウザーがプロトコルのサポートをネイティブに追加しない限り、使用できないということです。 プロトコルはまだ開発段階にあり、さまざまなプロキシ、レイテンシ レベル、ターゲットでパフォーマンスをテストしています。 その理由として、ODoH の運命をすぐに裁定するのは賢明ではないかもしれません。

入手可能な情報とデータに基づくと、このプロトコルは DNS の将来に有望であるように思われます。 インターネットの機能において重要な役割を担っている DNS が、依然としてプライバシーとセキュリティの問題に悩まされていることは明らかです。 また、DNS のセキュリティ面を強化することを約束する DoH プロトコルが最近追加されたにもかかわらず、それが提起するプライバシー上の懸念により、採用はまだ先のようです.

しかし、ODoH がプライバシーとパフォーマンスの面でその要求に応えることができれば、DoH との組み合わせは、連携して動作しながら、DNS のプライバシーとセキュリティの問題の両方に対処できます。 そして、現在よりもはるかにプライベートで安全なものにしましょう。