「Server Name Indication」の版間の差分
(→SNIの実装) |
|||
| 行32: | 行32: | ||
つまり、１つの[[IPアドレス]]で複数のドメインの[[HTTPS]]のサーバが提供できます。 | つまり、１つの[[IPアドレス]]で複数のドメインの[[HTTPS]]のサーバが提供できます。 | ||
== SNIの実装 == | == SNIの実装 == | ||
| − | SNI は、[[TLS]]の接続時の ClientHello の拡張で「接続したいドメイン」をサーバに伝えます。ClientHelloのSNIの情報をもとに、サーバは | + | SNI は、[[TLS]]の接続時の ClientHello の拡張で「接続したいドメイン」をサーバに伝えます。ClientHelloのSNIの情報をもとに、サーバは ServerHelloで適切な証明書をクライアントに渡すことができます。ただし、SNIの情報は暗号化されていません。そこで Encrypted SNI 拡張が考えられました。 |
| + | |||
== 対応状況 == | == 対応状況 == | ||
2015年の時点では、たいていのソフトウェアは対応していると考えられます。かなり古いソフトウェアは、SNIに対応していません。 | 2015年の時点では、たいていのソフトウェアは対応していると考えられます。かなり古いソフトウェアは、SNIに対応していません。 | ||
2018年11月1日 (木) 20:03時点における最新版
Server Name Indication (SNI, サーバネーム インディケーション)とは、SSL/TLSの拡張仕様です。SSLのハンドシェイクを行うときに、クライアントは、アクセスするホスト名を通知し、サーバ側はホスト名によって、証明書を使い分けします。
読み方
- Server Name Indication
- さーばねーむ いんでぃけーしょん
概要
Server Name Indication(SNI)では、複数の証明書を使い分けることができます。
SNIでは、あとから証明書を追加することで、異なるドメイン名のHTTPSのウェブサイトを追加できます。
マルチドメインのウェブサーバ
これは、SNIの話ではありません。
HTTP では、名前ベースのバーチャルホストが利用可能です。
しかしながら、HTTPSの場合は、名前ベースのバーチャルホストを利用できません。TLSプロトコルのハンドシェイクは、アプリケーション層(HTTP)の通信の前に完了されます。TLSプロトコルの段階では、接続先のホスト名を知ることはできませんでした。HTTPヘッダのホストフィールドを見るまで、どのホスト名に対してアクセスしているかわかりません。
この問題を解決するために、HTTPSのウェブサーバは、ホスト名ごとに異なるグローバルIPアドレスを利用していました。IPアドレスごとに証明書を設定します。それがIPベースのバーチャルホストになります。
複数ドメインをサポートするSSL証明書
複数のホスト名(ドメイン)をサポートする方法として
- ワイルドカード証明書
- SANs(Subject Alternative Names)
があります。 しかしながら、上記の方法は、証明書を発行するときに、未来に使うことになるドメインを予期して、入れておくことは事実上不可能です。
SNIを導入するとどうなるのか？
Server Name Indication(SNI)は、TLSのハンドシェイクを改良することにより、HTTPSのウェブサーバでも複数の証明書が利用可能になります。
つまり、１つのIPアドレスで複数のドメインのHTTPSのサーバが提供できます。
SNIの実装
SNI は、TLSの接続時の ClientHello の拡張で「接続したいドメイン」をサーバに伝えます。ClientHelloのSNIの情報をもとに、サーバは ServerHelloで適切な証明書をクライアントに渡すことができます。ただし、SNIの情報は暗号化されていません。そこで Encrypted SNI 拡張が考えられました。
対応状況
2015年の時点では、たいていのソフトウェアは対応していると考えられます。かなり古いソフトウェアは、SNIに対応していません。