Résumé

  • NewSessionTicket remet au client une identité PSK opaque pour une future négociation. Son acceptation relie cryptographiquement une nouvelle connexion à celle qui a produit le ticket ; elle ne ressuscite ni l’ancien transport ni la vérité actuelle des décisions applicatives.
  • Durée, âge masqué, nonce, hachage KDF, SNI, mode PSK et binder répondent à des questions distinctes. Aucun ne prouve à lui seul une autorisation encore valable, le même backend, l’acceptation du 0-RTT ou le droit de réutiliser une décision ancienne.
  • Une reprise défendable exige un contrat d’état versionné, un domaine limité de clés et de services, une politique 0-RTT indépendante, la revalidation des pouvoirs variables et un repli observable vers une négociation complète.

Une réussite cryptographique au mauvais temps

Le ticket avait six heures. Le serveur de secours savait le déchiffrer et a retrouvé l’état associé. La négociation reprise s’est achevée normalement ; l’indicateur resumed est devenu vrai. Entre-temps, le système d’identité avait retiré au compte un rôle privilégié.

L’application n’a pas interrogé ce système. Elle a lu le rôle conservé avec l’état du ticket et a traité la réussite TLS comme une confirmation actuelle. Le défaut ne venait donc ni d’une falsification ni d’un binder incorrect. Il venait d’une confusion entre continuité d’un secret et continuité d’un pouvoir.

Deux horloges avaient été fusionnées. La politique cryptographique considérait encore la PSK utilisable. La politique métier avait déjà invalidé le rôle. TLS pouvait répondre à la première question ; seul le détenteur de l’état courant pouvait répondre à la seconde.

Le ticket désigne une nouvelle clé

TLS 1.3 rassemble la reprise sous un échange PSK. Après le Finished du client, le serveur peut envoyer NewSessionTicket. La valeur opaque du ticket est associée à une PSK dérivée du secret de reprise et d’un ticket_nonce propre à cette émission.

Le ticket peut être une simple clé de recherche dans une base serveur. Il peut aussi contenir un état chiffré et authentifié que le client transporte sans le comprendre. Dans les deux cas, sa fonction protocolaire est d’identifier une PSK. Il n’est ni l’ancienne clé de trafic ni l’ancienne connexion.

Un serveur peut émettre plusieurs tickets pour permettre des connexions parallèles ou une course entre interfaces. Chaque nonce donne une PSK distincte. Une journalisation qui réduit tout cela à « même session » efface précisément les générations que l’opérateur doit pouvoir révoquer ou comparer.

La reprise construit un nouveau transcript, de nouvelles clés de trafic et de nouveaux compteurs d’enregistrements. Elle ne restaure pas le socket, la mémoire du processus, la transaction applicative ou la route réseau précédente.

La durée limite l’essai du client

ticket_lifetime part de l’émission et ne dépasse pas sept jours. Zéro commande l’abandon immédiat. Le client peut supprimer le ticket plus tôt ; le serveur peut lui accorder une validité effective plus courte.

Le champ ne promet donc pas une acceptation jusqu’à son terme. Il indique la borne au-delà de laquelle le client ne doit plus tenter la reprise. Une rotation de clé, la suppression d’une entrée, une réduction de portée ou une politique applicative nouvelle peuvent imposer une négociation complète avant cette date.

ticket_age_add ajoute une valeur aléatoire propre au ticket à l’âge transmis. Ce masque complique la corrélation passive. Le serveur soustrait la valeur et vérifie la tolérance avec le temps écoulé. Une copie du ticket conserve cependant la même construction ; le champ n’est pas une preuve active d’unicité.

Un âge douteux ne produit pas nécessairement une seule décision globale. Le serveur devrait refuser les données 0-RTT et ne pas considérer le ClientHello comme frais, tout en pouvant poursuivre la reprise ordinaire. Les tableaux de bord doivent donc séparer âge, sélection PSK, reprise et données anticipées.

Le binder authentifie une chaîne limitée

Le ClientHello présente des identités PSK et un binder pour chacune. Le binder relie la PSK au nouveau handshake et, par le secret de reprise, au handshake d’origine. Il prouve que le client connaît le secret attendu et que l’offre actuelle n’est pas détachée de cette histoire.

Il ne certifie pas la fraîcheur d’un rôle, d’un abonnement, d’un état de conformité ou d’une décision de risque. Une affirmation peut être authentique et obsolète. L’intégrité empêche sa modification invisible ; elle n’arrête pas le temps.

Dans une reprise authentifiée par PSK, le serveur ne renvoie pas Certificate et CertificateVerify. Le contexte authentifié antérieur accomplit cette fonction cryptographique. Toute application qui lui associe des faits variables doit déclarer lesquels sont seulement référencés, lesquels expirent et lesquels exigent une nouvelle consultation.

OpenSSL rend cette frontière visible après une authentification client post-handshake : le serveur peut émettre de nouveaux tickets liés à l’identité client mise à jour. Les anciens tickets ne sont pas transformés rétroactivement. Une exploitation sûre doit distinguer ces populations.

Le nom du service appartient au présent

Le ClientHello de reprise transporte le SNI actuel. Le client ne doit reprendre que si le certificat de la session initiale était valide pour ce nom et devrait normalement conserver le même SNI. Si la bibliothèque expose le nom à l’application, elle doit fournir celui de la nouvelle négociation.

RFC 9525 conserve la même discipline : l’identité de référence appartient au service demandé maintenant. SNI et ALPN aident à nommer le service et le protocole. Un ticket déchiffrable n’est pas une autorisation générale pour tous les noms, locataires ou protocoles couverts par une infrastructure.

Partager une clé d’enveloppe entre régions peut améliorer la continuité. Cela agrandit aussi l’ensemble des nœuds capables d’interpréter un état ancien. BoringSSL expose la reprise entre noms comme une politique explicite. La capacité de déchiffrer ne décide pas, à elle seule, de la portée légitime.

La compatibilité du hachage KDF impose une autre limite. La suite choisie doit utiliser le même hachage que la connexion d’origine. Cette compatibilité permet la dérivation cryptographique ; elle ne maintient ni routage, ni autorisation, ni paramètre applicatif par décret.

Reprendre n’est pas exécuter tôt

Un ticket peut annoncer early_data et un volume maximal. Le client reçoit alors la faculté de proposer du 0-RTT. Le serveur reste libre de le refuser, et l’application reste seule capable de juger les conséquences d’une opération rejouable.

Trois résultats doivent être mesurés séparément : le ticket a été déchiffré ou retrouvé ; sa PSK a été sélectionnée ; le 0-RTT a été accepté. Un âge incertain, une mémoire anti-rejeu absente ou des paramètres applicatifs modifiés peuvent bloquer les données précoces sans empêcher la connexion reprise.

HTTP 425 intervient après cette frontière. L’origine peut refuser d’agir sur une requête marquée par sa provenance anticipée. Ce mécanisme ne définit pas l’autorité de l’état contenu dans le ticket. La présente analyse demeure entière lorsque le 0-RTT est désactivé.

QUIC ajoute encore ses paramètres de transport et d’application. Un ticket TLS valide ne prouve pas que les anciennes limites QUIC ou les anciens SETTINGS HTTP/3 restent compatibles. Chaque couche doit valider ce qu’elle seule connaît.

Le stockage dessine le domaine d’acceptation

Avec une base, le ticket peut être consommé, supprimé et audité sous une autorité centrale. La disponibilité et la cohérence de cette base deviennent alors des dépendances de la reprise. Un retard de réplication peut créer un refus erroné ou une seconde acceptation.

Un ticket autonome survit plus facilement à la perte d’un nœud. En contrepartie, tout nœud possédant la clé d’enveloppe peut souvent lire et accepter l’état jusqu’au retrait de cette clé. La distribution des clés devient donc une distribution de pouvoir.

Le choix n’oppose pas un modèle sûr à un modèle dangereux. Il choisit des domaines de panne. Une base partagée peut devenir indisponible ; une clé largement répliquée peut prolonger l’autorité d’un état obsolète ; une longue période de chevauchement peut masquer une rotation incomplète.

OpenSSL expose le résultat du déchiffrement, le nom de clé, les données applicatives du ticket, le nombre d’émissions et les options de suppression. GnuTLS contrôle les clés et les émissions supplémentaires. Le code de BoringSSL génère un nouvel âge masqué, limite les tickets et conditionne séparément les données précoces.

Ces surfaces prouvent l’existence d’un contrôle. Elles ne prouvent pas la configuration chargée, la synchronisation des régions, le contenu exact des claims ou la revalidation effectuée par l’application.

Transporter une référence plutôt qu’une vérité éternelle

Les faits cryptographiques stables peuvent traverser la frontière : identité PSK, hachage KDF, mode de reprise et référence bornée au handshake authentifié. Les faits métier variables ont besoin d’une version et d’une source actuelle.

Un ticket peut contenir un identifiant utilisateur et un numéro de version d’autorisation. Le service compare ce numéro à l’autorité courante avant d’accorder le rôle. Il peut transporter une route de locataire avec expiration et la refuser après migration. Une nouvelle authentification client peut produire une nouvelle génération de ticket.

Le mauvais modèle transporte directement « administrateur », « appareil fiable » ou « abonnement actif » sans version ni contrôle. Ces chaînes peuvent être parfaitement authentiques le jour où elles deviennent fausses.

EAP-TLS utilise des tickets pour reprendre une authentification et respecte la limite de sept jours. Ce profil illustre la responsabilité de la couche utilisatrice : elle doit dire ce que « reprendre » signifie et quel événement révoque le raccourci.

La preuve opérationnelle nécessaire

Conserver un identifiant de corrélation non réutilisable ou un nom de clé, le nœud et la région d’émission, l’heure, l’expiration annoncée et effective, l’époque de clé, le modèle de stockage, le hachage KDF et le mode PSK. À l’offre, enregistrer l’âge présenté, le résultat de déchiffrement, l’identité sélectionnée, le SNI et l’ALPN actuels, puis le résultat de reprise ou de repli.

Tracer séparément le 0-RTT : proposition, éligibilité, acceptation, limite, état anti-rejeu et décision applicative. resumed=true ne doit jamais signifier implicitement early_data_accepted=true.

Pour les pouvoirs métier, enregistrer la version du schéma, la version d’autorisation, la vérification de révocation, la version de routage et la source de la décision actuelle. Le journal relie émission et acceptation sans exposer ticket ou PSK.

Tester les tickets expirés, les durées raccourcies, les clés inconnues ou retirées, l’échec d’authentification, la suppression en base, le rejeu interrégional, le changement SNI/ALPN, le hachage incompatible et le compte révoqué dont le ticket reste déchiffrable.

Enfin, prouver le repli. Le rejet du ticket doit permettre une négociation complète quand la politique l’autorise. Le mécanisme d’urgence doit retirer une époque de clé ou une version d’état sans interrompre les connexions TLS étrangères à cette décision.

Sources