[9] TLS の SNI は、クライアントがサーバーに対して接続中のサーバーの名前を知らせるものです。 バーチャルホスト (単一のネットワークアドレスによって複数の名前のホストを提供するもの) の実装のために必要です。

[25] SNI は TLS拡張であり、仕様上は必須とはされていません。近年 SNI による HTTPS バーチャルホストが普及してきており、クライアントは事実上 SNI への対応が必要です。 SNI に対応しない HTTPS クライアントは Web互換ではありません。

仕様書

プロトコル

[10] クライアントは、 ClientHello の TLS拡張 server_name にサーバーの名前を指定できます >>8。 クライアントは、対応している種類の名前のサーバーに接続する時は server_name を指定するべきです >>18。

[12] サーバーは、 SNI に対応していて、かつ指定されたサーバー名を認識できないなら、 unrecognized_name (112) fatal alert を送信するか、ハンドシェイクを継続するかのいずれかとするべきです >>18。

[34] Apache も www.google.com, www.yahoo.com, github.com, herokuapp.com のいずれも、 SNI でおかしな値を指定しても、 エラーや警告とはせず、同じ値を送り返してきます。 (HTTP応答には Host: の値を使い、 SNI で指定された値は無視しているようです。) [35] CloudFlare は SNI でおかしな値を指定すると internal_error fatal alert とします。 (>>34 はサーバー側で SNI により分岐していないと思われます。 CloudFlare は SNI により証明書の選択を行っているようです。)

[20] サーバーは、 ClientHello に server_name が含まれている場合、これを使って適切な証明書を選択してクライアントに送信したり、 その他セキュリティーに関わる選択を行ったりして構いません。その場合 ServerHello に server_name TLS拡張を含めなければなりません。その際 extension_data は空としなければなりません。 >>18

[13] クライアントの指定したサーバー名とサーバーが選んだサーバー名が一致しない場合、 クライアントが server endpoint identification する際に違いが判明するはずなので、 クライアントはその時通信を続けるかどうかを決めることになります >>18。

[29] SNI の拡張データは、 ServerNameList 型の欄 server_name_list です >>18。 すなわち、16ビット符号無し整数 (ネットワークバイト順) と、 その値が長さである1バイト以上216-1バイト以下のバイト列として表された ServerName のリストです >>18。

width
16
  1. 2 長さ
  2. 14... ServerName の列

[38] IPアドレスその他、ドメイン名以外のホストの指定方法は用意されていません。

サーバー名

[31] ServerName は、名前の種類を表す name_type 欄と、実際の名前を表す name 欄で構成されます >>18。

[14] name_type 欄の値は列挙型 NameType ですが、現在 DNSホスト名 (host_name = 0) のみ対応しています >>18。1バイトで表されます >>18。

[15] name 欄の値は HostName 型です。 HostName 型は、 16ビット符号無し整数 (ネットワークバイト順) と、 その値が長さである1バイト以上216-1バイト以下のバイト列です >>18。

width
16:
  1. 1 0
  2. 2 長さ
  3. 13... 名前

[17] DNSホスト名は、 DNS FQDN を、 末尾の. を付けずに ASCII バイト列として表現したものです >>18。 IPアドレスを指定してはなりません >>18。

[18] IDN はAラベルで表現します >>18。

[19] DNSホスト名の比較は、IDNA2008ラベル等価性によります >>18。

[11] サーバーの名前は複数指定できますが、同じ name_type の名前が複数あってはなりません >>18。

[30] 複数の指定をサーバーがどう解釈するべきかは定かではありません。

[32] Firefox も Chrome も IE も、末尾の点がついたホスト名が URL で指定された時は、 SNI にも末尾の点がついたホスト名を記載するようです。

[42] Firefox も Chrome も、 IPアドレスの URL の時は、 SNI を使いません (使えません)。

応用プロトコルとの関係

[21] アプリケーションプロトコルがサーバー名の折衝を行ってから TLS に切り替えた場合で SNI を使う場合には、アプリケーションプロトコルで折衝したのと同じサーバー名を指定するべきです。 >>18

[22] SNI でサーバー名を確立した場合には、クライアントは TLS 上のアプリケーションプロトコルで別のサーバー名を要求しようと試みるべきではありません。 >>18

[23] アプリケーションプロトコルは、 SNI によるサーバー名とアプリケーションプロトコル内で指定するプロトコルが異なる際にどう処理するか規定する必要があります。

[24] HTTP については実効要求URLを参照。

[27] サーバーの実装は、両者が一致することを前提にしている場合、一致しているか検査しなければなりません >>26。

[36] 再折衝が行われる場合、その ClientHello にも SNI が含められます。普通は最初の SNI と同じ値にします。 異なる値を指定した時にどう扱われるのかは定かではありません。

[37] 例えば HTTP応答の途中で再折衝が発生しクライアントが SNI で異なるホスト名を送信してくるとしたら穏やかではありません。

[41] 次のプロトコルは、 SNI への対応を要求しています。

[40] 更に、明文規定こそありませんが、 HTTP/1 over TLS も SNI への対応が必要です。

歴史

[1] ウェブブラウザのSNI対応 | dodaの日記 | スラッシュドット・ジャパン ( ( 版)) http://slashdot.jp/journal/495893/%E3%82%A6%E3%82%A7%E3%83%96%E3%83%96%E3%83%A9%E3%82%A6%E3%82%B6%E3%81%AESNI%E5%AF%BE%E5%BF%9C

[2] Server Name Indication - Wikipedia ( ( 版)) http://ja.wikipedia.org/wiki/Server_Name_Indication

[3] AndroidにおけるSNI対応状況 - さくらのナレッジ ( ( 版)) http://knowledge.sakura.ad.jp/tech/1706/

[4] Bug 909604 – wget: Missing support for SNI (Server Name Indication) ( ( 版)) https://bugzilla.redhat.com/show_bug.cgi?id=909604

[5] #653267 - wget: Please include SNI patch - Debian Bug report logs ( ( 版)) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653267

[6] GNU Wget - バグ: bug #26786, TLS SNI support [Savannah] ( (Copyright (C) 2000, 2001, 2002, 2003 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved 著, 版)) http://savannah.gnu.org/bugs/?26786

[28] RFC 7525 - Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) ( 版) https://tools.ietf.org/html/rfc7525#section-3.6

TLS implementations MUST support the Server Name Indication (SNI)

extension defined in Section 3 of [RFC6066] for those higher-level

protocols that would benefit from it, including HTTPS. However, the

actual use of SNI in particular circumstances is a matter of local

policy.

[33] RFC 7590 - Use of Transport Layer Security (TLS) in the Extensible Messaging and Presence Protocol (XMPP) ( 版) https://tools.ietf.org/html/rfc7590#section-3.5

Although there is no harm in supporting the TLS Server Name

Indication (SNI) extension [RFC6066], this is not necessary since the

same function is served in XMPP by the 'to' address of the initial

stream header as explained in Section 4.7.2 of [RFC6120].

[39] The CPAN Search Site - search.cpan.org ( 版) http://search.cpan.org/diff?from=AnyEvent-7.11&to=AnyEvent-7.12

[43] 韓国でSNIフィールドを使った特定サイトの接続遮断が始まる | スラド IT () https://it.srad.jp/story/19/02/13/0735240/

[44] 中国政府、TLS 1.3とESNIを使用するすべての暗号化されたHTTPSトラフィックをブロック中 | スラド YRO () https://yro.srad.jp/story/20/08/12/1642231/