概要
仮想ホスティング 上の複数のウェブサイトを提供する慣行です 同じサーバー。 現在では当たり前のことですが、HTTPの初期（バージョン1.1より前）ではこれは不可能でした。
元々、各Webサイトに専用ポートが割り当てられていれば、サーバーは同じマシン上で（つまり、同じIPアドレスの下で）複数のWebサイトしかホストできませんでした。 ブラウザはデフォルトでポートするため、これは理想的なソリューションではありませんでした 80 HTTPの場合、ユーザーが別のものを指定しない限り。 その結果、ほとんどのWebサイト所有者は、ユーザーが正しいポート番号を覚えておらず、別のWebサイトに到達するリスクを回避するために専用サーバーを選択しました。
それにもかかわらず、より多くのユーザーがWebに参加し、より多くのネットワークデバイスがオンラインで表示されるようになると、使用可能なIPアドレスの数は驚くべき速度で減少し始めました。 この予想される枯渇は、 IPv4アドレス範囲の枯渇、などのさまざまな対策を設計および実装するよう業界を推進してきました。 IPv6 （IPv4の後継）、サポートできる 必要以上のアドレス。 残念ながら、IPv6は実行可能なソリューションですが、その採用は非常に遅いものです。 による GoogleのIPv6統計この記事の執筆時点では、インターネットデバイスの約25％のみがIPv6を介して展開されています。
仮想ホスティングは、疲労問題の初期の緩和策として実装され、 Host HTTP 1.1のヘッダー。 HTTP 1.1を介して通信するブラウザーがサーバーのポートに接続できるようになりました 80 ドメイン名（例： www.ssl.com）にアクセスしたいWebサイトの Host ヘッダ。 サーバーが同じポートでホストしているサイトの数に関係なく、この情報を使用して正しいWebサイトを識別し、そのコンテンツを返すことができます。
HTTPSおよび仮想ホスティング
しかし、ネットワークの脆弱性とWebユーザーに対する攻撃に関する数多くの公開されたレポートにより、業界は 安全でないHTTPから、より安全な代替HTTPSへの移行を開始する。 の幅広い採用 HTTPS 全体的なユーザーセキュリティが向上しました。 ただし、その追加の機能強化により、Web通信の一般的な複雑さも増しています。
原則として、HTTPSは、ブラウザとサーバー間のHTTPS通信が暗号化されることを除いて、HTTPと非常によく似ています。 簡単に言うと、HTTPSでは、サーバーは、公的に信頼されているものによって発行された有効なSSL証明書をブラウザーに提供する必要があります。 証明する機関 （CA）など SSL.com。 ブラウザは証明書に含まれる公開鍵を使用して サーバーとの暗号化された通信チャネルを確立する。 さらに、特定のドメイン名に対して証明書が発行され、ブラウザはユーザーがアクセスしたいドメインとの一致をチェックします。 したがって、サーバーがホストするWebサイトの数に関係なく、ブラウザーは、要求したWebサイトの有効なSSL証明書を見つけることを期待します。
注意深い読者はすでに問題を感知している可能性があります。暗号化されたチャネルを確立して送信するには、ブラウザに正しいWebサイトの証明書が必要です Host ヘッダー、サーバーは Host 正しいサイトの証明書を見つけるためのヘッダー。 これは典型的な鶏と卵の問題です。
HTTPで想定された仮想ホスティングはHTTPSでは機能しないことは明らかです。これは、セキュリティ制御によりブラウザーが Host サーバーへの情報。 それでもなお、IPv4の枯渇問題は未解決であり、（ロードバランシングと複数のフェイルオーバーバックエンドサーバーを必要とする）クラウドテクノロジーの業界での採用の増加に伴い、仮想ホスティングは依然として必要です。
マルチドメイン証明書はどうですか？
この問題に対する提案された解決策は、マルチドメインまたは SAN証明書。 XNUMXつのSAN証明書で数百の異なるドメイン名を保護できます。ブラウザは、アクセスしようとしているドメイン名がSAN証明書のドメインリスト内で見つかっても問題ありません。 暗号化されたチャネルが構成された後、ブラウザは Host 他の場合と同様に、サーバーへのヘッダーと続行します。 これは、すでに存在し利用可能なテクノロジーを利用する優れたアイデアですが、SAN証明書のセキュリティを保証する同じメカニズムによって、いくつかの望ましくない可能性のある副作用が発生しました。
SAN証明書は、同じエンティティ（個人、会社、または組織）が所有する複数のドメインを保護するための優れたツールですが、共有ホスティングでの使用はやや実用的ではありません。 新しいドメインを証明書に追加または証明書から削除する準備ができている場合は常に、最新のドメインリストを含む新しい証明書をCAが発行し、すべてのドメインに再展開する必要があります。
さらに、SAN証明書は次のようにのみ発行できます。 組織検証済み（OV）または拡張検証済み（EV） if を ドメインは同じ組織に属しています。 これらの検証レベルは、 CAによって検証される証明書の所有者候補の情報の量とタイプ 証明書を発行する前。 検証レベルが高いほど、ユーザーがWebサイトに置く信頼が高まり、ユーザーの信頼がブランドの認知度とコンバージョン率に影響を与える可能性があることが示されています。
最後に、共有Webホスティング環境では、企業がサーバーを他の企業や組織（競合他社を含む）と共有することは非常に一般的です。 SAN証明書のドメインは公開されているため、ビジネスオーナーは同じ証明書をサードパーティ企業と共有することに消極的かもしれません。
SAN証明書は無数のアプリケーションを備えた強力で用途の広いツールですが、これらの問題により、IETF（インターネット標準の統治機関）が仮想的にホストされたHTTPS Webサイトの特定の問題に対するより適切なアプローチを探す動機になっています。
レスキューへのサーバー名の表示
ソリューションは、の形で実装されました サーバ名表示 (SNI）の拡張 TLS プロトコル（暗号化を処理するHTTPSの一部）。
SNIを使用すると、ブラウザは接続中に接続するドメイン名を指定できます。 TLS 握手 （サーバーとの最初の証明書ネゴシエーション）。 結果として、HTTPSサーバーはSNI情報を使用して接続の確立に必要な適切な証明書チェーンを識別できるため、Webサイトは共有IPアドレスとポートでホストされたまま独自のSSL証明書を使用できます。
その後、暗号化された通信チャネルが設定されると、ブラウザはウェブサイトのドメイン名を Host ヘッダーを付け、通常どおり続行します。 基本的に、SNIはHTTPと同じ機能を実行します。 Host 暗号化された接続の作成中のヘッダー。
この単純なトリックにより、サーバーは最終的に同じポートで複数のHTTPSWebサイトをホストできるようになりました。 ただし、ほとんどのインターネットテクノロジと同様に、SNIにはいくつかの制限があります。
SNIサポートに関する懸念
SNIは、1999年に最初にドラフトされて以来かなり成熟していますが、それをサポートしていないレガシーブラウザ（Windows XPのIE）とオペレーティングシステム（Androidバージョン<= 2.3）がまだいくつかあります。 SNIをサポートするブラウザとオペレーティングシステムの包括的なリストについては、以下をご覧ください。 この表.
SNIをサポートしないブラウザーの市場シェア（ひいてはこの発生の発生）は、最新のブラウザーと比較するとごくわずかですが、ブラウザーがSNIを認識しない場合は、デフォルトのSSL証明書にフォールバックし、 一般名の不一致エラー.
Googleなどの多くの企業は、SNIをサポートするクライアントに実装し、それをサポートしないまれなケースではSAN証明書にフォールバックします。 当然のことながら、ユーザーやビジネスオーナーがシステムを最新のテクノロジーにアップグレードするにつれて、この問題は減少すると予想されます。
SNIプライバシーの懸念
現在の安定版 TLS （バージョン1.2）は、ハンドシェイクの最初の部分を送信し、暗号化されていないSNI情報を送信します。 その結果、Web通信自体が完全に暗号化されていても、ネットワーク攻撃者はユーザーのWeb履歴を発見できます。
AmazonやGoogleなどのさまざまなクラウドサービスプロバイダーが、次のような（汚い）回避策を許可しています。 ドメイン前線。 ドメインの前面処理は、クラウドプロバイダーのホスト名を使用してSNI情報を難読化するため、Web履歴の開示を防ぐことができます。 TLS ネゴシエーションとターゲットサイトのHTTPヘッダー。 ただし、GoogleとAmazonが公に述べているため、この方法はもはや実行可能ではありません。 ドメインフロントリングの無効なサポート 2018年XNUMX月現在のサービス。
幸いなことに、より体系的なソリューションが提案されています 実験草案 詳細 暗号化されたSNI (エスニ）最新の拡張 TLS バージョン、1.3。 ESNIはSNI情報を暗号化するため、プライバシーの問題をすべて軽減できます。 残念ながら、 TLS 1.3はまだ業界で広く採用されていません TLS 1.3は徐々に事実上のネットワークセキュリティプロトコルになりつつあります。 ESNIのステータスとHTTPSのプライバシーについての私たちからの今後の記事に注意してください TLS.
まとめ
要約すると、SNIを使用すると、数百万のHTTPS Webサイトを単一のサーバーでホストできます。 ただし、個々のケースによっては、SAN証明書の方が適している場合があります。 ESNIには潜在的な解決策も存在しますが、SNIに関するプライバシーの懸念は依然として存在しています。 いずれの場合も、これらXNUMXつの方法のXNUMXつまたは組み合わせを使用して、最小限の労力ですべてのWebサイトに仮想ホスティングを簡単に実装できます。
SNIについてさらに質問がある場合、またはSANとSNIのどちらを選択するかわからない場合は、お客様に関するすべての質問にいつでもお答えします PKI ニーズ。 ちょうど私たちにメールをドロップ support@ssl.com 専門家がお手伝いします。
