Résumé

  • SNI transporte le nom DNS visé dans le ClientHello. Un frontal partagé peut donc choisir certificat et contexte TLS avant l’arrivée de la requête HTTP chiffrée.
  • Cette indication organise la sélection, elle n’établit ni identité ni autorisation. Parce qu’elle précède le chiffrement, elle est observable; ECH distingue aujourd’hui un nom extérieur public d’un nom intérieur protégé.

Le guichet devait choisir avant d’ouvrir la lettre

Un seul guichet dessert plusieurs sociétés. Une lettre fermée arrive, mais le guichetier doit choisir, avant de l’ouvrir, le cachet officiel qui prouvera quelle société répond. L’adresse de la société se trouve dans la lettre. Voilà, sous une forme matérielle, le paradoxe qu’a rencontré HTTPS.

Dans TLS 1.0, décrit par la RFC 2246, l’authentification et les secrets de session sont établis avant les données applicatives protégées. Or le champ HTTP qui distingue les hôtes virtuels n’est lisible qu’après cette étape. À une même adresse réseau, le serveur ne disposait donc pas du renseignement nécessaire au moment de sélectionner son certificat.

La RFC 3546, publiée en 2003, a placé ce renseignement plus tôt. Avec Server Name Indication, le client annonce dans son ClientHello le nom du serveur qu’il cherche. Le frontal peut alors choisir le certificat, les paramètres et le service correspondant.

La solution tient autant à la chronologie qu’au champ lui-même. Le nom devait arriver assez tôt pour être utile; à cet instant, les clés qui auraient pu le dissimuler n’existaient pas encore.

Délier l’adresse de l’identité de service

L’hébergement HTTP par nom permettait déjà à plusieurs sites de partager une adresse. Le frontal lisait l’autorité demandée et distribuait la requête. TLS inversait l’ordre: il fallait d’abord créer un canal authentifié, donc choisir une identité de serveur, avant de lire cette autorité.

Sans SNI, l’exploitant pouvait réserver une adresse à chaque identité, regrouper de nombreux noms dans un même certificat ou servir un certificat par défaut. Ces solutions transformaient une contrainte de séquence en coût d’adressage, en complexité de certificats ou en erreur pour l’utilisateur.

SNI a ajouté un critère de sélection à l’adresse, sans remplacer celle-ci. Le routage mène toujours la connexion jusqu’au frontal. Le nom du ClientHello précise ensuite quel contexte doit recevoir la connexion. Cette séparation a rendu praticable l’HTTPS mutualisé pour les hébergeurs, les CDN, les mandataires inverses et les plateformes infonuagiques.

Une indication n’est pas une preuve

La RFC 6066 définit server_name et son type host_name pour les noms DNS. Un serveur qui ne reconnaît pas le nom peut interrompre la négociation avec unrecognized_name ou continuer selon sa politique.

Ce choix suffit à montrer que SNI ne constitue pas une autorité. Le client ne prouve rien en écrivant un nom. Le serveur ne prouve rien simplement en sélectionnant une configuration. Le client doit encore valider le certificat; l’application doit encore contrôler l’autorisation; le nom de la requête HTTP doit rester cohérent avec le contexte sécurisé.

SNI ressemble à l’inscription extérieure qui dirige un dossier vers le bon service. La signature et les droits se vérifient ailleurs. Le confondre avec ces contrôles favorise les certificats par défaut trop larges, les passages entre locataires et les hypothèses fragiles sur la provenance de la connexion.

Le prix de la visibilité précoce

Avant que le ServerHello permette de dériver les clés, le premier ClientHello circule sans cette protection. Le serveur ne peut pas déchiffrer un nom pour choisir la configuration nécessaire à son déchiffrement. La visibilité n’était donc pas une faute de réglage; elle était la contrepartie de la position choisie.

Un observateur situé sur le chemin pouvait ainsi ignorer le contenu HTTP tout en apprenant le site demandé. La RFC 8744 décrit cette fuite de confidentialité et les usages opérationnels du SNI en clair: mesure, politique réseau, filtrage et diagnostic.

TLS 1.3, dans la RFC 8446, protège davantage la négociation après le ServerHello. Il ne peut toutefois pas cacher rétroactivement le ClientHello initial avec des clés qui seront établies plus tard. Le nom restait donc sur le côté public de la frontière.

Une dépendance née autour d’un détail observable

La présence stable d’un nom a produit un écosystème. Les plateformes s’en servent pour orienter les flux; des outils de sécurité le classent; des réseaux le journalisent ou le bloquent. Ces fonctions peuvent répondre à de vrais besoins, mais elles transforment une fuite en dépendance.

Dès lors, chiffrer le nom menace non seulement des techniques anciennes, mais aussi des intérêts constitués. Le frontal doit encore disposer d’une information publique minimale pour atteindre le composant capable de déchiffrer la suite. Dans le même temps, les intermédiaires perdent une information qu’ils considéraient parfois comme leur interface de contrôle.

L’histoire de SNI illustre une forme de verrouillage: un champ créé pour résoudre une contrainte de protocole devient une ressource pour d’autres acteurs, qui rendent son retrait plus coûteux.

ECH redessine la frontière au lieu d’effacer toute trace

La RFC 9849 spécifie Encrypted ClientHello. Le client construit un ClientHello intérieur contenant les éléments sensibles, puis le chiffre dans un ClientHello extérieur. Le nom extérieur public dirige la connexion vers le service capable de traiter ECH; le nom réel de l’origine reste dans la partie intérieure.

L’adresse IP et le nom public ne disparaissent pas. ECH ne promet donc pas un trafic sans métadonnées. Il évite plutôt que le nom précis de l’origine soit nécessairement divulgué à tout le trajet lorsqu’un nom commun suffit pour atteindre la frontière de confidentialité du fournisseur.

Acceptation, rejet et nouvelle configuration sont explicitement traités. Le client ne doit pas supposer que l’extérieur public est devenu son origine si le déchiffrement échoue. Il obtient une confirmation protégée de l’usage d’ECH ou des paramètres permettant une nouvelle tentative.

L’innovation prolonge ainsi la leçon de SNI: publier uniquement ce qui est indispensable au prochain choix, puis déplacer le détail derrière une frontière où il peut être protégé.

Une infrastructure partagée, une dette de frontière

SNI a rendu compatibles l’économie de l’hébergement partagé et l’ordre d’authentification de TLS. Il a réduit le lien rigide entre adresse, certificat et site, contribuant à faire du HTTPS mutualisé une pratique ordinaire.

Il n’a jamais certifié le nom, accordé un droit applicatif ni caché la destination. Sa réussite et sa faiblesse viennent de la même décision temporelle. ECH ne nie pas ce passé; il cherche une division plus parcimonieuse entre la route publique et la destination privée.

Dans un protocole, l’instant où une donnée devient nécessaire définit aussi les personnes qui peuvent l’observer. La question durable n’est donc pas seulement « ce champ est-il chiffré ? », mais « quel acteur doit connaître quel nom, avant quelle décision ? ».

Sources et limites des éléments probants

Le dossier normatif réunit les RFC 2246, RFC 3546, RFC 6066, RFC 8446, RFC 8744 et RFC 9849. L’analyse des coûts d’hébergement, des incitations de surveillance et du verrouillage opérationnel découle de l’ordre des messages spécifié; elle ne mesure aucun fournisseur ni réseau particulier.