コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

Server Name Indication

出典: フリー百科事典『ウィキペディア（Wikipedia）』

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

脚注

[編集]
  1. ^ “CAcert VHostTaskForce”. CAcert Wiki. 2012年8月26日閲覧。
  2. ^ “What is a Multiple Domain (UCC) SSL Certificate?”. 2012年8月26日閲覧。
  3. ^ “TLS Server Name Indication”. Paul's Journal. 2012年8月26日閲覧。
  4. ^ Patton, Christopher (2020年12月8日). “Good-bye ESNI, hello ECH!”. 2022年8月6日閲覧。
  5. ^ “EdelKey Project”. 2012年8月26日閲覧。
  6. ^ Brand, Kaspar (2009年3月29日). “TLS SNI Test Site”. 2012年8月26日閲覧。
  7. ^ “Understanding Certificate Name Mismatches” (2009年12月7日). 2013年7月8日閲覧。
  8. ^ Opera (2005年2月25日). “Changelog for Opera [8] Beta 2 for Windows” (via Archive.org). Opera Changelogs for Windows. Opera.com. 2005年11月23日時点のオリジナルよりアーカイブ。2013年7月19日閲覧。 “Readded experimental support for TLS Extensions and TLS 1.1. Setting is disabled by default.”
  9. ^ “Google Chrome, Issue 43142, Use SSLClientSocketNSS on Windows by default” (2010-10-29 - Although many report Chrome 8 does not work with SNI on XP and Win7). 2012年8月26日閲覧。
  10. ^ Kehrer, Paul. “SNI in iOS 4.0”. 22 November 2010閲覧。
  11. ^ “Bug 122433: Server Name Identification support”. Bugs.kde.org. 2011年7月18日閲覧。
  12. ^ “Issue 12908 - android Https - websites that support Server Name Indication (SNI) don't work”. code.google.com. 23 August 2011閲覧。
  13. ^ “Bug 34607: Support for Server Name Indication”. Apache Software Foundation. 2012年8月26日閲覧。
  14. ^ “Revision 776281: adding support for Server Name Indication to the Apache 2.2.x branch”. Apache Software Foundation. 2012年8月26日閲覧。
  15. ^ “CHANGES: Server Name Indication support is listed under the changes for Apache 2.2.12”. Apache Software Foundation. 2012年8月26日閲覧。
  16. ^ Notaras, George (2007年8月10日). “SSL-enabled Name-based Apache Virtual Hosts with mod_gnutls”. 2012年8月26日閲覧。
  17. ^ “1.4.24 - now with TLS SNI and money back guarantee”. Blog.lighttpd.net. 2011年3月8日閲覧。
  18. ^ “#386 (TLS servername extension (SNI) for namebased TLS-vhosts)”. Trac.lighttpd.net. 2011年3月8日閲覧。
  19. ^ “sol13452: Configuring a virtual server to serve multiple HTTPS sites using TLS Server Name Indication (SNI) feature”. ask.f5.com. 2012年3月26日閲覧。
  20. ^ “IBM HTTP Server SSL Questions and Answers”. Publib.boulder.ibm.com. 2011年3月8日閲覧。
  21. ^ “IHS 8 powered by Apache 2.2.x ?”. Publib.boulder.ibm.com. 2011年3月8日閲覧。
  22. ^ “Apsis Gmbh”. apsis.ch. 2011年8月18日閲覧。
  23. ^ “What’s New in IIS 8”. weblogs.asp.net. 2012年4月1日閲覧。
  24. ^ “Open Source PageKite”. PageKite.net. 2012年4月18日閲覧。
  25. ^ “SSL/TLS back-ends, endpoints and SNI”. PageKite.net. 2012年4月18日閲覧。
  26. ^ “Configuring an SSL Virtual Server for Secure Hosting of Multiple Sites”. Citrix. 5 July 2012閲覧。
  27. ^ “Introducing AlteonOS 28.1! - Knowledge Base - Radware”. kb.radware.com. 2012年8月20日閲覧。
  28. ^ “NSS 3.11.1 Release Notes”. Mozilla.org. 2011年3月8日閲覧。
  29. ^ “TLS Extensions”. Gnu.org (2010年8月1日). 2011年3月8日閲覧。
  30. ^ “Using Server Name Indication (SNI) with CyaSSL”. wolfSSL.com (2013年5月24日). 2013年11月25日閲覧。
  31. ^ a b “Support TLS SNI extension in ssl module”. Bugs.python.org. 2011年3月8日閲覧。
  32. ^ a b “QTBUG-1352. It would be useful if QSslSocket supports TLS extensions such as Server Name Indication as per RFC 3546.”. Qt Bug Tracker. 2011年4月15日閲覧。
  33. ^ a b “Java SE 7 Release Security Enhancements”. download.oracle.com. 2012年12月12日閲覧。
  34. ^ a b “HttpComponents HttpClient 4.3.2 Released”. 2014年1月25日閲覧。
  35. ^ “News: GNU wget 1.14 released”. GNU Wget (2012年10月19日). 2013年7月19日閲覧。
  36. ^ “Bugs: bug #26786, TLS SNI support”. GNU Wget (2010年10月29日). 2012年8月26日閲覧。
  37. ^ “Android’s HTTP Clients”. Google. 3 August 2012閲覧。
  38. ^ “Issue 12908: Https websites that support Server Name Indication (SNI) don't work”. Google. 3 August 2012閲覧。
  39. ^ “IO::Socket::SSL Changes file mentions introduction of SNI”. 2013年7月19日閲覧。
  40. ^ “Pike's SSL module”. 30 August 2013閲覧。
  41. ^ “Understanding Certificate Name Mismatches”. Blogs.msdn.com. 2011年3月8日閲覧。
  42. ^ “Android issue 1290 - Https websites that support Server Name Indication (SNI) don't work”. Code.google.com (2010年12月1日). 2011年12月13日閲覧。
  43. ^ “NSS Roadmap (as of 11 September 2009)”. Wiki.mozilla.org. 2011年3月8日閲覧。

関連項目

[編集]

外部リンク

[編集]
プロトコル
技術
歴史
実装
公証
脆弱性
理論
暗号
プロトコル
実装
「https://ja-two.iwiki.icu/w/index.php?title=Server_Name_Indication&oldid=97693365」から取得