Skip to main content

3. Indication du nom du serveur

[RFC5246] ne fournit pas de mécanisme permettant à un client d'indiquer au serveur le nom du serveur qu'il contacte. Il peut être souhaitable pour les clients de fournir ces informations afin de faciliter les connexions sécurisées aux serveurs qui hébergent plusieurs serveurs 'virtuels' à une seule adresse réseau sous-jacente.

Afin de fournir le nom du serveur, les clients PEUVENT inclure une extension de type "server_name" dans le client hello (étendu). Le champ "extension_data" de cette extension DOIT contenir "ServerNameList" où :

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;

La ServerNameList NE DOIT PAS contenir plus d'un nom du même name_type. Si le serveur a compris l'extension ClientHello mais ne reconnaît pas le nom du serveur, le serveur DEVRAIT prendre l'une des deux actions suivantes : soit abandonner la poignée de main en envoyant une alerte fatale unrecognized_name(112), soit continuer la poignée de main. Il N'EST PAS RECOMMANDÉ d'envoyer une alerte de niveau avertissement unrecognized_name(112), car le comportement du client en réponse aux alertes de niveau avertissement est imprévisible. S'il y a une inadéquation entre le nom du serveur utilisé par l'application cliente et le nom du serveur de la credential choisie par le serveur, cette inadéquation deviendra apparente lorsque l'application cliente effectuera l'identification du point de terminaison du serveur, moment auquel l'application cliente devra décider de poursuivre ou non la communication. Les implémentations TLS sont encouragées à rendre disponibles aux appelants d'application des informations sur les alertes de niveau avertissement qui ont été reçues ou envoyées pendant une poignée de main TLS. De telles informations peuvent être utiles à des fins de diagnostic.

Actuellement, les seuls noms de serveur pris en charge sont les noms d'hôte DNS ; cependant, cela n'implique aucune dépendance de TLS vis-à-vis du DNS, et d'autres types de noms peuvent être ajoutés à l'avenir (par un RFC qui met à jour ce document). TLS PEUT traiter les noms de serveur fournis comme des données opaques et transmettre les noms et les types à l'application.

"HostName" contient le nom d'hôte DNS complet du serveur, tel que compris par le client. Le nom d'hôte est représenté comme une chaîne d'octets utilisant l'encodage ASCII sans point final. Cela permet le support des noms de domaine internationalisés grâce à l'utilisation des A-labels définis dans [RFC5890]. Les noms d'hôte DNS ne sont pas sensibles à la casse. L'algorithme pour comparer les noms d'hôte est décrit dans [RFC5890], Section 2.3.2.4.

Les adresses IPv4 et IPv6 littérales ne sont pas autorisées dans "HostName".

Il est RECOMMANDÉ que les clients incluent une extension de type "server_name" dans le client hello chaque fois qu'ils localisent un serveur par un type de nom pris en charge.

Un serveur qui reçoit un client hello contenant l'extension "server_name" PEUT utiliser les informations contenues dans l'extension pour guider sa sélection d'un certificat approprié à renvoyer au client, et/ou d'autres aspects de la politique de sécurité. Dans ce cas, le serveur DOIT inclure une extension de type "server_name" dans le server hello (étendu). Le champ "extension_data" de cette extension DOIT être vide.

Si un serveur reçoit une ServerNameList contenant un name_type ou un ServerName qu'il ne prend pas en charge, il DOIT abandonner la poignée de main avec une alerte fatale unsupported_extension.

Si une application négocie un nom de serveur en utilisant un protocole d'application, puis passe à TLS, et si une extension server_name est envoyée, alors l'extension DEVRAIT contenir le même nom qui a été négocié dans le protocole d'application. Si le server_name est établi dans la poignée de main de session TLS, le client DEVRAIT vérifier que le server_name est cohérent avec l'identité du serveur négociée par le protocole de couche application, le cas échéant.

Lorsque l'extension de nom de serveur est utilisée dans une session reprise, le serveur NE DEVRAIT PAS l'utiliser pour décider d'accepter ou non la reprise, à moins qu'il ne conserve la liaison. Le serveur DEVRAIT ignorer cette extension dans une session reprise et continuer la reprise en utilisant le nom de serveur associé à la session d'origine. Pour pouvoir s'assurer que le nom de serveur présenté dans le client hello correspond au nom présenté à l'origine, il est RECOMMANDÉ que les implémentations conservent des informations sur le nom de serveur à travers une reprise de session.

Last updated on