Résumé

  • ECH sépare le ClientHelloInner chiffré de l’enveloppe externe et du public_name du serveur tourné vers le client ; cette séparation protège une partie de la négociation, elle ne désigne pas l’origine privée.
  • Une configuration DNS, l’acceptation d’ECH, un certificat et une transaction applicative sont quatre preuves différentes, avec des décideurs et des horloges différents.

La RFC 9849 prévoit un ClientHelloInner contenant les valeurs privées et un ClientHelloOuter qui porte des valeurs inoffensives ainsi que l’extension ECH. L’inner est chiffré avec une clé publique ECH et lié cryptographiquement à l’outer. Cette liaison empêche une certaine manipulation de l’enveloppe. Elle ne démontre ni que l’adresse publique, le nom DNS, le backend et l’opérateur sont une même personne, ni que le service demandé a été livré.

Le public_name ne doit pas être surinterprété. La RFC le définit comme le nom DNS du serveur face au client, celui auquel l’on fait confiance pour mettre à jour la configuration ECH et aider à la récupération d’une configuration périmée. C’est normalement le nom placé dans le SNI externe. Ce nom est une surface publique de routage et de récupération ; ce n’est pas le nom caché du backend, ni un certificat de propriété pour tous les noms privés.

La distinction devient concrète dans les topologies. En mode partagé, le serveur face au client et le backend peuvent être le même acteur. En mode séparé, le premier relaie vers le backend qui termine TLS, sans voir le texte clair de la connexion. Le modèle suppose un canal authentifié entre les deux et l’absence de corrélation exploitable entre les deux segments. La RFC ne spécifie pas le mécanisme exact qui empêche cette corrélation. Observer ECH ne vérifie donc pas ces hypothèses de déploiement.

L’acceptation n’est pas une preuve générale non plus. Le serveur peut accepter ECH et employer l’inner, ou le rejeter et employer l’outer. Après un rejet, la connexion n’est pas utilisable pour les données applicatives par le client ECH et une nouvelle configuration peut être proposée. Une acceptation est un état de négociation : elle ne confirme pas que la chaîne de certificats a été acceptée par la politique locale, que le nom attendu correspond, que l’application a autorisé l’action ou que celle-ci a abouti.

La RFC 8446 conserve cette séparation. TLS négocie des paramètres, peut authentifier des pairs et établit des clés ; il reste indépendant du protocole applicatif. Les ancres de confiance et une part des règles de validation sont distinctes de TLS. La présence d’un certificat, comme la présence d’ECH, ne remplace pas le journal de validation local ni la preuve d’un résultat applicatif.

La RFC 9460 apporte une autre limite utile : les enregistrements SVCB/HTTPS peuvent annoncer des clés et des extrémités alternatives, lesquelles peuvent avoir des capacités ou des opérateurs différents. Le DNS peut expliquer quelle instruction a été reçue ; il ne nomme pas automatiquement le serveur qui a terminé une connexion privée.

Il faut donc conserver un dossier par couches : source et durée de vie de l’ECHConfig, résolveur et cache, acceptation ou rejet, identité attendue, résultat de validation, état du canal vers le backend, extrémité choisie et résultat applicatif. Une trace chiffrée peut éclairer une colonne. Elle ne doit pas remplir les autres par analogie.

Sources