HTTPS URLをスニッフィングすることは可能ですか？
多くの投稿から、HTTPSまたはSSL接続のほとんどすべてが暗号化されていることがわかります。それでも、接続を開くコンピューターがホームネットワーク上にあり、ルーターのUnixベースのOSを含むwifiルーターへのアクセスが許可されている場合、そのような接続からURLを取得することは可能ですか？
メッセージの内容について話しているのではなく、ブラウザでアクセスされるドメインと、おそらくdomain.com/thiscategory/site123のような残りのURLについてのみです。
TL; DR攻撃者はドメインを越えて何も見ることができません。
HTTPリクエストの構造
HTTPは メソッド と ヘッダー の2つをWebサイトに送信することで機能します。最も一般的な方法は、GET、POST、およびHEADであり、それぞれページの取得、データの転送、または応答ヘッダーのみの要求を行います。 TLSは、ヘッダーとメソッドを含むHTTPトラフィック全体を暗号化します。 HTTPでは、URL内のパスがヘッダー本文とともに送信されます。この例では、wgetがページfoo.example.com/some/page.htmlをロードしています。このテキストは、ASCIIとしてサーバーに送信されます。
GET /some/page.html HTTP/1.1 User-Agent：Wget/1.19.1（linux-gnu） Accept：*/* Accept -エンコーディング：identity ホスト：foo.example.com
その後、サーバーはHTTP ステータスコード 、一部の 独自のヘッダー 、およびオプションで一部のデータ（HTMLなど）で応答します。例として、301リダイレクトといくつかのプレーンテキストを応答として指定すると、次のようになります。
HTTP/1.1 301が完全に移動しました 日付：2017年12月27日水曜日04:42:54 GMT サーバー：Apache 場所：https：// bar。 example.com/new/location.html Content-Length：56 Content-Type：text/plain ありがとうマリオですが、私たちの王女は別の城！
これは、正しい場所が別の場所にあることをクライアントに伝えます。
これらは、TCPを介してサイトに直接送信されるヘッダーです。 TLSは別のレイヤーで機能し、これをすべて暗号化します。これには、GETメソッドでアクセスしているページが含まれます。 Hostヘッダーもヘッダー本文に含まれるため暗号化されますが、ホストはIPアドレスの rDNS ルックアップまたは [〜＃〜] sni [〜＃〜] 、ドメインをプレーンテキストで送信します。
URLの構造
https://foo.example.com/some/page.html#some-fragment |プロト|ドメイン|パス|フラグメント|
- proto-一般的に使用されているプロトコルは、HTTPとHTTPSの2つだけです。
- domain-ドメインは
example.comおよび*.example.comであり、rDNSまたはSNIで検出可能です。 - path-パスは完全に暗号化されており、ターゲットサーバーでのみ読み取ることができます。
- fragment-フラグメントはWebブラウザーにのみ表示され、送信されません。
攻撃者が見ることができるもの
では、HTTPSを介してリクエストを送信した場合、攻撃者は何を確認できますか？ネットワーク上の受動的な盗聴者の観点から、前の架空の要求を考えてみましょう。あなたがアクセスしているものを知りたいのであれば、私は限られたオプションしか持っていません：
203.0.113.98に送信されるHTTPSで暗号化されたWebリクエストを作成しているようです。- 宛先ポートが443であることがわかります。これはHTTPSに使用されていることがわかっています。
- RDNSルックアップを実行し、
example.comおよびexample.orgにIPが使用されていることを確認します。 - SNIレコードを確認すると、
foo.example.comに接続しています。
私ができることはこれだけです。 トラフィック分析攻撃 と呼ばれる、送受信されているデータのサイズに基づくヒューリスティック分析が不足している場合、要求しているパス、または使用している方法を確認することはできません。ウィキペディアのような大規模なサービスの場合、暗号化されていないデータの分析だけに基づいて、どの記事を表示しているかはわかりません。
古いブラウザのリファラーに関する重要な注意
HTTPSはアクセスしているパスを暗号化しますが、暗号化されていないページに移動するそのサイト内のハイパーリンクをクリックすると、完全パスがrefererヘッダーにリークされる可能性があります。これは これ以外の場合 多くの新しいブラウザーの場合ですが、HTML5リファラーメタタグを設定して常に情報を送信するWebサイトと同様に、古いブラウザーや非準拠ブラウザーでもこの動作が発生する可能性があります。このような場合にクライアントがhttps://example.com/private/details.htmlからhttp://example.org/public/page.htmlにジャンプするためにunencryptedを送信する例は次のようになります。
GET /public/page.html Referer：https://example.com/private/details.html User-Agent：Wget/1.19.1（linux-gnu ） 受け入れ：*/* 受け入れ-エンコード：アイデンティティ ホスト：example.org
そのため、HTTPSページからHTTPページに移動すると、前のページの完全なURL（フラグメントを除く）がリークする可能性があるため、注意してください。
素朴な答えは「いいえ」です。URLはTLSストリームで暗号化されています。しかし、その答えは多くの関連情報を無視しています。
それがウィキペディアだとしましょう。すべてのヘッダーフィールドが同じであると仮定すると、https://en.wikipedia.org/wiki/Cryptographyとhttps://en.wikipedia.org/wiki/Information_securityのHTTP GETリクエストはどのくらいの期間ですか？単一のTLSレコードで送信される可能性が高いリクエストの長さを測定できる場合、おそらくこれらを区別できます。
もちろん、暗号に関する記事の要求とコレオグラフィーに関する記事を区別するのに役立ちません。また、TLSクライアントがサーバーによって無視されたいくつかのパディングをTLSレコードに巧妙に追加して、それをいくつかのブロックサイズの倍数に丸める場合にも役立ちません。しかし、英語版ウィキペディアには、振付よりも暗号についての記事がはるかに長く掲載されています。したがって、エンドポイントがTLSレコードを最大16384バイトまで埋め込んでも、暗号に関する記事とコレオグラフィーに関する記事を区別できるでしょう。
攻撃者としての観点から見ると、問題は複雑です。クライアントは、多くの要求と応答に同じTLSストリームを使用する可能性があります。しかし、被害者がCSS、画像、JavaScript、etc。を埋め込んだ単一のページをロードし、被害者がページを読み取ると、すべてが一斉にタイミングを計られて沈黙します。これらのリクエストのタイミングと数は、ユーザーが探していたページを区別できる別の変数を提供します。
これらの変数はすべて、ページの確率論的モデルに入力できます-- 匿名の参考文献 から持ち上げた ここに1つの例を示します 。 1つの例を破っても、ネットワーク上の攻撃者が1つのページについて学習するデータの分布が別のページからindistinguishableであることを意味するのではなく、その特定の識別器はそれほど効果的ではありません。
それで、あなたは、盗聴者として、-保証を介してURLをネットワークから読み取ることができますか？いいえ：TLSストリームで暗号化されます（NULL暗号が選択されていない限り！）。せいぜい、確率的に依存する他の観測可能な変数からそれを推測できます。
一方、被害者は保証になっており、URLが盗聴者から隠されているのでしょうか？いいえ：メイヨークリニックで読んでいる性感染症など、攻撃者がジューシーな情報を推測できるURLに依存する多くの変数があります。
（URLのfragmentのすべて（#のhttps://en.wikipedia.org/wiki/Cryptography#Terminologyマークの後の部分）は、HTTP GETリクエストで送信されないことに注意してください。 URLフラグメントに応じて異なるネットワークトラフィックをトリガーするページ上のスクリプト。）
あなたが言うURLは、HTTPヘッダーの内部にあり、HTTPボディと同様に、TLSストリーム内にあります。つまり、それらは暗号化されています。 HTTPSリクエストの前にDNSリクエストをスニッフィングすることでサーバー名を導出できますが、たとえば名前がすでにローカルキャッシュにある場合は、結果が得られない可能性があります。