HTTPSリクエストにホスト名がクリアテキストで含まれるのはなぜですか？
HTTPSプロトコルにホスト名がプレーンテキストで含まれている理由を理解するのに少し問題があります。 HTTPSパケットのホスト名とIPアドレスは暗号化されていません。
ホスト名を暗号化できないのはなぜですか？宛先IPをプレーンテキストのままにして（パケットがルーティング可能になるように）そのままにしておくことはできません。パケットが宛先サーバーに到着すると、パケットが復号化され、ホスト/インデックスがヘッダーから識別されますか？
たぶん問題は、特定の宛先IPごとに異なる証明書（異なるサブドメインでは異なる証明書？）が存在する可能性があるため、宛先サーバーは、サーバー内の正しいホストに到着するまでパケットを復号化できないことです。これは理にかなっていますか、それとも私は出発しますか？
ホスト名は、最初のSSLハンドシェイクに含まれており、同じIPアドレス（SNI：Server Name Indication）に複数のホスト名（異なる証明書を持つ）を持つサーバーをサポートします。これは、プレーンなHTTPリクエストのHost-headerに似ています。この名前は、クライアントからの最初のメッセージ（ClientHello）に含まれています。つまり、識別と鍵交換が行われる前に、サーバーが識別用の正しい証明書を提供できるようにします。
ホスト名を暗号化するのは良いことですが、問題は暗号化に使用するキーです。鍵交換は、証明書によるサイトの識別後にのみ行われます。そうしないと、中間者と鍵を交換する可能性があるためです。ただし、サーバーが一致する証明書を提供できるように、証明書による識別にはすでにホスト名が必要です。したがって、ホスト名の暗号化は、他の種類の識別に基づいて、または中間者に対して安全ではない方法で、キーを使用して行う必要があります。
SSLハンドシェイクでホスト名を保護する方法はありますが、ハンドシェイクとインフラストラクチャで追加のオーバーヘッドが発生します。暗号化されたSNIをTLS 1.3に組み込むかどうか、および組み込む方法については、現在進行中の議論があります。 このプレゼンテーション と IETF TLSメーリングリスト をご覧になることをお勧めします。
それとは別に、ホスト名の漏洩は、前述の名前のDNSルックアップなどの他の手段によっても発生する可能性があります。そしてもちろん、サーバーの応答で送信される証明書も暗号化されていないため（同じ問題、まだキーはありません）、サーバーの応答から要求されたターゲットを抽出できます。
Cloudflaresのすべての無料SSLオファーのように、SNIなしでは機能しないサイトはたくさんあります。 SNIをサポートしていないクライアント（Windows XPのIE8など）からアクセスすると、誤った証明書が提供されるか、 'unknown_name'などのSSLハンドシェイクエラーが発生します。
[〜＃〜] sni [〜＃〜] は、仮想ホスティング（同じIPアドレス上にある、名前が異なる複数のサーバー）用です。 SSLクライアントは、SSLサーバーに接続するときに、適切なサーバーと通信しているかどうかを知りたいと考えています。そのために、証明書で目的のサーバーのnameを探します。すべての悪意のあるハッカーは自分のサーバー（evilhacker.comと呼ばれる）の証明書を購入できますが、クライアントブラウザが接続しようとするため、honest-bank-inc.comを装った偽のサーバーに証明書を使用することはできません。 https://honest-bank-inc.com/は、目的のサーバー証明書で文字列honest-bank-inc.comを検索する際に非常に厳格であり、evilhacker.comではありません。
ここまでは順調ですね。その後、技術的な部分になります。 「HTTPS」では、SSLにカプセル化されたHTTPがあります。これは、SSLトンネルが最初に確立され（「ハンドシェイク」手順）、次にクライアントがそのトンネル内でHTTPリクエストを送信することを意味します。ハンドシェイク中に、サーバーは証明書をクライアントに送信する必要があります。しかし、その時点では、クライアントはまだサーバーに誰と通信しようとしているのかを伝えていません。サーバーは、接続を受信したため、クライアントが到達しようとしている名前がサーバーがホストしているサイト名の1つであると想定している可能性があります。しかし、それは当て推量であり、サーバーが異なる名前の複数のサイトをホストしている場合は失敗します。
この難問には、主に3つの方法があります。
サイトごとに1つのIP。サーバーは接続の最初からターゲットIPアドレスを知っているので、サーバーはそのIPアドレスを使用して、どのサーバーが真のターゲットであるかを知ることができます。もちろん、IPアドレスの relative shortage により、この従来のソリューションは、今日ではあまり魅力的ではありません。
サーバー証明書のいくつかの名前。これは完全に有効です。 Google自身も、証明書に70を超える名前を付ける傾向があります。バリアントは「*」を含む「ワイルドカード名」で、多くの名前と一致します。ただし、これは、証明書の発行時にすべての名前がわかっている場合にのみ機能します。 Webサイトホスティングサービスの場合、これは顧客が登録するたびに新しい証明書を購入することを意味します。
SNI。 SNIを使用すると、クライアントは、サーバーが証明書を送信する前に、ハンドシェイクの早い段階で目的の名前を送信します。これは最新のソリューションであり、Windows XPが瀬戸際を越えたため、ついに広く使用できるようになりました（Windows上のIE XPが最後のブラウザでしたそれはSNIをサポートしていませんでした）。
何らかのサーバーと通信しているという事実は、明らかにIPから隠すことはできません。パケットはマシンを出て、ネットワークに入り、宛先にルーティングされ、配信される必要があります。 https://www.fred.com からページを配信するサーバーに接続していることは秘密ではありません。
ただし、URLにはIPが含まれていません。代わりに、複数の情報が含まれています。ホスト名（IPアドレスに解決する必要がある）が含まれているだけでなく、特定の要求に関する詳細が含まれています。www、search、mailなどの名前のサーバーに、このディレクトリパスに沿ってルーティングします。名前。
ホスティングサービスは、サーバー名表示を介して単一のWebサーバー上の複数のサイトをサポートするために、この間接性を利用しました。したがって、 https://www.fred.com と https://www.barney.com の両方が127.0.0.1のサーバーでホストされている可能性があります。サーバーがそのメッセージを内部的にルーティングする方法を区別する名前。セキュリティ上の理由から、実際のキーが格納される別のサーバーにルーティングする必要がある可能性があります。そのメッセージを復号化するためのキーがそのフロントエンドサーバーに存在しない可能性があるため、fredサイトをホストしているマシンに到着するまで、メッセージを復号化できません。
証明書を解決するためにホスト名を含める必要があることに加えて、SNIの使用に関連する1つの一般的な慣行があります。これは知っておくことが重要です。これにより、実装が可能になります https://en.wikipedia.org/wiki/Virtual_hosting SSL/TLS経由。
SNIは、一般的なすべてのWebサーバーで使用されています。