TLS 1.3に基づくドメインフロンティング

導入

Cisco、BlueCoat、FireEye などの有名なメーカーが提供する最新の企業コンテンツ フィルタリング システムには、国家レベルで積極的に導入されている、より強力な対応製品である DPI システムと多くの共通点があります。どちらの作業の本質も、送受信されるインターネット トラフィックを検査し、ブラック/ホワイト リストに基づいてインターネット接続を禁止する決定を下すことです。そして、どちらも仕事の基本において同様の原則に依存しているため、それらを回避する方法にも多くの共通点があります。

DPI と企業システムの両方を非常に効果的にバイパスできるテクノロジの XNUMX つは、ドメイン フロント テクノロジです。その本質は、ブロックされたリソースに移動し、評判の良い別のパブリック ドメインの背後に隠れることです。このリソースは、明らかにどのシステムによってもブロックされません (例: google.com)。

このテクノロジーについてはすでにかなり多くの記事が書かれており、多くの例が挙げられています。ただし、最近話題になっている DNS-over-HTTPS および暗号化 SNI テクノロジー、および TLS 1.3 プロトコルの新バージョンにより、ドメイン フロントの別のオプションを検討することが可能になります。

テクノロジーを理解する

まず、誰が誰で、なぜこれが必要なのかを誰もが理解できるように、基本的な概念を定義しましょう。 eSNI メカニズムについては説明しましたが、その動作についてはさらに詳しく説明します。 eSNI (暗号化されたサーバー名表示) メカニズムは、TLS 1.3 プロトコルでのみ使用できる SNI の安全なバージョンです。主なアイデアは、リクエストがどのドメインに送信されるかに関する情報を暗号化することです。

ここで、eSNI メカニズムが実際にどのように機能するかを見てみましょう。

最新の DPI ソリューションによってブロックされているインターネット リソースがあるとします (たとえば、有名な torrent トラッカー rutracker.nl を考えてみましょう)。トレント トラッカーの Web サイトにアクセスしようとすると、リソースがブロックされていることを示すプロバイダーの標準スタブが表示されます。

RKN Web サイトでは、このドメインは実際に停止リストにリストされています。

Whois をクエリすると、ドメイン自体がクラウド プロバイダー Cloudflare の背後に「隠されている」ことがわかります。

しかし、RKN の「専門家」とは異なり、より技術的に精通した Beeline の従業員 (または有名な規制当局の苦い経験から教えられた) は、愚かにも IP アドレスでサイトを禁止したのではなく、ドメイン名を停止リストに追加しました。同じ IP アドレスの背後にどのような他のドメインが隠されているかを確認し、そのうちの XNUMX つにアクセスしてアクセスがブロックされていないことを確認すると、これを簡単に確認できます。

これはどうして起こるのでしょうか?すべての通信は https プロトコル経由で行われ、Beeline からの https 証明書の置き換えにまだ気づいていないため、プロバイダーの DPI はどのようにして私のブラウザーがどのドメインにあるのかを知るのでしょうか?彼は透視能力があるのか​​、それとも私が尾行されているのか？

Wireshark を介したトラフィックを見てこの質問に答えてみましょう

このスクリーンショットは、最初にブラウザーが DNS 経由でサーバーの IP アドレスを取得し、次に宛先サーバーとの間で標準の TCP ハンドシェイクが発生し、その後ブラウザーがサーバーとの SSL 接続を確立しようとすることを示しています。これを行うために、ソース ドメインの名前をクリア テキストで含む SSL Client Hello パケットを送信します。このフィールドは、cloudflare フロントエンドサーバーが接続を正しくルーティングするために必要です。ここでプロバイダーの DPI が捕らえられ、接続が切断されます。同時に、プロバイダーからスタブを受け取らず、サイトが無効になっているか、単に機能していないかのような標準的なブラウザー エラーが表示されます。

次に、手順に記載されているように、ブラウザで eSNI メカニズムを有効にしましょう。 Firefoxの :
これを行うには、Firefox 設定ページを開きます。 約：設定 そして、次の設定を有効にします。

network.trr.mode = 2;
network.trr.uri = https://mozilla.cloudflare-dns.com/dns-query
network.security.esni.enabled = true

この後、cloudflare Web サイトで設定が正しく機能していることを確認します。 リンク トレント トラッカーを使ってトリックをもう一度試してみましょう。

出来上がり。私たちのお気に入りのトラッカーは、VPN やプロキシ サーバーなしで開きました。何が起こったのかを確認するために Wireshark のトラフィック ダンプを見てみましょう。

今回、SSL クライアント hello パッケージには宛先ドメインが明示的に含まれていませんが、代わりにパッケージに新しいフィールド encrypted_server_name が表示されています。これには rutracker.nl の値が含まれており、これを復号化できるのは Cloudflare フロントエンド サーバーのみです。分野。その場合、プロバイダー DPI は手を洗ってそのようなトラフィックを許可する以外に選択肢はありません。暗号化には他のオプションはありません。

そこで、このテクノロジーがブラウザーでどのように機能するかを調べました。次に、これをより具体的で興味深いものに適用してみましょう。まず、同じカールに eSNI を使用して TLS 1.3 で動作するように教え、同時に eSNI ベースのドメイン フロント処理自体がどのように機能するかを確認します。

eSNI によるドメインフロンティング

curl は標準の openssl ライブラリを使用して https プロトコル経由で接続するため、まずそこで eSNI サポートを提供する必要があります。 openssl マスター ブランチにはまだ eSNI サポートがないため、特別な openssl ブランチをダウンロードし、コンパイルしてインストールする必要があります。

GitHub からリポジトリのクローンを作成し、通常どおりコンパイルします。

$ git clone https://github.com/sftcd/openssl
$ cd openssl
$ ./config

$ make
$ cd esnistuff
$ make

次に、curl を使用してリポジトリのクローンを作成し、コンパイルされた openssl ライブラリを使用してそのコンパイルを構成します。

$ cd $HOME/code
$ git clone https://github.com/niallor/curl.git curl-esni
$ cd curl-esni

$ export LD_LIBRARY_PATH=/opt/openssl
$ ./buildconf
$ LDFLAGS="-L/opt/openssl" ./configure --with-ssl=/opt/openssl --enable-esni --enable-debug

ここで、openssl が配置されているすべてのディレクトリ (この例では、/opt/openssl/) を正しく指定し、構成プロセスがエラーなしで完了することを確認することが重要です。

構成が成功すると、次の行が表示されます。

警告: esni ESNI は有効ですが、実験的とマークされています。慎重に使用してください。

$ make

パッケージが正常にビルドされたら、openssl の特別な bash ファイルを使用して、curl を構成して実行します。便宜上、curl を使用してディレクトリにコピーしましょう。

cp /opt/openssl/esnistuff/curl-esni 

そして、cloudflare サーバーに対してテスト https リクエストを作成し、同時に Wireshark で DNS パケットと TLS パケットを記録します。

$ ESNI_COVER="www.hello-rkn.ru" ./curl-esni https://cloudflare.com/

サーバー応答では、openssl とcurl からの多くのデバッグ情報に加えて、cloudflare からコード 301 の HTTP 応答を受け取ります。

HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 13:12:55 GMT
< Transfer-Encoding: chunked
< Connection: keep-alive
< Cache-Control: max-age=3600
< Expires: Sun, 03 Nov 2019 14:12:55 GMT
< Location: https://www.cloudflare.com/

これは、リクエストが宛先サーバーに正常に配信され、受信され、処理されたことを示します。

次に、Wireshark のトラフィック ダンプを見てみましょう。この場合、プロバイダ DPI が認識したもの。

最初に、curl が DNS サーバーに接続して、cloudflare サーバーの公開 eSNI キーを取得したことがわかります。これは、_esni.cloudflare.com への TXT DNS リクエスト (パッケージ番号 13) です。次に、curl は openssl ライブラリを使用して、前の手順で取得した公開キーで SNI フィールドが暗号化された TLS 1.3 リクエストを Cloudflare サーバーに送信しました (パケット #22)。 ただし、SSL-hello パケットには、eSNI フィールドに加えて、通常のオープン SNI のフィールドも含まれており、任意の順序で指定できます (この場合は、- www.hello-rkn.ru).

このオープン SNI フィールドは、cloudflare サーバーによって処理されるときにまったく考慮されず、プロバイダー DPI のマスクとしてのみ機能しました。 Cloudflareサーバーはssl-helloパケットを受信し、eSNIを復号化し、そこから元のSNIを抽出して、何事もなかったかのように処理しました（eSNIの開発時に計画したとおりにすべてを正確に実行しました）。

この場合、DPI の観点から捕捉できる唯一のことは、_esni.cloudflare.com へのプライマリ DNS リクエストです。ただし、このメカニズムが内部からどのように機能するかを示すためにのみ、DNS リクエストをオープンにしました。

最終的に DPI の下から問題を解決するために、すでに述べた DNS-over-HTTPS メカニズムを使用します。簡単な説明 - DOH は、HTTPS 経由で DNS リクエストを送信することで中間者攻撃から保護できるプロトコルです。

リクエストを再度実行してみましょう。ただし、今回は DNS ではなく https プロトコル経由で公開 eSNI キーを受け取ります。

ESNI_COVER="www.hello-rkn.ru" DOH_URL=https://mozilla.cloudflare-dns.com/dns-query ./curl-esni https://cloudflare.com/

リクエスト トラフィック ダンプは、以下のスクリーンショットに示されています。

Curl はまず DoH プロトコル (サーバー 104.16.249.249 への https 接続) 経由で mozilla.cloudflare-dns.com サーバーにアクセスし、そこから SNI 暗号化用の公開キーの値を取得し、次に宛先にアクセスすることがわかります。サーバー、ドメインの後ろに隠れています www.hello-rkn.ru.

上記の DoH リゾルバー mozilla.cloudflare-dns.com に加えて、有名な悪の企業のような他の人気のある DoH サービスを使用することもできます。
次のクエリを実行してみましょう。

ESNI_COVER="www.kremlin.ru" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

そして、次のような答えが得られます。

< HTTP/1.1 301 Moved Permanently
< Date: Sun, 03 Nov 2019 14:10:22 GMT
< Content-Type: text/html
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=/; domain=.rutracker.nl; HttpOnly; Secure
< Location: https://rutracker.nl/forum/index.php
< CF-Cache-Status: DYNAMIC
< Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< Server: cloudflare
< CF-RAY: 52feee696f42d891-CPH

この場合、DoH リゾルバー dns.google を使用して、ブロックされた rutracker.nl サーバーに注目し (ここにタイプミスはありません。有名な企業は独自のファーストレベル ドメインを持っています)、別のドメインで自分自身をカバーしました。すべての DPI が死の苦しみの下でブロックすることは禁止されています。受け取った応答に基づいて、リクエストが正常に処理されたことがわかります。

プロバイダーの DPI がカバーとして送信するオープン SNI に応答するかどうかの追加チェックとして、他の禁止されているリソース (たとえば、別の「良い」トレント トラッカー) を装って rutracker.nl にリクエストを送信できます。

$ ESNI_COVER="rutor.info" DOH_URL=https://dns.google/dns-query ./curl-esni https://rutracker.nl/

サーバーからの応答が受信されません。理由は...私たちのリクエストは DPI システムによってブロックされます。

最初の部分の短い結論

そのため、openssl とcurl を使用して eSNI の機能を実証し、eSNI に基づいたドメイン フロントの動作をテストすることができました。同様に、openssl ライブラリを使用するお気に入りのツールを、他のドメインの「装いで」動作するように適応させることができます。これについては次の記事で詳しく説明します。

出所： habr.com