Server Name Indication

索引トップ用語の索引ランキングカテゴリー

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/11/18 13:56 UTC 版)

SNIは特に、HTTP 1.1の名前ベースバーチャルホストをHTTPSに対応させるために使われる。SNIを機能させるには、Webサーバ側とブラウザ側両面の対応が必要である。SNIを実装しないブラウザでは全てのホスト名で同じサーバ証明書が使われるため、警告が表示されることがある。2016年時点でPC・モバイルの主要なブラウザで問題なく利用できる状況である。

問題の背景

SSL/TLS接続のはじめに、クライアントはSSL/TLSのサーバから（サーバとCAの）証明書を受け取り、証明書の改ざんされていないことなどを確認する。サーバ証明書にはホスト名が書かれており、それが今接続しようとしているホスト名と一致することをクライアントは確認する。そうでない場合、なりすましや中間者攻撃の恐れがあるため、クライアントはユーザに警告をする。ユーザの責任で証明書を信用し、警告を迂回することができるアプリケーションも存在する。

HTTPの場合、名前ベースバーチャルホストを使うと、複数のホスト名（同一のドメインであれ、異なるドメインであれ）を単一のサーバと単一のグローバルIPで運用できる。これは、ブラウザ側がHTTPヘッダによって希望のホスト名を指定することで働く。しかし、HTTPSの場合、HTTP要求をやりとりする前にSSL/TLSハンドシェイクを行う必要がある。このため、ブラウザがどのホストを訪問するかを、ハンドシェイク時点でサーバ側には予測できず、HTTPヘッダのホスト名によって複数枚のサーバ証明書を使い分けることができない。したがって、単一のサーバで複数枚のサーバ証明書を使い分けるには名前ベースバーチャルホストは利用できず、ホスト名ごとに異なるグローバルIPを使う必要があった（IPベースバーチャルホスト）。

この問題への対処方法として、1枚のサーバ証明書に複数のホスト名を指定する手段が知られていた。X.509 v3の証明書で導入されたsubjectAltName拡張を利用することで、追加のホスト名を指定できる。通常、主体者のCommon Name属性同様、こちらでもワイルドカードを使える。しかし、実運用においてサーバの運用する全てのホスト名を予めCSRに含めておくことは現実的ではなく、ホスト（ワイルドカードの場合、ドメイン）名が増えるたびに別々にサーバ証明書を導入することが多い。2005年から、CAcertはTLSをバーチャルホスト下で使う方法について様々な実験を行なった^[1]が、多くは非実用的なものだった。例えば、subjectAltName拡張を使って運用する全ドメインのホスト名を1枚のサーバ証明書に集約し、ドメインが増えたりドメイン名が変わったりするごとに取得しなおすという方法^[2]が提案された。

これらの事情によって、複数のサーバ証明書を使い分けたいサーバは、単数または少数のホスト名をIP別に運用することが要求される。ホスト（ワイルドカードの場合、ドメイン）名ごとに別のグローバルIPを取得することはコストがかかる（IPアドレス枯渇問題）ため、多くのWebサイトにはHTTPS通信の利用はハードルが高かった。

SNIによる解決

Server Name Indication（SNI）では、TLSに拡張を加えることでこの問題に対処する。TLSのハンドシェイク手続きで、HTTPSクライアントが希望するドメイン名を伝える（この部分は平文となる）^[3]。それによってサーバが対応するドメイン名を記した証明書を使うことが可能になる。サーバとクライアントが共にSNIに対応していれば、一つのIPで複数のドメインにHTTPSサーバを提供することが可能になる。

SNIは2003年6月、RFC 3546「TLS拡張仕様」に加わった。その後更新され、2014年1月現在、SNIの記述のある最新の仕様はRFC 6066 (日本語訳) である。

脚注