Renforcer la rotation des clés de chiffrement des tickets de session dans les proxies Edge distribués

TLS session resumption est l’un des rares endroits en ingénierie réseau moderne où une optimisation de performance érode directement une garantie de sécurité. La clé de chiffrement du ticket de session (STEK) se trouve à cette intersection : elle permet aux proxies edge d’éviter les échanges cryptographiques complets pour les clients de retour, mais en créant une seule clé symétrique qui déverrouille chaque session chiffrée avec elle. Si la gestion des clés est mal faite — ce que les équipes en production font régulièrement — un adversaire passif enregistrant des ciphertexts depuis des semaines dispose soudainement de l’oracle de déchiffrement.

Cet article explique comment fonctionnent les STEKs au niveau du protocole, ce que la recherche dit de leurs échecs en pratique, comment concevoir une boucle de rotation multi-clés automatisée qui survive au routage Anycast et aux fenêtres de propagation des clés globales, et comment le modèle PSK de TLS 1.3 modifie la surface de menace sans l’éliminer.

---

1. Le modèle de ticket de session sans état

Une poignée de handshake TLS 1.3 nécessite au moins un aller-retour avant que les données d’application ne puissent circuler. Pour un client mobile atteignant une API via un chemin à haute latence, cet overhead est mesurable. Le mécanisme de ticket de session, défini pour TLS 1.2 dans RFC 5077 et adapté au modèle de reprise PSK (Pre-Shared Key) de TLS 1.3 dans RFC 8446, décharge l’état de session vers le client pour supprimer ce coût.

Le flux est simple :

1. Après un handshake complet, le serveur dérive un secret de reprise et l’encrypte avec la STEK — une clé symétrique détenue uniquement par le serveur — produisant un blob opaque appelé ticket de session.
2. Le serveur envoie ce ticket au client dans un message NewSessionTicket. Le client le stocke localement.
3. Lors de la reconnexion, le client attache le ticket à son ClientHello. Le serveur le déchiffre avec sa copie locale de la STEK, récupère le secret de reprise, et évite la phase de négociation de clé.

La propriété critique ici est l’absence d’état côté serveur : celui-ci ne stocke rien par session. Tout l’état de reprise vit dans le ticket chiffré sur le client. Pour un tissu edge distribué où n’importe lequel des PoPs peut recevoir le prochain paquet d’un client en roaming, c’est architecturalement essentiel — il n’y a pas de base de données de sessions partagée à synchroniser.

[ Client ]                               [ Proxy Edge Distribué ]
     |                                               |
     | ---- ClientHello (Avec Ticket de Session) ----> |
     |                                               |  [ Déchiffre le ticket ]
     |                                               |  [ Utilise la STEK active ]
     | <--- ServerHello (Session reprise, 0/1-RTT) --- |

---

2. La vulnérabilité du ticket de session : briser la confidentialité future

TLS assure la confidentialité future parfaite (PFS) via des échanges de clés Diffie-Hellman éphémères : même si un adversaire compromet plus tard la clé privée à long terme d’un serveur, il ne peut pas déchiffrer le trafic de sessions capturées auparavant, car chaque session dérivait ses clés symétriques d’une paire de clés ECDHE fraîche et abandonnée.

Les tickets de session sapent cette garantie à un niveau structurel. Le ticket contient le secret de reprise. La STEK chiffre le ticket. Si un adversaire extrait la STEK — via divulgation mémoire, canal latéral, ou insider compromis — il peut déchiffrer tous les tickets encryptés sous cette clé et récupérer les secrets de session sous-jacents.

Comme le dit directement le papier USENIX Security 2023 de Hebrok et al. : un adversaire pouvant compromettre la STEK peut enregistrer passivement et déchiffrer les sessions TLS, et peut aussi usurper le serveur.

Ce que la recherche montre

Le danger n’est pas théorique. Trois classes distinctes d’échecs en pratique ont été documentées :

Le piège de la clé statique. Beaucoup de load balancers open-source et d’implémentations de proxies génèrent une STEK au démarrage du processus et la font tourner uniquement lors d’un redémarrage. Un serveur avec une haute disponibilité peut exposer des mois de données de session historiques à une seule extraction de clé. RFC 5077 recommandait déjà de faire tourner la STEK au moins toutes les 24 heures, précisément parce qu’une compromission de la clé n’expose que les sessions de cette période de rotation plutôt que tout le trafic historique.

La STEK tout-zéro (CVE-2020-13777). Les versions 3.6.4 à 3.6.13 de GnuTLS comportaient un bug d’initialisation de rotation : la structure de session est zéroisée au démarrage, et la STEK n’est pas réellement peuplée avant que la première rotation programmée ne se déclenche — six heures plus tard par défaut. Pendant cette fenêtre initiale, tous les tickets étaient encryptés avec une clé tout-zéro, permettant à quiconque de les déchiffrer avec zéro effort cryptographique. Pour TLS 1.2, cela permettait de récupérer en plaintext tout le trafic passivement. Pour TLS 1.3, cela réduisait à une attaque de type man-in-the-middle contre la session reprise. Le bug a été introduit lors de l’ajout du support de rotation basé sur TOTP ; le chemin d’initialisation ne déclenchait pas une génération immédiate de clé avant la première émission de ticket.

L’incident de clé non initialisée de l’AWS ALB (AWS-2021-002). En avril 2021, AWS a révélé qu’un cas limite introduit en septembre 2020 causait une utilisation intermittente d’une clé de chiffrement de ticket de session non initialisée lors de périodes de faible trafic. La fenêtre d’exposition a duré jusqu’au 16 avril 2021, date à laquelle AWS a déployé une mitigation complète. La connaissance de ce cas limite pourrait théoriquement permettre de déchiffrer certains tickets affectés, bien qu’AWS ait noté que le trafic traversant les contrôles de chiffrement du réseau AWS restait protégé.

Clés faibles et keystreams répétées. L’analyse à grande échelle du USENIX Security 2023 par Hebrok et al. — premier audit cryptographique systématique des implémentations de tickets de session à l’échelle Internet — a trouvé que des serveurs vulnérables utilisaient des clés faibles ou des keystreams répétées dans leurs tickets, permettant leur déchiffrement. Parmi les résultats majeurs : une faille répandue dans l’écosystème AWS qui permettait de déchiffrer passivement le trafic pour au moins 1.9% des serveurs du Top 100k de Tranco. Le papier a reçu un prix d’Artifact distingué à USENIX Security 2023.

Confusion de tickets de session virtuels (USENIX Security 2025). Un article de suivi du même groupe de recherche — “STEK Sharing is Not Caring: Bypassing TLS Authentication in Web Servers using Session Tickets” (Hebrok et al., 2025) — a démontré que partager une STEK entre hôtes virtuels sur la même IP et port permet de réutiliser des tickets d’un hôte virtuel contre un autre, contournant l’authentification par certificat client et serveur. Leur scan à grande échelle a trouvé que toutes les quatre implémentations open-source analysées — Apache (CVE-2025-23048), nginx (CVE-2025-23419), (Open)LiteSpeed, et Caddy — étaient vulnérables à des contournements d’authentification client, et six clusters de CDN vulnérables, dont Fastly susceptible de contournement d’authentification serveur. Fastly a corrigé en liant les tickets au certificat émetteur ; Cloudflare, en tant que mitigation initiale, a désactivé les tickets de session lorsque l’authentification client est active.

CVE-2025-23419 (nginx / F5 NGINX Plus, 2025). Lorsque plusieurs blocs serveur nginx partagent la même IP et port et que le bloc serveur par défaut utilise des tickets TLS ou le cache de session SSL, un client authentifié légitimement contre le serveur par défaut peut reprendre cette session contre un autre bloc serveur sans présenter à nouveau son certificat. La vulnérabilité concerne nginx 1.11.4 et ultérieur compilé avec OpenSSL, lorsque TLSv1.3 et la reprise de session sont activés, et a été corrigée dans nginx 1.26.3 et 1.27.4.

---

3. La problématique de synchronisation dans les proxies Edge distribués

Sécuriser un seul serveur avec un script de rotation STEK local est une problématique résolue. Gérer la rotation STEK à travers un tissu proxy distribué globalement sous routage Anycast est une toute autre difficulté.

+---------------------------------------------------------------------+
|                        GESTIONNAIRE CENTRAL DE CLÉS                |
|         (Génère & signe cryptographiquement les nouvelles STEKs)    |
+---------------------------------------------------------------------+
              |                                  |
    Distribution sécurisée             Distribution sécurisée
              v                                  v
  +-----------------------+         +-----------------------+
  |    PoP Anycast A     |         |    PoP Anycast B     |
  |  (Noeud Edge Tokyo)  |         |  (Noeud Edge Londres)|
  |   - STEK active v2  |         |   - STEK active v2  |
  |   - STEK en cours de retrait v1 | |   - STEK en cours de retrait v1 |
  +-----------------------+         +-----------------------+
              |                                  |
              +----------------------------------+
                              |
                     [ Client mobile ]
               (Roaming Tokyo → Londres en cours de session)

Dans une topologie edge distribuée, un client peut initier une connexion à un PoP Tokyo, recevoir un ticket de session encrypté sous la STEK active de ce nœud, roamer via Anycast vers un PoP Londres, et présenter le même ticket. Si Londres ne possède pas la STEK exacte qui a encrypté le ticket, la reprise de session échoue et le proxy revient à un handshake complet 1-RTT.

Si cette défaillance de synchronisation se produit à grande échelle lors d’une fenêtre de rotation globale — chaque nœud edge tournant simultanément — cela entraîne une avalanche de handshakes cryptographiques complets. La surcharge CPU en entrée de réseau suit, la latence explose, et sous charge soutenue, des défaillances en cascade du tissu edge deviennent possibles.

L’astuce opérationnelle tentante est de configurer une seule STEK statique sur toutes les instances globales via un fichier de configuration partagé et de la laisser inchangée indéfiniment. C’est exactement la mauvaise approche : cela échange un risque opérationnel bien compris (pic de latence lors de la rotation) contre une exposition à la confidentialité qui s’accroît chaque heure.

---

4. Concevoir une boucle de rotation STEK automatisée et sans interruption

La solution est un cycle cryptographique multi-clés garantissant que chaque nœud proxy détient simultanément plusieurs clés dans des états opérationnels distincts : une pour le chiffrement actif, une ou plusieurs pour la décryption gracieuse des tickets plus anciens encore en circulation, et une voie de purge propre qui efface les clés de la mémoire volatile une fois leurs tickets expirés.

Les quatre phases du cycle de vie de la STEK

Une architecture de rotation bien conçue suit chaque clé à travers quatre états :

Pré-positionnée (Next). Une clé nouvellement générée, distribuée à tous les nœuds edge globaux mais pas encore utilisée pour chiffrer des données. La fenêtre de pré-distribution — typiquement 5–15 minutes — absorbe le délai de propagation réseau et le décalage d’horloge, garantissant que chaque nœud détient la clé avant qu’elle ne devienne l’encryptor active.

Active (Primary). La clé utilisée actuellement pour chiffrer tous les nouveaux tickets de session et pour déchiffrer ceux reçus qui ont été encryptés avec elle.

En retrait (Previous). Une clé plus utilisée pour le chiffrement, mais conservée en mémoire pour déchiffrer d’anciens tickets encore en circulation dans les navigateurs. La durée de vie d’un ticket de navigateur peut atteindre 24h, donc la pile en retrait doit couvrir cette fenêtre.

Purge (Expired). La clé est écrasée en toute sécurité dans la mémoire volatile. Une fois purge, tout adversaire détenant du ciphertext historique encrypté sous cette clé perd sa capacité de déchiffrement — c’est la définition cryptographique de la confidentialité future pour cette période.

Fréquence de rotation

RFC 5077 recommandait de faire tourner la STEK au moins toutes les 24h. En production, avec des exigences de sécurité plus élevées, la rotation se fait souvent toutes les 1–6h. Avec une rotation horaire et une durée de vie de ticket navigateur de 24h, le proxy doit maintenir une pile d’environ 24 clés en retrait en plus de la clé active.

Fenêtre temporelle	Slot STEK 1 (Primary)	Slot STEK 2 (En retrait)	Slot STEK 3 (En retrait)	Slot STEK 4 (Purge)
00:00 – 01:00	Clé_C (Chiffre/Déchiffre)	Clé_B (Déchiffre uniquement)	Clé_A (Déchiffre uniquement)	Clé_0 (Purge mémoire)
01:00 – 02:00	Clé_D (Chiffre/Déchiffre)	Clé_C (Déchiffre uniquement)	Clé_B (Déchiffre uniquement)	Clé_A (Purge mémoire)
02:00 – 03:00	Clé_E (Chiffre/Déchiffre)	Clé_D (Déchiffre uniquement)	Clé_C (Déchiffre uniquement)	Clé_B (Purge mémoire)

---

5. Guide étape par étape pour la mise en œuvre

Étape 1 : Génération de clés cryptographiquement sécurisée

Le coordinateur central doit utiliser un générateur de nombres pseudo-aléatoires cryptographiquement sécurisé (CSPRNG). Pour l’implémentation nginx de RFC 5077, une STEK nécessite 48 octets d’entropie brute : 16 octets pour un nom de clé unique (utilisé par le client pour identifier la STEK qui a encrypté son ticket), 16 octets pour une clé de chiffrement AES-128, et 16 octets pour une clé d’authentification HMAC-SHA256.

#!/usr/bin/env bash
set -euo pipefail

# Générer une STEK cryptographiquement sécurisée de 48 octets pour nginx
NOM_CLÉ=$(openssl rand -hex 16)
CLÉ_AES=$(openssl rand -hex 16)
CLÉ_HMAC=$(openssl rand -hex 16)

# Écrire la structure binaire brute directement en mémoire volatile — jamais sur disque
echo "${NOM_CLÉ}${CLÉ_AES}${CLÉ_HMAC}" | xxd -r -p > /dev/shm/stek_new.bin

La sortie se trouve dans /dev/shm — un système de fichiers en mémoire tmpfs — plutôt que sur un stockage en bloc. Cela a son importance : une extraction forensique à partir de blocs disque supprimés est une voie d’attaque documentée ; des clés qui ne touchent jamais le stockage non volatile n’ont aucune surface de récupération après écrasement.

Étape 2 : Pipeline de distribution sécurisé

Le gestionnaire de clés central — HashiCorp Vault est un choix courant pour son moteur de secrets dynamiques, ses logs d’audit, et son enforcement de politiques d’accès — génère une nouvelle STEK à cadence fixe, assemble la clé active actuelle plus les clés en retrait nécessaires dans un fichier de clés empilées, et la distribue à tous les nœuds edge via un canal de contrôle TLS mutuellement authentifié (mTLS).

Le daemon de distribution sur chaque nœud écrit directement le matériel clé reçu dans un chemin en tmpfs et ne le met jamais en buffer sur disque. Le canal de contrôle doit lui aussi être mTLS-authentifié et surveillé ; un canal compromis est une cible de valeur supérieure à un seul nœud edge, puisqu’il touche chaque nœud du parc.

Étape 3 : Rechargement sans interruption dans nginx

La directive ssl_session_ticket_key d’nginx accepte un chemin vers un fichier clé binaire. Lorsqu’on liste plusieurs clés — ou qu’un seul fichier contient plusieurs clés de 48 octets — nginx utilise la première clé pour chiffrer les nouveaux tickets et tente toutes les clés suivantes pour déchiffrer ceux entrants.

http {
    ssl_session_tickets on;

    # Chemin en mémoire ; ne pointe jamais vers un disque persistant
    ssl_session_ticket_key /dev/shm/tls_session_ticket.keys;

    server {
        listen 443 ssl;
        server_name api.exemple.com;

        ssl_certificate     /etc/letsencrypt/live/exemple.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/exemple.com/privkey.pem;
        ssl_protocols       TLSv1.2 TLSv1.3;

        # Mitigation CVE-2025-23419 : désactiver les tickets par vhost quand mTLS est actif
        # ssl_session_tickets off;
    }
}

La séquence atomique de remplacement de clé et de rechargement gracieux :

# Empiler la clé active courante en premier, suivie des clés en retrait par ordre d’âge
cat /dev/shm/stek_current.bin \
    /dev/shm/stek_previous_1.bin \
    /dev/shm/stek_previous_2.bin \
    > /dev/shm/tls_session_ticket.keys.tmp

# Remplacement atomique — mv sur le même système de fichiers est un syscall rename(2), donc atomique
mv /dev/shm/tls_session_ticket.keys.tmp /dev/shm/tls_session_ticket.keys

# SIGHUP déclenche un rechargement gracieux : les nouveaux workers prennent le fichier clé mis à jour,
# les anciens terminent leurs connexions actives sous l’ancien jeu de clés et se ferment proprement — aucune connexion n’est perdue
nginx -s reload

Lorsqu’nginx reçoit SIGHUP, le processus maître fork de nouveaux workers qui héritent de la nouvelle structure mémoire. Les workers existants terminent leurs connexions actives sous l’ancien set de clés et se ferment proprement — aucune connexion n’est interrompue.

Mitigation CVE-2025-23419

Comme le montre la recherche USENIX 2025, partager une STEK entre blocs serveur nginx servant différents hôtes virtuels sur la même IP:port permet à un ticket d’un hôte virtuel d’être repris contre un autre, contournant l’authentification par certificat client. Si votre configuration utilise plusieurs blocs serveur sur une IP:port partagée avec une authentification client, la mitigation consiste à désactiver les tickets de session sur le serveur par défaut ou sur tout bloc où l’accès est contrôlé par mTLS :

server {
    listen 443 ssl default_server;
    ssl_client_certificate /etc/ssl/ca.crt;
    ssl_verify_client on;

    # Désactiver les tickets pour éviter la confusion entre vhosts
    ssl_session_tickets off;
}

Nginx 1.26.3 et 1.27.4 incluent la correction en amont.

---

6. Architecture PSK TLS 1.3 et exception 0-RTT

TLS 1.3 remplace la structure explicite de RFC 5077 par un modèle unifié de reprise PSK. Les améliorations architecturales sont réelles, mais accompagnées d’une exception majeure : les données précoces 0-RTT.

psk_dhe_ke restaure la confidentialité future pour la reprise standard

TLS 1.3 définit deux modes d’échange de clés PSK : psk_ke (reprise symétrique pure, sans échange de clé supplémentaire) et psk_dhe_ke (PSK plus échange Diffie-Hellman éphémère). Lorsqu’il est configuré avec psk_dhe_ke, une session reprise effectue toujours un nouvel échange ECDHE après la validation du ticket. Les données d’application suivantes sont enveloppées dans une clé de session dérivée à partir du secret de reprise et du nouvel échange éphémère — ce qui signifie qu’un adversaire qui extrait la STEK ne pourra pas déchiffrer les données de la session reprise sans casser aussi l’échange éphémère.

Forcer le mode psk_dhe_ke dans un contexte de menace quantique est aussi pertinent : la recherche sur les attaques de récolte différée (harvest-now, decrypt-later) identifie précisément la combinaison de psk_dhe_ke et rotation fréquente de STEK comme rompant la chaîne de reprise sur laquelle s’appuient les adversaires passifs de collecte massive.

0-RTT : la vulnérabilité qui subsiste

0-RTT permet à un client de revenir en envoyant directement ses requêtes HTTP dans son ClientHello initial, réalisant une transmission de données à latence zéro pour le premier aller-retour. C’est le mécanisme que les CDN vendent comme “reprise instantanée.”

[ Client ]                               [ Proxy Edge Distribué ]
     |                                               |
     | -- ClientHello + Données 0-RTT (via PSK) -----> |
     |                                               |  [ Déchiffre immédiatement ]
     |                                               |  [ Transmet au backend ]
     |                                               |  [ ECDHE pas encore terminé ]

Parce que ces données précoces sont envoyées avant la fin de l’échange ECDHE, leur confidentialité repose entièrement sur le secret de reprise dans le ticket de session — le blob chiffré par la STEK. Un adversaire détenant une STEK compromise peut déchiffrer immédiatement les données 0-RTT sans effort cryptographique supplémentaire.

Pire, les données 0-RTT sont intrinsèquement vulnérables aux attaques de replay. Le protocole lui-même l’admet : la section 8 de la RFC 8446 impose explicitement que la protection contre la répétition des données 0-RTT incombe aux développeurs d’application plutôt qu’au TLS. Un attaquant peut intercepter un paquet 0-RTT légitime — un transfert financier, un appel API modifiant l’état, une requête d’authentification — et le rejouer contre plusieurs PoPs edge. Comme le proxy sans état déchiffre le ticket et traite la requête intégrée sans état par requête, l’exécution en double est la règle sauf si l’application empêche explicitement.

En pratique, cela a des conséquences. Rejouer une requête POST /api/transfers entraîne une double exécution de transaction. Rejouer une soumission de commande entraîne une double facturation. L’analyse CertGuard de mars 2026 a documenté un cas où un attaquant rejouant des webhooks 0-RTT contre plusieurs PoPs CDN a déclenché des doubles charges de processeur de paiement ; l’anomalie n’a été détectée que parce que le processeur en aval a signalé des IDs de transaction en double.

---

7. Mitigations anti-replay pour les environnements 0-RTT

La posture défensive pour 0-RTT doit inclure des contrôles à plusieurs niveaux :

Restreindre 0-RTT aux méthodes HTTP idempotentes. La règle de base est de bloquer le traitement 0-RTT pour toute méthode ayant des effets de bord. Seules GET, HEAD, et OPTIONS sont sûres pour 0-RTT — leur rejouer donne le même résultat. POST, PUT, PATCH, et DELETE doivent être rejetées en 0-RTT et attendre la complétion du handshake 1-RTT.

Validation de l’âge du ticket. TLS 1.3 inclut une extension d’âge du ticket obfusquée dans le ClientHello. Le proxy évalue si l’âge revendiqué du ticket est dans une marge acceptable par rapport à l’horloge du serveur. Les requêtes où le delta dépasse la fenêtre acceptable — indiquant une répétition ou un paquet obsolète — doivent être rejetées ou forcer un handshake complet. Cela offre une protection approximative mais pas une garantie cryptographique.

Clés d’idempotence côté application. Pour tout endpoint nécessitant des méthodes non-GET et où le 0-RTT ne peut pas être désactivé complètement, l’application doit exiger une clé d’idempotence par requête dans la charge ou l’en-tête. Le backend vérifie cette clé dans un magasin de déduplication à courte durée avant exécution. C’est la défense la plus fiable car elle fonctionne indépendamment de la configuration TLS.

Fonctions pseudo-aléatoires puncturables (PPRFs). La recherche académique d’Aviram, Gellert, et Jager (publiée dans le Journal of Cryptology, 2021) propose un mécanisme côté serveur où la STEK elle-même est “puncturée” après chaque utilisation. Le serveur dérive une nouvelle clé capable de déchiffrer tous les tickets sauf celui utilisé, puis jette l’originale. Cela rend chaque ticket déchiffrable une seule fois, éliminant la replay à la couche cryptographique. La méthode offre simultanément confidentialité future et résistance au replay, bien que la construction naïve par chiffrement à clé publique soit peu pratique ; la construction basée sur PPRF dans l’article la résout avec des tailles de clés raisonnables.

Désactiver le 0-RTT pour les endpoints sensibles. Lorsque les autres contrôles ne sont pas réalisables, la posture la plus simple et correcte est de désactiver complètement le 0-RTT pour les endpoints où la répétition aurait des conséquences. La plupart des plateformes CDN et proxy permettent une configuration par route. Le coût en latence d’un aller-retour supplémentaire lors de la reconnexion est mesurable mais limité ; le coût d’une fraude par replay non détectée ne l’est pas.

---

8. Observabilité, audit, et télémétrie

Un système de rotation STEK sans surveillance est un contrôle de sécurité qui peut échouer silencieusement pendant de longues périodes. Les anomalies cryptographiques ne déclenchent pas d’alarmes de disponibilité classiques — un proxy servant des données cryptées corrompues ressemble à un proxy sain.

Métriques de télémétrie critiques

Les équipes d’infrastructure doivent exposer et alerter sur ces métriques TLS spécifiques au niveau d’entrée edge :

tls.resumption.ticket_received — volume brut de clients tentant la reprise de session sans état.

tls.resumption.success — handshakes réussis utilisant une STEK valide ou en retrait.

tls.resumption.fail.key_not_found — client a présenté un ticket, mais aucune STEK locale ne correspond au nom de clé. Des pics soutenus indiquent une défaillance de synchronisation dans la distribution globale des STEKs — symptôme du problème de “cache miss stampede” décrit en section 3.

tls.resumption.fail.decryption_error — nom de clé trouvé, mais échec de vérification HMAC ou de déchiffrement. Un taux d’échec occasionnel est normal (tickets corrompus, bit-flips, stockage client défectueux) ; une augmentation soutenue indique une manipulation active, un fuzzing par un acteur malveillant, ou une corruption de clé.

Vérifications d’intégrité continue des clés

Le daemon de rotation doit effectuer des contrôles de santé en continu sur le matériel clé en mémoire volatile :

#!/usr/bin/env bash
CLÉ_FICHIER="/dev/shm/tls_session_ticket.keys"
EXPECTED_SIZE=48  # octets par STEK

# Vérifier que le fichier existe et n’est pas vide
if [[ ! -s "$CLÉ_FICHIER" ]]; then
    echo "CRITIQUE : fichier de clés STEK manquant ou vide" >2
    exit 2
fi

TAILLE_FICHIER=$(stat -c%s "$CLÉ_FICHIER")

# Vérifier que la taille est un multiple exact de 48 octets
if (( TAILLE_FICHIER % EXPECTED_SIZE != 0 )); then
    echo "CRITIQUE : taille du fichier de clés STEK (${TAILLE_FICHIER}) n’est pas un multiple de ${EXPECTED_SIZE}" >2
    exit 2
fi

# Vérifier que l’entropie n’est pas suspectement faible (fichier de clés nul ou tout-zéro)
NUL_BYTES=$(xxd -p "$CLÉ_FICHIER" | tr -d '\n' | grep -o '00' | wc -l)
TOTAL_OCTETS=$(( TAILLE_FICHIER * 2 ))  # caractères hex
TAUX_NUL=$(echo "scale=4; $NUL_BYTES / $TOTAL_OCTETS" | bc)

if (( $(echo "$TAUX_NUL > 0.10" | bc -l) )); then
    echo "CRITIQUE : taux de null-byte élevé dans le fichier de clés STEK : ${TAUX_NUL}" >2
    exit 2
fi

echo "OK : fichier de clés STEK de ${TAILLE_FICHIER} octets, ${TAILLE_FICHIER / EXPECTED_SIZE} clés, test d’entropie réussi"

Le test du taux de null-byte cible directement le mode d’échec ayant produit CVE-2020-13777 et l’incident AWS-2021-002 : un processus de rotation qui écrase silencieusement le fichier de clés actif avec des octets zéro ou non initialisés.

Audit d’isolation des hôtes virtuels

Compte tenu des divulgations de 2025, tout déploiement nginx ou Apache utilisant plusieurs blocs serveur sur une IP:port partagée doit aussi auditer la portée des tickets de session :

# Vérifier la configuration pour mTLS + tickets de session sur des écouteurs partagés
nginx -T 2>/dev/null | awk '
    /server {/           { in_server=1; mTLS=0; tickets=1; ip="" }
    /listen/             { ip=$2 }
    /ssl_verify_client on/ { mTLS=1 }
    /ssl_session_tickets off/ { tickets=0 }
    /^[[:space:]]*}/    {
        if (in_server && mTLS && tickets)
            print "AVERTISSEMENT : mTLS + tickets de session sur " ip " — exposition CVE-2025-23419"
        in_server=0
    }
'

---

9. Conclusion

La STEK est l’une des clés symétriques à la plus haute valeur dans un déploiement TLS distribué. Elle ne protège pas une seule session — elle protège toutes les sessions encryptées avec elle, y compris celles enregistrées avant qu’elle ne soit extraite et qui peuvent être déchiffrées rétroactivement. Une STEK statique et non rotative transforme effectivement votre parc de proxies edge en oracle passif de déchiffrement pour tout adversaire patient et équipé d’un dispositif de capture.

L’incident GnuTLS 2020 avec clé zéro, la divulgation de clé non initialisée AWS 2021, les résultats du scan à grande échelle USENIX 2023 (incluant la faille AWS touchant 1.9% des serveurs du Top 100k), et les vulnérabilités de confusion de tickets virtuels en 2025 sur Apache, nginx, (Open)LiteSpeed, Caddy, et Fastly montrent collectivement que la mauvaise gestion des STEK n’est pas un cas limite. C’est le résultat prévisible de laisser la gestion du cycle de vie des clés aux configurations par défaut.

La voie d’ingénierie pratique est bien définie : stockage en mémoire uniquement, génération centralisée via CSPRNG, distribution pré-positionnée avec fenêtre de propagation, pile multi-voies en retrait adaptée à la durée de vie des tickets navigateur, signalisation atomique de rechargement, et surveillance continue de l’entropie. Ajoutez l’application de psk_dhe_ke pour TLS 1.3 afin de restaurer la confidentialité future pour la reprise standard, restreignez le 0-RTT aux méthodes idempotentes ou désactivez-le sur les routes sensibles, isolez la portée de la STEK par hôte virtuel lorsque mTLS contrôle l’accès, et instrumentez vos compteurs d’échec de reprise pour une alerte en temps réel.

La fenêtre de rotation — période durant laquelle une STEK est active et une compromission future pourrait déverrouiller le trafic historique — est l’exposition quantifiable que contrôlent les rotations automatisées. Chaque heure sans incident d’une clé en rotation est une heure de trafic confidentiel, peu importe ce qui arrive à l’infrastructure en aval.

---

Références

Aviram, N., Gellert, K., & Jager, T. (2021). Protocoles de reprise de session et sécurité avancée pour TLS 1.3 0-RTT. Journal of Cryptology, 34(3). https://doi.org/10.1007/s00145-021-09385-0

AWS Security. (2021, 26 avril). Résolu : problème de ticket de session Application Load Balancer (AWS-2021-002). https://aws.amazon.com/security/security-bulletins/AWS-2021-002

Hebrok, S., Nachtigall, S., Maehren, M., Erinola, N., Merget, R., Somorovsky, J., & Schwenk, J. (2023). Il faut vraiment qu’on parle des tickets de session : analyse à grande échelle des dangers cryptographiques avec TLS Session Tickets. 32e USENIX Security Symposium, 4877–4894. https://www.usenix.org/conference/usenixsecurity23/presentation/hebrok

Hebrok, S., Storm, T. L., Cramer, F. M., Radoy, M., & Somorovsky, J. (2025). STEK Sharing is Not Caring : Contournement de l’authentification TLS dans les serveurs web via les tickets de session. 34e USENIX Security Symposium. https://www.usenix.org/conference/usenixsecurity25/presentation/hebrok

Klute, F. (2020). CVE-2020-13777 : GnuTLS utilise une STEK tout-zéro lors de la première rotation. https://gitlab.com/gnutls/gnutls/-/issues/1011

NVD. (2025). CVE-2025-23419 : Contournement de l’authentification client nginx via reprise de session TLS. https://nvd.nist.gov/vuln/detail/CVE-2025-23419

NVD. (2025). CVE-2025-23048 : Contournement de l’authentification client Apache via reprise de session TLS. https://nvd.nist.gov/vuln/detail/CVE-2025-23048

Rescorla, E. (2018). Le protocole TLS version 1.3 (RFC 8446). IETF. https://www.rfc-editor.org/rfc/rfc8446