Résumé

  • La RFC 9850 définit une ligne SSLKEYLOGFILE avec trois éléments : le type de secret, le nombre aléatoire du ClientHello et le secret. Associée à une trace réseau et au contexte de connexion, cette ligne peut permettre le déchiffrement ; seule, elle ne date rien et n’identifie ni machine, ni personne, ni autorisation.
  • Le risque dépasse la lecture passive. Les secrets peuvent exposer du trafic ancien, permettre l’injection dans une connexion active, compromettre des usages applicatifs des exporters, annuler la confidentialité persistante et révéler le ClientHello interne d’ECH.
  • La spécification réserve le mécanisme aux systèmes où TLS ne protège que des données de test et interdit son usage en production. Une reconstruction réussie ne prouve donc ni la légitimité de la collecte, ni la chaîne de conservation, ni l’auteur d’une action observée.

Le déchiffrement répond à un verbe, pas à tout le dossier

Dans une enquête, le mot « preuve » attire vers lui des faits qui n’ont pas la même origine. Une capture contient des paquets. Un journal de clés contient de la matière secrète. Un outil applique une interprétation du protocole. Un analyste relie le résultat à un équipement, puis parfois à une personne. Ces étapes peuvent former une démonstration robuste, mais aucune ne doit absorber les autres.

Si les enregistrements TLS deviennent lisibles, on sait qu’un ensemble de secrets, de paquets et de paramètres a fonctionné ensemble. On ne sait pas encore qui a lancé la journalisation, à quel moment le fichier a été créé, sur quel processus, avec quelle permission, ni comment la capture et le fichier ont circulé jusqu’à l’analyste. La capacité de rendre les octets lisibles n’ajoute pas ces métadonnées par magie.

Cette distinction protège aussi l’enquêteur. Une conclusion étroite peut être reproduite. Une conclusion qui transforme un fichier technique en témoin universel devient fragile dès que la défense demande l’horloge, l’interface de capture, le hash, les droits d’accès ou l’identité de l’actif.

Une pratique existante devenue format commun

La RFC 9850, publiée en juillet 2026 dans la catégorie Informational, est signée par Martin Thomson, Yaroslav Rosomakho et Hannes Tschofenig. Elle ne raconte pas l’invention solitaire d’un mécanisme. Ses remerciements précisent que le format est né dans le projet Network Security Services, qu’il a évolué avec TLS et que les auteurs documentent la pratique tout en l’étendant à Encrypted Client Hello.

Le profil IETF Datatracker conservé le 1er septembre décrit Thomson comme ingénieur chez Mozilla, recense 45 RFC sous son identité publique et indique plusieurs fonctions actuelles au sein de l’IETF et de la liaison avec le W3C. Ces éléments situent une contribution durable aux protocoles. Ils ne lui donnent aucune autorité sur la compilation d’un navigateur, le lancement d’un processus, la collecte d’une entreprise ou l’interprétation judiciaire d’un fichier.

IANA tient désormais le registre des libellés SSLKEYLOGFILE. Cette coordination évite que producteurs et outils donnent des sens incompatibles aux mêmes mots. La RFC rappelle pourtant que l’approbation d’un libellé par les experts désignés n’est pas son approbation au sens opérationnel. Enregistrer une syntaxe n’est pas autoriser son usage.

Les trois champs disent aussi ce qu’ils ne disent pas

Une ligne utile contient un label, un client_random et un secret. Le premier indique la nature du secret. Le deuxième reprend les 32 octets Random du ClientHello afin de retrouver une connexion parmi plusieurs. Le troisième transporte la valeur secrète en hexadécimal.

La conclusion suivante est une déduction structurelle tirée de cette définition, et non une phrase attribuée à la RFC : aucun champ obligatoire ne porte l’heure, le nom d’hôte, l’adresse et le port, la chaîne de certificats, le processus, l’utilisateur, la décision d’autorisation, l’origine du fichier, la référence de la capture ou la chaîne de conservation. Le nombre aléatoire du ClientHello corrèle des données ; il ne certifie pas une identité.

La RFC nomme elle-même une autre dépendance. Le secret n’est pas annoté avec la suite cryptographique ni avec les autres paramètres de connexion ; un enregistrement du handshake peut être nécessaire. Le journal n’est donc pas un transcript autonome. Il devient opérant lorsqu’un autre jeu de données lui fournit la scène cryptographique.

Cette sobriété explique l’interopérabilité du format. Elle explique aussi pourquoi une ligne syntaxiquement correcte peut être copiée ou construite hors de la capture qu’on lui attribue. La fiabilité vient du procédé de collecte, des hashes, des horloges et de la corroboration, non de la seule grammaire.

La puissance réelle impose une lecture encore plus rigoureuse

Refuser au fichier le statut de certificat ne revient pas à le banaliser. La section de sécurité de la RFC 9850 affirme que l’accès aux secrets concernés peut briser la confidentialité et l’intégrité des connexions actives et des enregistrements chiffrés conservés auparavant.

Les clés dérivées sont symétriques. Dans les conditions appropriées, celui qui peut retirer la protection des records peut aussi produire des données acceptables pour une connexion active. L’observation se transforme alors en possibilité d’injection ou de modification. Il faut donc distinguer dans le dossier les records capturés avant l’analyse et toute donnée créée pendant un test actif.

Les secrets d’exporter agrandissent encore le périmètre. Certaines applications les utilisent pour lier une session, authentifier un contexte ou dériver d’autres secrets. Leur fuite ne révèle pas seulement un contenu : elle peut atteindre une propriété de sécurité applicative que la capture ne rend pas évidente.

La confidentialité persistante cesse également de protéger les sessions dont la matière secrète a été enregistrée. Une compromission future de la clé longue durée n’était plus censée rouvrir tout le passé ; le journal fait précisément entrer les secrets de trafic dans l’archive. La capture stockée et le fichier deviennent les deux moitiés d’une divulgation différée.

Tous les libellés n’accordent pas le même pouvoir. Pour TLS 1.2, CLIENT_RANDOM transporte le master secret : la RFC cite lecture, altération, reprise de session, usurpation des deux extrémités, insertion d’une renégociation et fabrication de Finished. Pour ECH, ECH_SECRET peut révéler le ClientHello interne et le SNI qu’il protège. Compter les fichiers sans inventorier les types de secrets empêche d’évaluer l’incident.

« MUST NOT » doit être appliqué avant le démarrage

La RFC 9850 ne recommande pas un compromis ordinaire entre observabilité et confidentialité. Elle vise les systèmes où TLS ne protège que des données de test et dit que le mécanisme ne doit pas être utilisé en production. Pour un logiciel compilé, elle recommande la compilation conditionnelle afin qu’un binaire déployé ne puisse même pas être configuré pour journaliser.

Cette architecture est plus forte qu’une permission de fichier. Si la capacité n’existe pas dans le binaire de production, une variable d’environnement, un script d’urgence ou un processus compromis ne peut pas l’activer. Dans un laboratoire, les droits d’accès, la durée de vie et la destruction restent indispensables. En production, ils ne remplacent pas l’absence de la fonction.

Le danger apparaît quand un diagnostic « temporaire » devient un répertoire permanent, puis une collecte centrale, puis une habitude d’assistance. Le fichier survit à l’expérience, entre dans une sauvegarde et rencontre des captures conservées pour une autre raison. La question décisive n’est plus seulement « qui le lit ? », mais « pourquoi le système en service pouvait-il le créer ? ».

La découverte d’une telle capacité en production appelle donc un confinement : identifier le binaire et son contexte de lancement, empêcher de nouveaux secrets, protéger les fichiers et captures existants, délimiter les connexions et les secrets d’exporter concernés, puis conserver les éléments nécessaires sans recopier les secrets dans les tickets.

Un succès analytique ne distribue pas les identités

Le handshake de TLS 1.3, décrit par la RFC 9846, négocie des paramètres, authentifie les pairs selon le mécanisme choisi — l’authentification du client est facultative — et établit de la matière secrète partagée. Les protocoles applicatifs doivent encore préciser comment interpréter certificats et identités.

Le journal exporte certains produits de ce calcul. Il ne rejoue pas la validation du certificat, ne dit pas quel nom l’application attendait, ne garantit pas que le client était authentifié et n’associe aucune personne à une extrémité. Même une capture complète doit conserver séparément l’identité de référence, le résultat de validation et la politique applicative.

Un échec de déchiffrement doit rester étroit lui aussi. La mauvaise connexion, un handshake absent, une mise à jour de clé, un sens inversé, le choix du ClientHello interne ou externe, ou le contexte d’un protocole intégré peuvent suffire. « Non déchiffré » ne signifie pas « fabriqué ».

La RFC 9325 rappelle que l’authentification, la confidentialité et l’intégrité sont des objectifs distincts. Un artefact qui neutralise les deux derniers ne gagne pas automatiquement le premier comme pouvoir documentaire.

Le document n’est ni permission ni souverain

Dans The Policy Mirror, Heng Lu écrit qu’un registre peut décrire la réalité sans la créer. Running-Code Primacy demande de limiter l’autorité d’un artefact partagé à sa fonction déterministe. On Reality Layers sépare l’effet exécutable de la revendication symbolique.

Appliqué ici, l’effet exécutable est incontestable : les bons secrets avec les bons records peuvent révéler ou altérer le trafic. La revendication symbolique abusive consiste à faire du petit fichier la preuve de la session, de ses acteurs et de la légitimité de la collecte.

La contribution de Thomson, Rosomakho et Tschofenig se lit dans cette retenue. Ils normalisent les octets nécessaires à l’interopérabilité et placent au premier plan l’interdiction de production. La publication d’une RFC et l’existence d’un registre IANA ne transforment pas une pratique dangereuse en pratique autorisée.

La responsabilité reste distribuée. Les auteurs répondent du texte. Les implémenteurs choisissent les fonctions. Les responsables de release choisissent le binaire. Les opérateurs contrôlent le lancement. Les enquêteurs construisent la provenance et interprètent le résultat. Le format ne peut hériter de leurs décisions.

Le dossier probatoire doit entourer le fichier

Avant le premier déchiffrement, il faut documenter le build, le mécanisme d’activation, l’auteur et l’autorisation de la demande, le processus, l’actif, l’intervalle de collecte, les permissions, les hashes, le lieu de stockage et chaque transfert de garde.

La capture exige son propre registre : interface, direction, filtre, source horaire, pertes, complétude du handshake, tuple de transport et hash. L’analyse doit ensuite relier explicitement le label et le ClientHello random, les paramètres retrouvés, l’outil et sa version, les records authentifiés, les échecs et toute action active.

La conclusion peut alors rester utile sans devenir souveraine. Des clés d’endpoint ne sont pas l’identité d’un utilisateur. Des octets déchiffrés ne prouvent pas leur affichage. Une requête capturée ne prouve pas l’issue commerciale. Un test autorisé n’est pas une interception autorisée partout.

Le journal de clés conserve sa valeur lorsque ces limites sont visibles. Il cesse seulement de se faire passer pour une histoire complète.

Sources