Résumé

  • RFC 9850 décrit le format à trois champs label client_random secret, uniquement pour des systèmes où TLS ne protège que des données de test, et interdit son usage en production.
  • Les labels ne donnent pas le même pouvoir : le secret maître TLS 1.2 a une portée plus large que des secrets de trafic TLS 1.3, tandis que les exporters et ECH touchent aussi l’authentification applicative et la confidentialité du nom demandé.
  • Une ligne correcte prouve une syntaxe. L’autorisation, le périmètre, les consommateurs, l’association avec la capture, la conservation, la transmission, l’effacement et le retour à un état non journalisé restent des faits séparés.

Le diagnostic crée un paradoxe pratique. Pour comprendre un échange protégé, une équipe demande à un point terminal de rendre la conversation lisible à un autre programme. La cryptographie continue de fonctionner, mais son effet n’est plus réservé aux deux extrémités. RFC 9850 rend ce transfert de visibilité interopérable. Il ne lui donne aucune légitimité automatique.

La limite est écrite sans détour. Publié en juillet 2026 dans la catégorie Informational, le texte n’appartient pas à la voie des normes Internet. Son mécanisme vise les systèmes où TLS ne couvre que des données de test et il ne doit pas être utilisé en production. Pour un logiciel compilé, le document privilégie même la compilation conditionnelle afin qu’un binaire déployé ne puisse pas recevoir cette capacité par simple configuration. La normalisation porte donc sur un format de laboratoire, non sur une pratique générale de production.

Une entrée ordinaire contient trois valeurs séparées par un espace. label nomme le type de matière. client_random reprend les 32 octets du Random du ClientHello, sous la forme de 64 caractères hexadécimaux, pour distinguer les connexions. secret transporte la valeur hexadécimale dont la longueur dépend du label. Les outils doivent accepter plusieurs fins de ligne et les lettres hexadécimales en majuscules ou minuscules. Ils peuvent ignorer une ligne mal formée afin de sauver les secrets encore exploitables d’un fichier endommagé.

Cette tolérance est utile au parseur, mais elle montre ce qu’il ne sait pas faire. Le parseur peut décider qu’une valeur est récupérable. Il ne sait pas si la collecte a été approuvée, si le fichier est complet, si le producteur était le bon processus, si le délai de conservation est expiré ou si le lecteur actuel fait partie du dossier. Aucun des trois champs ne porte le nom du responsable, l’environnement, le ticket, le destinataire ou la date de destruction. Une grammaire valide n’est pas une chaîne d’autorité.

L’identifiant de connexion ne ferme pas non plus l’enquête. RFC 9850 précise que le journal n’indique ni la suite cryptographique ni les autres paramètres ; un enregistrement du handshake peut être nécessaire. La capture de paquets et le fichier de secrets sont donc deux objets à relier. Le premier sans le second peut rester opaque. Le second, sans capture autorisée, peut encore donner prise sur une connexion active. Un répertoire commun n’établit ni origine commune ni périmètre commun.

La diversité des labels empêche de parler d’une unique « clé de débogage ». TLS 1.3 sépare les secrets du trafic précoce, du handshake, du trafic applicatif client et serveur et des exporters. Le sens est directionnel et temporel. Le besoin de lire une phase dans un seul sens ne justifie pas de collecter tous les labels que l’implémentation sait émettre.

Pour TLS 1.2, CLIENT_RANDOM désigne le secret maître. RFC 9850 lui attribue une portée supérieure à celle des secrets TLS 1.3 typiques : lecture et altération des messages, mais aussi reprise de session, usurpation d’une extrémité, insertion de records provoquant une renégociation et falsification de Finished. Le texte indique qu’une implémentation peut éviter ces risques en ne journalisant pas cette valeur. Une politique qui classe tous les secrets dans la même case masque donc l’essentiel.

Les exporters étendent encore le champ. Une application peut en tirer un lien de session, un élément d’authentification ou d’autres secrets de contexte. RFC 9850 envisage de les omettre quand leur abus serait possible, ou d’exiger une autorisation séparée. Le cercle admis pour inspecter des paquets n’est pas nécessairement habilité à recevoir de la matière liée à l’identité applicative.

ECH ouvre une autre surface. ECH_SECRET correspond au secret partagé KEM de HPKE ; ECH_CONFIG décrit la configuration employée. La possession de ECH_SECRET permet de déchiffrer le ClientHello interne et d’en révéler notamment le SNI. Après une négociation ECH réussie, les labels TLS 1.3 ordinaires sont associés au Random interne, alors que les labels ECH utilisent toujours le Random externe. Une indexation générique de la « connexion » peut perdre cette distinction précisément au point où le nom caché est en jeu.

Le pouvoir n’est pas seulement passif. Les clés de records dérivées sont symétriques ; un détenteur peut donc être capable de chiffrer pour une connexion active, avec un risque d’injection ou de modification. Et l’enregistrement annule la propriété de forward secrecy pour les connexions concernées : une acquisition ultérieure du fichier permet de déchiffrer les records conservés. La bonne unité de risque n’est pas « TLS » en général, mais l’ensemble exact des connexions et des classes de secrets exportées.

L’autorisation commence avant la première ligne. Une variable d’environnement telle que SSLKEYLOGFILE place l’activation dans le contexte de lancement. Un fichier spécial peut éviter le stockage durable tout en alimentant un autre programme ; il supprime un support, pas le consommateur. La preuve d’activation doit donc nommer la charge de test, le build ou processus, les labels permis, l’approbateur et l’intervalle de collecte.

La garde se poursuit ensuite : identité et rôle de chaque consommateur, origine et destination de chaque transfert, protection, intégrité, expiration, contrôle d’accès et échéance de conservation. Capture et secrets ont besoin d’un identifiant de dossier commun, sans que le second soit distribué à tous les lecteurs du premier. C’est le moyen de conserver une exception de diagnostic comme exception.

Enfin, l’effacement d’un chemin ne prouve pas la fermeture. Des copies peuvent avoir été créées par un outil d’analyse, un espace temporaire, une pièce jointe ou une sauvegarde. Il ne faut pas supposer qu’elles existent ; il faut recenser les nœuds possibles et enregistrer leur sort. La clôture réunit désactivation, arrêt du producteur, départ des consommateurs, destruction des copies connues, expiration des transferts et fin de la capture.

Les anciennes connexions ne récupèrent pas la forward secrecy déjà perdue. Le constat défendable porte sur la nouvelle frontière : des connexions ultérieures utilisent des secrets frais et non journalisés, la surface de collecte n’émet plus, et l’application fonctionne sans cette exportation. Le registre IANA rend les labels stables et partageables. Cette coordination fine donne un nom au pouvoir ; elle ne prouve ni le droit de l’exercer ni sa disparition.

Sources