Résumé

  • Un Exported Authenticator assemble Certificate, CertificateVerify et Finished avec des secrets exportés d’une connexion TLS ou DTLS précise. Il démontre la possession d’une identité X.509 supplémentaire sans modifier l’état TLS.
  • Le message ne porte ni horodatage intrinsèque ni identifiant de flux applicatif. Le contexte de requête protège contre la répétition dans la connexion ; l’opération, le moment d’effet et le privilège doivent être définis ailleurs.
  • Une exploitation défendable sépare la requête, la liaison à la connexion, la validation cryptographique, la politique de certificat, le refus vide authentifié et la décision d’autorisation. Un proxy qui termine TLS constitue une frontière cryptographique, même si le certificat semble identique.

Une preuve correcte, une histoire d’autorisation fausse

La connexion est ouverte à 13 h 58 avec l’identité du handshake ordinaire. Plusieurs centaines de requêtes avancent en parallèle. Cinq minutes plus tard, une demande applicative réclame une identité additionnelle ; la réponse est un Exported Authenticator valide.

L’erreur survient après la validation. Le service transforme preuve valide en toute la connexion appartenait déjà à cette identité. Or RFC 9261 précise que les authentificateurs sont indépendants et unidirectionnels et qu’aucun changement d’état explicite n’intervient dans TLS lors de leur création ou de leur validation.

La preuve peut donc justifier une transition prospective : telle opération future, sur tel flux, reçoit désormais tel niveau. Elle ne peut dater sa propre création, désigner un flux absent de ses octets ni modifier l’auteur d’actions antérieures. Cette limite n’est pas une lacune : TLS fournit le lien cryptographique ; l’application fournit la sémantique.

Ce que les octets établissent vraiment

L’authentificateur reprend trois formes de messages TLS 1.3 sans lancer un nouveau handshake. Certificate présente la chaîne X.509. CertificateVerify prouve la possession de la clé privée. Finished protège la transcription construite avec une clé issue de la connexion déjà établie. L’ensemble est sérialisé sans cadrage de record TLS et peut circuler dans la connexion existante ou dans un canal applicatif offrant une protection équivalente.

Les rôles client et serveur utilisent des libellés d’export distincts. Pour TLS 1.3, la dérivation emploie exporter_master_secret, jamais le secret d’export précoce. Avec TLS 1.2, la suite doit utiliser la PRF et Extended Master Secret doit avoir été négocié. La preuve est ainsi attachée à la connexion initiale plutôt qu’au seul certificat.

Le résultat signifie : sur cette connexion, ce pair a démontré la possession de cette identité acceptable dans cette transcription. Il ne signifie pas que l’identité était active au début, qu’elle vaut sur une autre connexion, qu’elle possède chaque objet multiplexé ni que le certificat accorde un droit métier.

La validation de chaîne reste une fonction séparée. Une signature et un Finished corrects ne sauvent ni un certificat expiré, ni un émetteur refusé, ni une identité hors politique. La journalisation doit conserver séparément le résultat cryptographique, la décision de confiance X.509 et la décision de privilège.

Le contexte de requête n’est pas un mandat universel

Une demande d’authentificateur contient un certificate_request_context de 0 à 255 octets. Cette valeur doit rester unique dans la portée de la connexion pour les deux formes de requête RFC 9261 et devrait être imprévisible pour le pair. La réponse la répète, ce qui relie la preuve à une demande et empêche qu’une preuve déjà admise satisfasse une autre demande locale.

Cette propriété ne transforme pas le contexte en identifiant mondial, horloge ou numéro de transaction. Si une passerelle, un service d’identité et un worker allouent chacun des valeurs sans propriétaire commun au niveau de la connexion, une collision est possible malgré trois bases locales cohérentes.

L’imprévisibilité limite aussi la préparation de preuves par un attaquant qui obtient brièvement une clé privée. Un compteur visible peut être unique mais prévisible ; un générateur aléatoire restauré depuis un snapshot peut répéter un état. Il faut consigner le hachage du contexte, l’époque du générateur, la connexion, les extensions demandées, la cible applicative et l’heure locale, sans exposer aucun secret exporté.

Le client ne peut produire une preuve sans demande préalable. Le serveur peut s’authentifier spontanément. Les métriques doivent garder cette asymétrie : une preuve serveur spontanée ne prouve pas une demande du client, et une preuve client sans demande en attente n’est pas acceptable.

Une connexion multiplexée n’est pas un flux

HTTP/2 regroupe de nombreux flux dans une connexion. RFC 9001 interdit l’authentification client post-handshake de TLS dans QUIC précisément parce que le CertificateRequest TLS ne peut pas être relié de façon fiable à l’événement applicatif qui l’a provoqué.

Les Exported Authenticators déplacent demande et réponse dans la couche applicative. Ils donnent donc à un protocole la possibilité de nommer son événement, mais ne le nomment pas à sa place. Le protocole doit affirmer que le contexte X vise le flux 41 et l’opération Y, puis fixer une barrière après la validation Z.

La politique prudente est étroite et prospective. Aucun paquet déjà traité, aucune requête mise en file avant la validation et aucun flux frère ne reçoit silencieusement la nouvelle identité. Une élévation à l’échelle de la connexion reste possible si le produit la décide explicitement, mais elle exige un ordre, une barrière, un périmètre et un retour arrière vérifiables.

Il faut distinguer l’heure de réception, l’heure de validation et l’heure d’effet. RFC 9261 n’insère pas d’heure de création. Un champ unique authenticated_at détruit les indices nécessaires pour repérer retard, répétition et réordonnancement.

Le terminateur TLS casse la continuité

Le Handshake Context provient de la connexion initiale. Une preuve construite sur la connexion A et vérifiée sur B échoue à CertificateVerify. Un proxy qui termine TLS crée deux contextes, même si les noms et chaînes de certificats se ressemblent.

Accepter le même certificat comme solution de secours supprimerait la propriété essentielle de la preuve. Si l’identité doit franchir ce terminateur, il faut une délégation explicite avec émetteur, audience, durée et chaîne de garde, ou deux authentificateurs indépendants dont le rapprochement est une décision applicative documentée.

Une reconnexion, un failover ou tout remplacement du contexte TLS produit la même discontinuité. Le privilège lié à l’ancienne connexion ne doit pas survivre par simple ressemblance de session. Le système redemande une preuve, revient au niveau inférieur ou emploie un mécanisme de continuité défini séparément.

Un refus peut être authentifié

Un pair dépourvu d’identité convenable, ou qui refuse de la fournir, peut envoyer un authentificateur vide. Finished est présent ; Certificate et CertificateVerify sont absents. Le MAC authentifie le refus dans la connexion, mais la fonction de validation ne retourne aucune identité valide.

Ce cas mérite un état propre : refus_vide_authentifié. Il diffère du silence, d’octets mal formés, d’une signature fausse et d’une chaîne rejetée. L’application peut poursuivre avec un privilège inférieur, arrêter une opération sensible ou proposer une autre méthode. Réessayer sans limite transformerait un refus valide en boucle de déni de service.

Le registre opérationnel

Le registre de connexion note version, suite, fin du handshake, vérification du Finished pair, EMS en TLS 1.2 et identifiant non secret. Celui de requête note rôle, hachage et unicité du contexte, extensions, cible, heure et canal.

Le registre de validation note mode demandé ou spontané, hachage du Certificate, empreintes de chaîne, algorithme et résultat CertificateVerify, résultat Finished, correspondance de connexion, politique X.509, refus vide, réception et validation. Le registre d’autorité note décideur, flux ou opération, ancien et nouveau privilège, effet, expiration et preuve de retour arrière.

Un taux global de réussite masque les fautes importantes. Il peut augmenter pendant que les contextes se répètent ou que l’élévation s’étend trop loin. À l’inverse, un rejet mauvaise connexion peut être la preuve exacte qu’un proxy n’a pas franchi la frontière.

IANA attribue les libellés. OpenSSL et BoringSSL montrent l’existence du substrat d’export sur une connexion réelle. Ni le registre ni ces interfaces ne prouvent l’usage de RFC 9261 ou une autorisation correcte. La réalité apparaît dans l’exécution reconstruisible : demande, preuve, validation, décision.

Sources