メインコンテンツまでスキップ

3. サーバー名表示

[RFC5246]は、クライアントが接続しているサーバーの名前をサーバーに示すメカニズムを提供していません。クライアントがこの情報を提供して、単一の基礎となるネットワークアドレスで複数の「仮想」サーバーをホストするサーバーへの安全な接続を容易にすることが望ましい場合があります。

サーバー名を提供するために、クライアントは（拡張された）Client Helloに"server_name"タイプの拡張を含めることができます（MAY）。この拡張の"extension_data"フィールドには"ServerNameList"が含まれていなければなりません（MUST）。ここで：

struct {
    NameType name_type;
    select (name_type) {
        case host_name: HostName;
    } name;
} ServerName;

enum {
    host_name(0), (255)
} NameType;

opaque HostName<1..2^16-1>;

struct {
    ServerName server_name_list<1..2^16-1>
} ServerNameList;

ServerNameListには、同じname_typeの名前が複数含まれてはなりません（MUST NOT）。サーバーがClientHello拡張を理解したがサーバー名を認識しない場合、サーバーは次の2つのアクションのいずれかを取るべきです（SHOULD）：致命的なunrecognized_name(112)アラートを送信してハンドシェイクを中止するか、ハンドシェイクを続行します。警告レベルのunrecognized_name(112)アラートを送信することは推奨されません（NOT RECOMMENDED）。警告レベルのアラートに対するクライアントの動作は予測不可能であるためです。クライアントアプリケーションが使用するサーバー名と、サーバーが選択したcredentialのサーバー名との間に不一致がある場合、この不一致は、クライアントアプリケーションがサーバーエンドポイント識別を実行するときに明らかになり、その時点でクライアントアプリケーションは通信を続けるかどうかを決定する必要があります。TLS実装は、TLSハンドシェイク中に受信または送信された警告レベルのアラートに関する情報をアプリケーション呼び出し元が利用できるようにすることが推奨されます。このような情報は、診断目的に役立つ可能性があります。

現在、サポートされているサーバー名はDNSホスト名のみです。ただし、これはTLSがDNSに依存することを意味するものではなく、他の名前タイプが将来追加される可能性があります（本文書を更新するRFCによって）。TLSは、提供されたサーバー名を不透明なデータとして扱い、名前とタイプをアプリケーションに渡すことができます（MAY）。

"HostName"には、クライアントが理解しているサーバーの完全修飾DNSホスト名が含まれています。ホスト名は、末尾のドットなしでASCIIエンコーディングを使用するバイト文字列として表されます。これにより、[RFC5890]で定義されているA-labelを使用することで、国際化ドメイン名のサポートが可能になります。DNSホスト名は大文字小文字を区別しません。ホスト名を比較するためのアルゴリズムは、[RFC5890]のセクション2.3.2.4で説明されています。

リテラルIPv4およびIPv6アドレスは"HostName"で許可されていません。

クライアントは、サポートされている名前タイプでサーバーを見つけるたびに、Client Helloに"server_name"タイプの拡張を含めることが推奨されます（RECOMMENDED）。

"server_name"拡張を含むClient Helloを受信するサーバーは、拡張に含まれる情報を使用して、クライアントに返す適切な証明書の選択、および/またはセキュリティポリシーの他の側面を導くことができます（MAY）。この場合、サーバーは（拡張された）Server Helloに"server_name"タイプの拡張を含めなければなりません（MUST）。この拡張の"extension_data"フィールドは空でなければなりません（MUST）。

サーバーが、サポートしていないname_typeまたはServerNameを含むServerNameListを受信した場合、サーバーは致命的なunsupported_extensionアラートでハンドシェイクを中止しなければなりません（MUST）。

アプリケーションがアプリケーションプロトコルを使用してサーバー名をネゴシエートしてからTLSにアップグレードし、server_name拡張が送信される場合、拡張にはアプリケーションプロトコルでネゴシエートされたのと同じ名前が含まれているべきです（SHOULD）。server_nameがTLSセッションハンドシェイクで確立される場合、クライアントは、該当する場合、server_nameがアプリケーション層プロトコルによってネゴシエートされたサーバーアイデンティティと一致することを確認すべきです（SHOULD）。

サーバー名拡張が再開されたセッションで使用される場合、サーバーはバインディングを維持しない限り、再開を受け入れるかどうかを決定するためにそれを使用すべきではありません（SHOULD NOT）。サーバーは、再開されたセッションでこの拡張を無視し、元のセッションに関連付けられたサーバー名を使用して再開を続けるべきです（SHOULD）。Client Helloで提示されたサーバー名が元々提示された名前と一致することを確認できるようにするために、実装がセッション再開を通じてサーバー名に関する情報を維持することが推奨されます（RECOMMENDED）。

に最終更新