Pourquoi les demandes HTTPS incluent-elles le nom d'hôte en texte clair?
J'ai un peu de mal à comprendre pourquoi le protocole HTTPS inclut le nom d'hôte en texte brut. J'ai lu que le nom d'hôte et les adresses IP d'un paquet HTTPS ne sont pas cryptés.
Pourquoi le nom d'hôte ne peut pas être crypté? Ne pouvons-nous pas simplement laisser l'adresse IP de destination en texte brut (afin que le paquet soit routable), puis lorsque le paquet arrive sur le serveur de destination, le paquet est déchiffré et l'hôte/index identifié à partir de l'en-tête?
Le problème est peut-être qu'il peut y avoir différents certificats pour une adresse IP de destination particulière (différents certificats pour différents sous-domaines?), De sorte que le serveur de destination ne peut pas déchiffrer le paquet jusqu'à ce qu'il arrive à l'hôte correct au sein de ce serveur. Est-ce que cela a un sens, ou suis-je loin?
Le nom d'hôte est inclus dans la négociation SSL initiale pour prendre en charge les serveurs qui ont plusieurs noms d'hôte (avec différents certificats) sur la même adresse IP (SNI: Server Name Indication). Ceci est similaire à l'hôte-en-tête dans les requêtes HTTP simples. Le nom est inclus dans le premier message du client (ClientHello), c'est-à-dire avant toute identification et échange de clé, afin que le serveur puisse offrir le bon certificat d'identification.
Bien que le cryptage du nom d'hôte soit agréable, la question serait de savoir quelle clé utiliser pour le cryptage. L'échange de clés ne survient qu'après identification du site par certificat, car sinon vous pourriez échanger des clés avec un homme du milieu. Mais l'identification avec les certificats nécessite déjà le nom d'hôte pour que le serveur puisse offrir le certificat correspondant. Ainsi, le cryptage du nom d'hôte devrait être effectué avec une clé basée sur un autre type d'identification ou d'une manière non sûre contre l'homme du milieu.
Il pourrait y avoir des moyens de protéger le nom d'hôte dans la négociation SSL, mais au prix d'un surcoût supplémentaire dans la négociation et l'infrastructure. Des discussions sont en cours pour savoir si et comment inclure SNI chiffré dans TLS 1.3. Je vous suggère de consulter cette présentation et la liste de diffusion IETF TLS .
En dehors de cela, une fuite du nom d'hôte peut également se produire par d'autres moyens, comme la recherche DNS précédente pour le nom. Et bien sûr, le certificat envoyé dans la réponse du serveur n'est pas trop chiffré (même problème, pas de clé pour le moment) et donc on peut extraire la cible demandée de la réponse du serveur.
Il existe de nombreux sites qui ne fonctionneront pas sans SNI, comme toutes les offres SSL gratuites de Cloudflares. Si un client ne prend pas en charge SNI (comme IE8 sur Windows XP), cela entraînera soit le mauvais certificat servi, soit une erreur de négociation SSL comme 'unknown_name'.
SNI est là pour l'hébergement virtuel (plusieurs serveurs, avec des noms distincts, sur la même adresse IP). Lorsqu'un client SSL se connecte à un serveur SSL, il veut savoir s'il parle au bon serveur. Pour ce faire, il recherche le nom du serveur prévu dans le certificat. Chaque pirate malveillant peut acheter un certificat pour son propre serveur (appelé evilhacker.com), mais il ne pourra pas l'utiliser pour un faux serveur se faisant passer pour honest-bank-inc.com parce que le navigateur client essaye de se connecter à https://honest-bank-inc.com/, sera assez catégorique pour trouver dans le prétendu certificat de serveur la chaîne honest-bank-inc.com, et certainement pas evilhacker.com.
Jusqu'ici tout va bien. Puis devient la partie technique. Dans "HTTPS", vous avez HTTP encapsulé dans SSL. Cela signifie que le tunnel SSL est d'abord établi (la procédure de "prise de contact") puis, seulement alors, le client envoie la requête HTTP dans ce tunnel. Pendant la prise de contact, le serveur doit envoyer son certificat au client. Mais, à ce stade , le client n'a pas encore dit au serveur à qui il essaie de parler. Le serveur peut supposer que, depuis qu'il a reçu la connexion, le nom que le client souhaite atteindre est probablement l'un des noms de site hébergés par le serveur. Mais c'est une conjecture et échoue si le serveur héberge plusieurs sites avec des noms distincts.
Il existe principalement trois façons de sortir de cette énigme:
Une adresse IP par site. Étant donné que le serveur connaît l'adresse IP cible dès le début de la connexion, le serveur peut utiliser cette adresse IP pour savoir quel serveur est la véritable cible. Bien sûr, la pénurie relative d'adresse IP rend cette solution traditionnelle moins attrayante de nos jours.
Plusieurs noms dans le certificat du serveur. C'est parfaitement valable. Google a lui-même tendance à mettre plus de 70 noms dans son certificat. Une variante est des "noms génériques" qui contiennent "*", correspondant à de nombreux noms. Cependant, cela ne fonctionne que tant que tous les noms sont connus lorsque le certificat est émis. Pour un service d'hébergement de site Web, cela signifierait acheter un nouveau certificat chaque fois qu'un client s'inscrit.
SNI. Avec SNI, le client envoie le nom voulu au début de la négociation, avant que le serveur n'envoie son certificat. Il s'agit de la solution moderne, et maintenant que Windows XP est allé au-delà du bord, il peut enfin être largement utilisé (IE sur Windows XP était le dernier navigateur) qui ne prend pas en charge SNI).
Le fait que vous communiquez avec un serveur ne peut évidemment pas être caché à IP. Les paquets doivent quitter votre machine, entrer dans le réseau, être acheminés vers la destination et être livrés. Ce n'est pas un secret que vous contactez un serveur qui fournit des pages de https://www.fred.com .
Cependant, l'URL ne contient pas l'IP. Au lieu de cela, il contient plusieurs informations. Non seulement il contient le nom d'hôte (qui doit être résolu en une adresse IP), mais il contient des détails sur la demande spécifique: acheminez-le vers un serveur à cette adresse nommée www, recherche, courrier, etc., et le long de ce chemin de répertoire Nom.
Les services d'hébergement ont exploité cette indirection pour prendre en charge plusieurs sites sur un même serveur Web via l'indication de nom de serveur. Ainsi, à la fois https://www.fred.com et https://www.barney.com peuvent être hébergés sur un serveur à 127.0.0.1, et ce n'est que le nom qui distingue la façon dont le serveur acheminera ce message en interne. Il est possible que pour des raisons de sécurité, il doive être acheminé vers un serveur séparé, où les clés réelles seront stockées. Les clés pour déchiffrer ce message peuvent ne pas exister sur ce serveur frontal, il ne peut donc pas être déchiffré avant d'arriver sur la machine hébergeant le site fred.
Outre la nécessité d'inclure le nom d'hôte pour résoudre le certificat, il existe une pratique courante liée à l'utilisation de SNI, qui est importante à connaître: elle permet la mise en œuvre https://en.wikipedia.org/wiki/Virtual_hosting sur SSL/TLS.
SNI est utilisé par tous les serveurs Web populaires: