web-dev-qa-db-ja.com

HTTPSプロトコルを介してアクセスされるWebサイトの*完全な*リクエストされたURLにアクセスできるのはどの当事者ですか?

HTTPSプロトコルを介してアクセスするWebサイトのfull要求されたURLにアクセスできるのはどの当事者ですか?

ここに私が考えることができるいくつかの可能性があります、そしてもっとあるかもしれません:

  1. ウェブサイトにアクセスするローカルデバイス
  2. ルーター
  3. モデム
  4. ローカルネットワークプロバイダー(有線または無線)
  5. ISP
  6. インターネットに沿って目的地まで各ホップ
  7. 兄貴
  8. 宛先ISP
  9. 宛先ローカルネットワークプロバイダー(通常は有線ですが、ワイヤレスにすることもできます)
  10. 宛先モデム
  11. 宛先ルーター
  12. 宛先ホスト

この質問は、具体的にはfullリクエストされたURLに関するものであり、URLを介して渡されるすべてのパラメーターだけでなく、アクセスされる特定のページも含まれます。

また、HTTPSリクエストヘッダー全体にアクセスできない手順はありますか?

14
RockPaperLizard

TLSエンドポイントのみ1 HTTPSはエンドツーエンドの暗号化を提供するため、完全なURLを読み取ることができます。

HTTPSは、要求行、要求/応答本体、およびすべてのヘッダーを含む完全なHTTPプロトコルをラップします。リクエストURLは、他のすべてのコンポーネントと一緒に暗号化されるHTTPの一部にすぎません。いずれかのパーティがURLを読み取ることができた場合、当然、完全なHTTPトラフィックにもアクセスできます。

明確にするために、URLが誤って開示される可能性がある方法はまだたくさんあります。

  • リンクをクリックしてサイトから移動すると、ブラウザはデフォルトで、以前のURLを含むRefererヘッダーを送信します。したがって、これは閲覧しているサイトに開示されます。

  • ブラウザプラグイン 訪問したURLをどこかに送信する可能性があります 分析または販売するため。

  • 「正当な」HTTPSインターセプトを行うセキュリティ製品または企業ファイアウォール(アクティブにインストールされ、ルート証明書を信頼していることを意味します)は、HTTPトラフィックを読み取って、URLを知る可能性があります。

  • ターゲットサイトのホスト(完全なURLではない)は、HTTPS [〜#〜] sni [〜#〜] とクライアントのDNSクエリにより、潜在的な盗聴者に日常的に公開されます。

ただし、サイドチャネルリークのない正しい設定を前提とすると、要求URLは、他のすべての送信と同様にTLSトンネルを通過するだけです。

1あなたの例では、これらはおそらくローカルデバイス(1。)宛先ホスト(12)です。 。 @Bobが指摘するように、TLS接続はロードバランサーまたは他の何らかの形式のプロキシで終了することもできます。

33
Arminius