[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。
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。
ServerName の列[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。
0[17] DNSホスト名は、 DNS FQDN を、
末尾の. を付けずに
ASCII バイト列として表現したものです >>18。
IPアドレスを指定してはなりません >>18。
[19] DNSホスト名の比較は、IDNA2008ラベル等価性によります >>18。
[11] サーバーの名前は複数指定できますが、同じ name_type
の名前が複数あってはなりません >>18。
[32] Firefox も Chrome も IE も、末尾の点がついたホスト名が URL で指定された時は、 SNI にも末尾の点がついたホスト名を記載するようです。
[42] Firefox も Chrome も、 IPアドレスの URL の時は、 SNI を使いません (使えません)。
[21] アプリケーションプロトコルがサーバー名の折衝を行ってから TLS に切り替えた場合で SNI を使う場合には、アプリケーションプロトコルで折衝したのと同じサーバー名を指定するべきです。 >>18
[22] SNI でサーバー名を確立した場合には、クライアントは TLS 上のアプリケーションプロトコルで別のサーバー名を要求しようと試みるべきではありません。 >>18
[23] アプリケーションプロトコルは、 SNI によるサーバー名とアプリケーションプロトコル内で指定するプロトコルが異なる際にどう処理するか規定する必要があります。
[27] サーバーの実装は、両者が一致することを前提にしている場合、一致しているか検査しなければなりません >>26。
[36] 再折衝が行われる場合、その ClientHello
にも SNI が含められます。普通は最初の 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
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.
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/
Host:の値を使い、 SNI で指定された値は無視しているようです。)