サーバー名の表示

サーバー名表示( SNI ) は、トランスポート層セキュリティ (TLS)コンピュータ ネットワーク プロトコルの拡張機能であり、クライアントがハンドシェイク プロセスの開始時に接続しようとしているホスト名を示します。 ^[1]この拡張機能により、サーバーは同じIP アドレスとTCP ポート番号で複数の証明書のうち 1 つを提示できるため、複数の安全な ( HTTPS ) Web サイト (または TLS 経由のその他のサービス) を同じ IP アドレスで提供できます。すべてのサイトで同じ証明書を使用する必要はありません。これは、HTTP/1.1 の名前ベースの仮想ホスティングと概念的に同等ですが、HTTPS 用です。これにより、プロキシは TLS/SSL ハンドシェイク中にクライアント トラフィックを適切なサーバーに転送することもできます。元の SNI 拡張機能では目的のホスト名が暗号化されていないため、盗聴者は要求されているサイトを確認できます。SNI 拡張機能は、2003 年にRFC  3546 で指定されました。

SNI 以前は、TLS 接続を行う際に、クライアントは接続先のサイトを指定することができませんでした。そのため、1 つのサーバーが単一のリスナーで複数のサイトをホストしている場合、サーバーは TLS プロトコルでどの証明書を使用するかを知る方法がありません。詳しく言うと、TLS 接続を行う際に、クライアントは Web サーバーにデジタル証明書を要求します。サーバーが証明書を送信すると、クライアントは証明書を調べ、接続先の名前と証明書に含まれる名前を比較します。一致した場合は、接続は通常どおり続行されます。一致が見つからない場合は、不一致が中間者攻撃の試みを示している可能性があるため、ユーザーに不一致の警告が表示され、接続が中止されることがあります。ただし、一部のアプリケーションでは、ユーザーが警告をバイパスして接続を続行できます。この場合、証明書を信頼する責任、ひいては接続を信頼する責任はユーザーにあります。

しかし、サーバーが管理するすべての名前をカバーする単一の証明書を取得することは困難である可能性があり、すべての名前の完全なリストが事前にないため、不可能になることもあります。複数のホスト名を管理するサーバーは、名前ごと（または名前の小さなグループ）に異なる証明書を提示する必要がある可能性があります。subjectAltName を使用すると、1人の人物^[2]によって管理される複数のドメインを単一の証明書に含めることができます。このような「統合通信証明書」は、ドメインのリストが変更されるたびに再発行する必要があります。

名前ベースの仮想ホスティングでは、複数の DNS ホスト名を単一のサーバー (通常は Web サーバー) で同じ IP アドレス上でホストできます。これを実現するために、サーバーはプロトコルの一部としてクライアントが提示したホスト名を使用します (HTTP の場合、名前はホスト ヘッダーで提示されます)。ただし、HTTPS を使用する場合、サーバーが HTTP ヘッダーを確認する前に TLS ハンドシェイクが行われます。そのため、サーバーは HTTP ホスト ヘッダーの情報を使用してどの証明書を提示するかを決定することができず、同じ IP アドレスからは、同じ証明書でカバーされている名前しか提供できませんでした。

実際には、これは、安全で効率的なブラウジングのために、HTTPS サーバーが IP アドレスごとに 1 つのドメイン (またはドメインの小グループ) しか処理できないことを意味していました。サイトごとに個別の IP アドレスを割り当てると、IP アドレスの要求を地域のインターネット レジストリに正当化する必要があり、IPv4 アドレスが枯渇しているため、ホスティング コストが増加します。IPv6 の場合、アドレス空間が枯渇していないにもかかわらず、1 台のマシンに複数の IP が存在するため、管理オーバーヘッドが増加します。その結果、多くの Web サイトが安全な通信の使用を事実上制限されました。

SNI は、クライアントが TLS ネゴシエーションのClientHelloメッセージの一部として仮想ドメイン名を送信することで、この問題に対処します。 ^[3]これにより、サーバーは正しい仮想ドメインを早期に選択し、正しい名前を含む証明書をブラウザーに提示できます。したがって、SNI を実装するクライアントとサーバーを使用すると、単一の IP アドレスを持つサーバーで、共通の証明書を取得することが非現実的なドメイン名のグループに対応できます。

SNI は、2003 年 6 月に RFC 3546「トランスポート層セキュリティ (TLS) 拡張」を通じてIETFのインターネット RFCに追加されました。この標準の最新バージョンは RFC 6066 です。

サーバー名表示ペイロードは暗号化されていないため、クライアントが接続しようとしているサーバーのホスト名は盗聴者に見える状態です。このプロトコルの弱点は、ネットワークフィルタリングと監視のためのセキュリティソフトウェア^{[4] [5] [6]}や、検閲を実施するための政府によって悪用されました。^[7]

現在、サーバー名表示を隠そうとする技術は複数あります。

ドメイン フロンティングは、SNI 内の目的のホスト名を、同じサーバー、またはより一般的にはコンテンツ配信ネットワークと呼ばれるサーバー ネットワークによってホストされている別のホスト名に置き換える手法です。クライアントがドメイン フロンティングを使用すると、サーバー ドメインが SNI (暗号化されていない) に置き換えられますが、サーバーが適切なコンテンツを提供できるように、HTTP ホスト ヘッダー (TLS によって暗号化されている) にはそのまま残ります。ドメイン フロンティングは SNI 自体を定義する標準に違反するため、互換性が制限されます (多くのサービスは、SNI ホストが HTTP ヘッダー ホストと一致するかどうかを確認し、ドメイン フロンティングされた SNI との接続を無効として拒否します)。ドメイン フロンティングは、以前は政府の検閲を回避するために使用されていましたが、^[8]主要なクラウド プロバイダー (Google、Amazon の AWS、CloudFront) が利用規約で明示的に禁止し、技術的な制限を設けているため、その人気は低下しました。^[9]

暗号化クライアントHello（ECH）は、TLS 1.3ネゴシエーションの初期段階で送信されるクライアントHelloメッセージ全体の暗号化を可能にするTLS 1.3プロトコル拡張です。 ^[10] ECHは、証明書利用者（Webブラウザ）が事前に知っておく必要がある公開鍵を使用してペイロードを暗号化します。つまり、ECHはブラウザベンダーが事前に知っている 大規模なCDNで最も効果的です。

この拡張機能の2018年版はEncrypted SNI (ESNI) ^[11]と呼ばれ、ドメイン盗聴のリスクに対処するために「実験的」な形で実装されました。^{[12] [13] [14]} Firefox 85ではESNIのサポートが削除されました。^[15] ECHとは対照的に、Encrypted SNIはClient Hello全体ではなくSNIのみを暗号化しました。^[16]このバージョンのオプトインサポートは2018年10月にFirefoxに組み込まれ^[17]、DNS over HTTPS (DoH) を有効にする必要がありました。^[18]

2020年3月、分析によりSNIのみを暗号化するだけでは不十分であることが実証された後、ESNIはECH拡張に作り直されました。たとえば、仕様では、セッション再開を容易にするためのあらゆるデータを事前共有キー拡張に含めることが許可されており、ESNIによって暗号化されたサーバー名とまったく同じクリアテキストのコピーを送信することさえ可能です。また、拡張機能を1つずつ暗号化するには、すべての拡張機能の暗号化されたバリアントが必要になり、それぞれがプライバシーに影響を与える可能性があり、宣伝されている拡張機能のセットが公開されます。最後に、ESNIの実際の展開により、相互運用性の制限が明らかになりました。^[19]短縮名は2020年3月にECHOでしたが^[16]、2020年5月にECHに変更されました。^[20]

ESNIとECHはどちらもTLS 1.3で初めて定義されたKeyShareEntryに依存しているため、TLS 1.3とのみ互換性があります。^{[21] [22]}また、ECHを使用するには、クライアントは1.3未満のTLSバージョンを提案してはなりません。^[23]

別のインターネットドラフトでは、ECH公開鍵をHTTPSおよびSVCB DNSレコードタイプ経由で送信するためのパラメータが組み込まれており、ハンドシェイクプロセスが短縮されています。^{[24] [25]}

2020年8月、中国のグレートファイアウォールはESNIトラフィックをブロックし始めましたが、ECHトラフィックは引き続き許可しました。^[26]

2020年10月、ロシアのISPロステレコムとそのモバイルオペレーターTele2はESNIトラフィックのブロックを開始しました。^[27]同年9月、ロシアの検閲省ロスコムナゾールは、ウェブサイトアクセスの検閲を妨げるTLS 1.3とESNIを含む一連の暗号化プロトコルを禁止する計画を立てました。^{[28] [29] [30]}

2023年7月のIETF117会議で、ECHに取り組んでいるメンバーは、ChromeとFirefoxが1％のサンプルトライアルを実施していることを通知し、チームは最終ドラフトが2024年1月までにIESG評価に提出されることを期待しています。 ^{[31] [32]}

2023年9月、Cloudflareはホストドメインに対してECHのサポートを開始しました。^[33]

2023年10月、MozillaはFirefox v118でECHをデフォルトで有効化しましたが、DNS over HTTPS（DoH）も有効化されていることを条件としました^{[34] [35] 。これにより、} HTTPSリソースレコードに対するDNSリクエストがコンピュータネットワーク上で盗聴されるのを防ぐことができます。 ^[36] 2023年9月、Chromiumバージョン117（Google Chrome、Microsoft Edge、Samsung Internet、Operaで使用）ではこれをデフォルトで有効化し、DNSのHTTPSリソースレコードにキーを展開することも要求しました。^{[37] [38]}

2004年、 OpenSSLにTLS/SNIを追加するためのパッチがEdelKeyプロジェクトによって作成されました。^[39] 2006年にこのパッチはOpenSSLの開発ブランチに移植され、2007年にOpenSSL 0.9.8（最初に0.9.8fでリリースされました^[40]）にバックポートされました。SNIをサポートする最初のWebブラウザは2006年に登場し（Mozilla Firefox 2.0、Internet Explorer 7）、その後Webサーバーが登場しました（2009年にApache HTTP Server、2012年にMicrosoft IIS）。

アプリケーション プログラムが SNI を実装するには、使用する TLS ライブラリが SNI を実装し、アプリケーションがホスト名を TLS ライブラリに渡す必要があります。さらに複雑なことに、TLS ライブラリはアプリケーション プログラムに含まれている場合もあれば、基盤となるオペレーティング システムのコンポーネントである場合もあります。このため、一部のブラウザーはどのオペレーティング システムでも SNI を実装しますが、他のブラウザーは特定のオペレーティング システムでのみ SNI を実装します。^{[引用が必要]}

• RFC 6066 ( RFC 3546 を廃止した RFC 4366 を廃止)
• Mozilla Wiki - 暗号化クライアント Hello (ECH)