WebサーバーでSNIホールを有効にすると、セキュリティにどのような影響がありますか？
Webサーバー（Apache 2.4としましょう）はSNIを実装しています。サブジェクトの別名（land.org）を含む4096ビットのSHA384署名付きワイルドカード証明書（* .land.org）で構成されています。認証局には、SHA-2署名付きルート証明書への信頼できるパスと、SHA-1署名付きルート証明書への2番目の信頼できるパスがあります。また、このWebサーバーは、現在安全な再ネゴシエーションと見なされているものを実装しているとしましょう。
Webサーバーは、SSLv3のみが有効になっているデフォルトの仮想ホスト（wonder.land.org）用に構成されており、SSL証明書には、一意のDH1024キーと、本にある古くて安全でない暗号がすべて含まれています（暗号をエクスポートするには112ビット、など-Netscape Communicatorでさえも満足できるように配慮しています）。もう1つの仮想ホストはland.orgで、TLSv1.2とTLSv1.0が有効になっており、128ビット以上の暗号と一意のDH2048キーが使用されています。両方の仮想ホストの暗号の順序は、既知の脆弱性と暗号の強度に基づいて、最も強いものから最も弱いものまでです。
Bobは、現代の妄想を伴うTLSv1.2 Elliptic Curve暗号化をサポートする最新のブラウザーを使用するユーザーです。彼は https://land.org に毎日アクセスします。
アリスは、SSLv3を介したエクスポート暗号化をサポートする古代のWebブラウザーで使用している、スミソニアン美術館の学芸員です。彼女は https://land.org に毎日アクセスして、10BASE2接続が486DX2で引き続き機能していることを確認します。 WebブラウザーはSNIをサポートしていないため、アリスのリクエストは「SNIホール」を通過し、デフォルトの仮想ホスト（wonder.land.org）を返します。これは、「あなたのWebクライアントはサーバーをサポートしていません」という静的なHTML 2.0ページです。名前表示はプードル攻撃に対して脆弱です。博物館の展示のアップグレードを検討してください。ただし、インターネット接続は実際に機能します。」
質問（はい/いいえ）：このWebサーバーはボブのセキュリティまたは独自の（サーバーの）セキュリティを危険にさらしていますか？現在知られている脆弱性のみを検討してください。
私の直感は、SNIなしの接続を別のサーバー（Bobにサービスを提供している同じサーバーではない）に、同じサーバーの外部にある手段を介して向けたいというものでした。ディープパケットインスペクションファイアウォールのようなもので、実際にClientHelloバージョンとSNI部分を調べます。
同じサーバーでSNIホールが解析されない理由は2つあります。
1）TLSサーバー名表示とホストヘッダーは、プロトコルレイヤーによってまったく異なる機能ですが、目的は非常に似ています。このため、サーバーソフトウェアの作成者がそれらを異なる方法で解釈することには興味がない可能性があります。また、仮想ホストを選択する動作がTLS SNIレベルで発生していることをテストし続けることはやや難しいため、将来のアップグレード時に、ボブはこのメソッドを介して送信されるはずのないCookieを安全でないサーバーに送信する可能性があります（または、アリスは接続に関するリラックスした説明の代わりにエラーを受信する可能性があります。）
2）すべての弱い暗号とプロトコルのバリエーションを同じサーバーに保持することにより、サーバーソフトウェアを複雑に保ち、おそらくこれまでのところ未知の攻撃ベクトルに対応して、プロトコルの安全でないバージョンに何らかの方法で復帰/ロールバックできます。