AI tools

Server Name Indication

ウィキペディアから

Server Name Indication（SNI、サーバー ネーム インディケーション、サーバ名表示）は、SSL/TLSの拡張仕様の一つである。SSLハンドシェイク時にクライアントがアクセスしたいホスト名を伝えることで、サーバ側がグローバルIPごとではなくホスト名によって異なる証明書を使い分けることを可能にする。

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 (日本語訳) である。

SNIの暗号化

SNIも暗号化する方法が検討されている。当初、Encrypted SNI (ESNI)が検討されていたものの、その後Encrypted Client Hello (ECH)が考案され、標準化に向けた検討が進められている[4]。

対応状況

要約
視点

SNIに対応するには、アプリケーションの使うSSLライブラリがホスト名を受け取る仕組みが必要である。OSの機能を利用してSSL通信を行うアプリケーションでは、OSのSSL機能がSNIをサポートしない場合はSNIを使うことはできない。2011年の時点でほとんどのブラウザやSSLライブラリはSNIを実装したが、ユーザの使うOSとの組み合わせによってはSNIを利用できない場合がしばしばある。

対応ソフト

2004年に、OpenSSLでTLS/SNIをサポートするパッチがEdelKeyプロジェクトによって作成された[5]。このパッチは2006年開発ブランチに取り込まれ、2007年にOpenSSL 0.9.8にポートされた。

TLS/SNIをサポートするブラウザ[6]
Webサーバ
ライブラリ
  • Mozilla NSS 3.11.1[28] client-side only
  • OpenSSL
    • 0.9.8f (released 11 Oct 2007) - '--enable-tlsext' オプションを明示的に指定する必要がある
    • 0.9.8j (released 07 Jan 2009) through 1.0.0 (released 29 March 2010) - デフォルトで対応
  • GnuTLS[29]
  • wolfSSL (デフォルトでは無効だが '--enable-sni' or '--enable-tlsx' オプションにより利用可能)[30]
  • PolarSSL（英語版） 1.2.0およびそれ以降 (デフォルトで有効)
  • libcurl / cURL 7.18.1 (30 Mar 2008)
  • Python 3.2 (ssl, urllib[2] and httplib モジュール) [31]
  • Qt 4.8[32]
  • Oracle Java 7 JSSE [33]
  • Apache HttpComponents 4.3.2 [34]
  • wget 1.14[35] (1.14以前はパッチによる[36]
  • Android 2.3 (Gingerbread) (ただし部分的、HttpsURLConnection クラスを使った場合に限り対応)[37]
  • Android 3.0 (Honeycomb) [38]
  • IO::Socket::SSL (Perl/CPANモジュール, 1.83以降[39])
  • Pike 7.9.5 (SSL module) [40]

非対応ソフト

以下の組み合わせのソフトウェアはSNIに対応していない。

クライアント
サーバ
ライブラリ
  • Qt 4.7[32]
  • Mozilla Network Security Services server side [43]
  • Java 1.6 およびそれ以前 [33]
  • Apache HttpComponents 4.3.1 およびそれ以前 [34]
  • Python 2.x (ssl, urllib[2], httplib モジュール) [31]
  • PhantomJS 1.x

脚注

関連項目

外部リンク

Wikiwand - on

Seamless Wikipedia browsing. On steroids.