3. Server-Namensanzeige

[RFC5246] bietet keinen Mechanismus für einen Client, um einem Server den Namen des Servers mitzuteilen, den er kontaktiert. Es kann für Clients wünschenswert sein, diese Informationen bereitzustellen, um sichere Verbindungen zu Servern zu erleichtern, die mehrere 'virtuelle' Server unter einer einzigen zugrunde liegenden Netzwerkadresse hosten.

Um den Servernamen bereitzustellen, KÖNNEN Clients eine Erweiterung vom Typ "server_name" in das (erweiterte) Client-Hello aufnehmen. Das Feld "extension_data" dieser Erweiterung MUSS "ServerNameList" enthalten, wobei:

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;

Die ServerNameList DARF NICHT mehr als einen Namen desselben name_type enthalten. Wenn der Server die ClientHello-Erweiterung verstanden hat, aber den Servernamen nicht erkennt, SOLLTE der Server eine von zwei Aktionen durchführen: entweder den Handshake durch Senden einer fatalen Warnung unrecognized_name(112) abbrechen oder den Handshake fortsetzen. Es wird NICHT EMPFOHLEN, eine Warnung auf Warnstufe unrecognized_name(112) zu senden, da das Verhalten des Clients als Reaktion auf Warnungen auf Warnstufe unvorhersehbar ist. Wenn eine Nichtübereinstimmung zwischen dem von der Clientanwendung verwendeten Servernamen und dem Servernamen der vom Server gewählten Credential besteht, wird diese Nichtübereinstimmung offensichtlich, wenn die Clientanwendung die Server-Endpunkt-Identifikation durchführt, an welchem Punkt die Clientanwendung entscheiden muss, ob sie die Kommunikation fortsetzen soll oder nicht. TLS-Implementierungen werden ermutigt, Anwendungsaufrufern Informationen über Warnungen auf Warnstufe zur Verfügung zu stellen, die während eines TLS-Handshakes empfangen oder gesendet wurden. Solche Informationen können für Diagnosezwecke nützlich sein.

Derzeit sind die einzigen unterstützten Servernamen DNS-Hostnamen; dies impliziert jedoch keine Abhängigkeit von TLS zu DNS, und andere Namenstypen können in Zukunft hinzugefügt werden (durch einen RFC, der dieses Dokument aktualisiert). TLS KANN bereitgestellte Servernamen als opake Daten behandeln und die Namen und Typen an die Anwendung weitergeben.

"HostName" enthält den vollqualifizierten DNS-Hostnamen des Servers, wie vom Client verstanden. Der Hostname wird als Byte-String mit ASCII-Kodierung ohne abschließenden Punkt dargestellt. Dies ermöglicht die Unterstützung von internationalisierten Domainnamen durch die Verwendung von A-Labels, die in [RFC5890] definiert sind. DNS-Hostnamen unterscheiden nicht zwischen Groß- und Kleinschreibung. Der Algorithmus zum Vergleichen von Hostnamen wird in [RFC5890], Abschnitt 2.3.2.4, beschrieben.

Literale IPv4- und IPv6-Adressen sind in "HostName" nicht zulässig.

Es wird EMPFOHLEN, dass Clients eine Erweiterung vom Typ "server_name" in das Client-Hello aufnehmen, wann immer sie einen Server über einen unterstützten Namenstyp lokalisieren.

Ein Server, der ein Client-Hello mit der "server_name"-Erweiterung erhält, KANN die in der Erweiterung enthaltenen Informationen verwenden, um seine Auswahl eines geeigneten Zertifikats zu leiten, das an den Client zurückgegeben werden soll, und/oder andere Aspekte der Sicherheitsrichtlinie. In diesem Fall MUSS der Server eine Erweiterung vom Typ "server_name" in das (erweiterte) Server-Hello aufnehmen. Das Feld "extension_data" dieser Erweiterung MUSS leer sein.

Wenn ein Server eine ServerNameList erhält, die einen name_type oder ServerName enthält, den er nicht unterstützt, MUSS er den Handshake mit einer fatalen Warnung unsupported_extension abbrechen.

Wenn eine Anwendung einen Servernamen unter Verwendung eines Anwendungsprotokolls aushandelt und dann auf TLS aktualisiert, und wenn eine server_name-Erweiterung gesendet wird, SOLLTE die Erweiterung denselben Namen enthalten, der im Anwendungsprotokoll ausgehandelt wurde. Wenn der server_name im TLS-Sitzungs-Handshake festgelegt wird, SOLLTE der Client überprüfen, dass der server_name mit der vom Anwendungsschichtprotokoll ausgehandelten Serveridentität übereinstimmt, falls zutreffend.

Wenn die Servername-Erweiterung in einer wiederaufgenommenen Sitzung verwendet wird, SOLLTE der Server sie NICHT verwenden, um zu entscheiden, ob die Wiederaufnahme akzeptiert werden soll, es sei denn, er behält die Bindung bei. Der Server SOLLTE diese Erweiterung in einer wiederaufgenommenen Sitzung ignorieren und die Wiederaufnahme unter Verwendung des mit der ursprünglichen Sitzung verbundenen Servernamens fortsetzen. Um sicherstellen zu können, dass der im Client-Hello präsentierte Servername mit dem ursprünglich präsentierten Namen übereinstimmt, wird EMPFOHLEN, dass Implementierungen Informationen über den Servernamen durch eine Sitzungswiederaufnahme beibehalten.