Résumé

  • Le ticket de session TLS transporte chez le client un état de reprise rendu opaque par le serveur. Le client le conserve et le présente, sans pouvoir le lire, le modifier ni obliger le serveur à l’accepter.
  • L’économie de fiches individuelles ne supprime pas l’état côté serveur : elle en concentre une partie dans les clés de protection, les règles d’expiration et le choix des nœuds autorisés à ouvrir les tickets.

Une consigne extérieure pour la mémoire du serveur

Au premier échange, un serveur négocie des paramètres cryptographiques coûteux. Au suivant, il aimerait les retrouver sans recommencer tout le dialogue. L’ancienne solution consistait à remettre au client un identifiant court et à garder, derrière cet identifiant, une fiche de session. Le client rapportait le numéro ; le serveur devait encore posséder la fiche.

RFC 5246 décrit cette logique pour TLS 1.2 : une session réunit des paramètres réutilisables par plusieurs connexions, et un identifiant choisi par le serveur désigne un état actif ou reprenable. Le gain de calcul se payait en mémoire, en vieillissement des entrées et en coordination. Dans une ferme de serveurs, la prochaine connexion devait retrouver le bon cache ou revenir sur le bon nœud.

La proposition publiée dans RFC 4507 en 2006 a retourné le problème. Plutôt que de conserver une fiche et d’en donner la référence, le serveur enfermait la fiche elle-même dans un ticket protégé et la remettait au client. RFC 5077 a remplacé ce premier texte en 2008 tout en conservant l’idée.

Le client devenait ainsi une consigne extérieure. Il portait la mémoire, mais n’en devenait ni l’auteur ni le lecteur.

Un objet opaque n’est pas un ordre

Dans le format recommandé par RFC 5077, l’état chiffré peut contenir la suite cryptographique, le secret maître, un horodatage et les informations utiles sur l’authentification initiale. Un nom de clé indique au serveur quelle protection essayer ; un contrôle d’intégrité empêche une modification discrète du contenu.

L’opacité est une frontière d’autorité. Le client ne doit pas interpréter la structure interne. Il conserve le ticket avec les paramètres associés, le renvoie dans un nouveau ClientHello et prouve, au cours de la poignée de main abrégée, qu’il possède aussi le secret nécessaire. Un ticket copié seul n’est donc pas une autorisation complète.

Le serveur, lui, déchiffre, vérifie la validité et décide. Il peut renouveler le ticket, l’ignorer ou procéder à une négociation complète. La présence d’un objet émis hier ne contraint pas la politique d’aujourd’hui. Une suspension de compte, un changement de rôle ou une nouvelle règle applicative doivent encore être évalués au-dessus de TLS.

Le refus faisait partie du fonctionnement normal

Un système de reprise sûr doit supporter l’échec de la reprise. Une clé peut avoir tourné ; le ticket peut avoir expiré ; le client peut arriver dans une zone qui ne partage pas la clé ; le serveur peut avoir changé de politique. RFC 5077 permet alors de revenir à la poignée de main complète.

Ce chemin de sortie empêche l’optimisation de devenir un verrou. Le refus d’un ticket n’affirme pas que le serveur est inaccessible ou que le certificat est faux. Il affirme seulement que cet ancien état ne sera pas réutilisé. Si l’exploitation traite chaque refus comme une panne, elle sera tentée de conserver trop longtemps les clés anciennes et d’élargir leur diffusion.

La réception d’un ticket renouvelé n’est pas non plus acquise avant la fin de l’échange. Le serveur ne peut pas confondre envoi, réception et adoption. Cette modestie évite que deux extrémités attribuent des états différents à la prochaine connexion.

Moins d’entrées, une clé plus puissante

Le terme « sans état côté serveur » décrit l’absence possible d’une fiche par client. Il ne décrit pas une machine amnésique. Le serveur conserve ses clés de ticket, les algorithmes, les règles de durée, les connexions en cours et le pouvoir d’accepter.

Cette nouvelle forme d’état est plus petite mais peut avoir une portée supérieure. Une clé partagée entre plusieurs nœuds facilite la reprise après répartition de charge. La même clé fait aussi de tous ces nœuds un seul domaine de compromission. Une clé locale limite l’exposition, au prix de négociations complètes plus fréquentes lorsque le client change de nœud.

RFC 5077 recommande de réserver les clés à la protection des tickets et de les changer régulièrement. RFC 9325 transforme l’hygiène opérationnelle en exigences plus nettes : rotation régulière, destruction des anciennes clés en fin de validité et durée raisonnable des tickets. Le but est d’éviter qu’une clé récupérée tardivement ouvre une tranche trop longue de l’histoire cryptographique.

Trois horloges au lieu d’une

Le ticket TLS 1.2 comporte une indication de durée. Le client devrait supprimer l’objet à l’échéance et peut le faire avant. Le serveur peut cependant appliquer une durée plus courte ou plus longue que l’indication. Ce nombre guide le stockage ; il ne réserve pas une reprise future.

Il faut donc distinguer l’âge annoncé au client, la fenêtre réellement acceptée et le temps pendant lequel la clé de protection reste disponible. Une rotation mal conduite peut rendre les tickets inutilisables trop tôt. Une clé ancienne réintroduite par un rollback peut, au contraire, les ressusciter au-delà du périmètre prévu.

La boîte ne corrige pas ce qui a été mal lié

La reprise hérite des propriétés de la session d’origine. RFC 7627 a montré que l’ancien secret maître n’était pas lié à suffisamment d’éléments de la négociation. Un attaquant actif pouvait synchroniser des secrets entre deux sessions, puis fragiliser les mécanismes qui supposaient leur unicité, y compris la reprise.

L’extension « extended master secret » a lié le secret au transcript de la poignée de main. La leçon dépasse la correction : chiffrer parfaitement un état portable ne répare pas une origine ambiguë. La qualité du sceau ne remplace pas la qualité de l’histoire placée dans l’enveloppe.

TLS 1.3 : un ticket pour désigner une PSK

RFC 8446 a reconstruit la reprise autour d’une clé prépartagée. Après la négociation principale, le serveur peut envoyer un NewSessionTicket avec une durée, une valeur masquant l’âge, un nonce et une identité opaque. Lors d’une connexion ultérieure, le client présente cette identité avec un binder qui prouve la possession de la PSK.

La durée annoncée ne peut dépasser sept jours et le client ne peut conserver le ticket plus longtemps. Surtout, la PSK peut être combinée à un nouvel échange Diffie–Hellman éphémère. RFC 9325 recommande cette combinaison lorsque la confidentialité persistante compte : reprendre ne signifie pas forcément renoncer à tout apport cryptographique nouveau.

Les données 0-RTT sont une option voisine, non la définition du ticket. Une reprise peut rester en 1-RTT. Confondre les deux ferait croire à tort que chaque ticket doit être à usage unique ou que désactiver les données précoces résout la gestion des clés.

Un contenu caché peut encore servir d’étiquette

RFC 5077 impose la confidentialité du contenu, notamment pour éviter la fuite d’informations sur l’utilisateur. Il prévient aussi que la réutilisation visible d’un même ticket peut relier plusieurs connexions. RFC 9325 conserve cette inquiétude de suivi.

Le chiffrement répond à « que contient l’objet ? », pas forcément à « est-ce le même objet ? ». Fréquence d’émission, renouvellement, réutilisation et durée sont donc aussi des paramètres de vie privée.

Ce qui a réellement été déplacé

Les tickets ont déplacé les données nécessaires à la reconstruction d’une session et réduit l’obligation de retrouver une fiche par client. Ils n’ont déplacé ni la clé qui donne sens au ticket, ni la décision de l’accepter, ni l’autorité applicative.

Ils ne prouvent pas une identité humaine, une permission commerciale actuelle, un usage unique ou l’absence totale d’état. Leur réussite historique tient à une séparation plus fine : le client peut porter une mémoire que seul le serveur gouverne, à condition que la portée des clés, l’expiration et le retour à la négociation complète restent explicites.

Sources et limites des preuves

Le dossier officiel comprend RFC 4507, RFC 5077, RFC 5246, RFC 7627, RFC 8446 et RFC 9325. L’analyse du périmètre de flotte et des incitations d’exploitation découle de ces mécanismes ; elle ne mesure aucun fournisseur particulier.