web-dev-qa-db-ja.com

HTTPS URLは最初の接続でプレーンテキストですか?

サイトに接続したことがないexample.com

このサイトがhttpsであり、https://example.com/supersecretpage初めてサイトに接続したため、暗号鍵がまだ交換されていないため、URLはクリアテキストで送信されますか?そうでない場合、これはいつ行われますか?そのURLを入力するときの手順を誰かに説明してもらえますか?

34
user104545

短い答え:いいえ、URLは暗号化されますが、(サブ)ドメインはプレーンテキストで送信されます。あなたの場合、(パッシブ)攻撃者は知っています_example.com_に接続しているが、アクセスしている特定のページがわからない。

要するに、攻撃者があなたがアクセスしているサイトに関する情報を入手できる場所が3回あります(時系列)。

  1. DNSクエリの(サブ)ドメイン
  2. Client Hello(SNI)の(サブ)ドメイン
  3. サーバー証明書の(サブ)ドメイン

しかし...

  1. URLはTLS経由で暗号化されて送信されます

詳細については、以下の説明をお読みください。

説明

注:「(サブ)ドメイン」と書いているときは、ドメイン(_example.com_)とサブドメイン(_mydomain.example.com_)の両方を意味します。私が「ドメイン」とだけ書くとき、私は本当にサブドメインなしのドメイン(_example.com_)だけを意味します。

基本的に何が起こるかです:

  1. https://example.com/supersecretpage と入力します。
  2. ブラウザは(sub)domainを特別なTLS拡張( [〜#〜] sni [〜#〜] で送信) =)
  3. ある時点で、ブラウザはサーバーからSSL証明書を取得します。
    証明書に応じて、これには接続しているサブドメインも含まれますしかし複数のサブドメイン、さらには複数のドメインが含まれる場合もあります。したがって、実際には、_example.com_の証明書には、_www.example.com_、_devserver.example.com_、および_how-to-develop-tls.example_も含まれる場合があります。これらのエントリは Subject Alternative Names と呼ばれ、証明書はそれらすべてに対して有効です。
  4. クライアントが証明書を検証し、クライアントとサーバーが暗号を選択した後、トラフィックが暗号化されます
  5. これがすべて発生した後、「通常の」HTTP要求が送信されます(保護されたTLSチャネルを介して)。これは、完全なURLが表示されるリクエスト全体で初めてのことです。リクエスト。このようになります:

    GET/supersecretpage HTTP/1.1
    ホスト:example.com
    [...]

*証明書がワイルドカード証明書の場合、サブドメインは含まれず、_*.example.com_のみが含まれます。

もう1つ言及する価値があります。接続を確立する前に、クライアントはDNS名を解決する必要があります。これを行うには、暗号化されていないDNSクエリをDNSサーバーに送信し、これらのクエリにも(sub)domain。これにより、攻撃者がアクセスしたドメインを確認するために使用できます。


ただしこれは、ユーザーがURLバーに_https://example.com/supersecretpage_を手動で入力することを想定しているため、常にこのように行われる必要はありません。しかし、これはほとんどのユーザーにとって非常にまれです。むしろ_example.com/supersecretpage_と入力します。別の問題は、訪問者が 安全でないHTTPSリンク とは対照的に、HTTPを使用する 安全でないリンク をクリックすることです。そのようなリンクは、例えば、サイトがHTTPSをサポートしていないか、デフォルトでHTTPSにリダイレクトしなかったときに作成された古いリンクである。なぜこれが重要なのかと尋ねますか?

このような(通常の)場合、URLに_https://_はありません。プロトコルがURLバーに入力されていない場合、すべてのブラウザは内部的にこのURLを_http://example.com/supersecretpage_に「変換」します(そこにhttp://があることに注意してください)サーバーがHTTPSをサポートすることを期待できないためです。これは、ブラウザーが最初に安全でないHTTPを使用してWebサイトへの接続を試み、WebサイトがHTTPSのURLに(301)リダイレクトを送信した後にのみ、安全なモードを使用することを意味します。
この場合、攻撃者は暗号化されていないHTTPリクエストで完全なURLを見ることができます。

ブラウザの「ネットワークパネル」を調べることで、これを自分で簡単にテストできます。そこで、この「HTTPSアップグレード」が表示されます。
HTTPS connection upgrade in Firefox

ただし、この安全でない最初のHTTP要求を防ぐための手法があることに注意してください。最も注目すべきは [〜#〜] hsts [〜#〜] および-サイトへの最初の接続を保護するために HSTS preloading だけでなく HTTPS Everywherehelps このような攻撃に対して。 FYI:Netcraftによると すべてのHTTPSサーバーの95%が脆弱です 2016年3月の時点で、このような(SSLストリッピング)攻撃に対して脆弱でした。

76
rugk

いいえ、URLはクリアテキストで送信されません。

TCPスリーウェイハンドシェイクが完了した直後に、クライアントはサーバーとのTLSネゴシエーションを開始します。そのネゴシエーションが完了し、暗号化が行われた後にのみ、HTTP要求が送信されます。

15
gowenfawr

Www.example.comのサイトにアクセスしたことがないので、ブラウザはドメイン名をIPアドレスに解決する必要があります。したがって、接続しようとしているサイトのドメイン名を含むDNS解決クエリを送信します。したがって、安全なDNSを使用しない限り、MITMは接続しようとしているドメインを見つけることができます。

2
user90696