TLS session resumption: cos’è e perché è critica per le performance

Ogni connessione HTTPS richiede un handshake TLS prima che client e server possano scambiarsi dati cifrati. In un handshake completo, questo processo aggiunge uno o due round trip (RTT) alla latenza — un costo non trascurabile quando si misurano TTFB e Core Web Vitals su reti ad alta latenza.

TLS session resumption è il meccanismo che permette di saltare (o abbreviare) l’handshake nelle connessioni successive verso lo stesso server, riutilizzando parametri crittografici negoziati in precedenza. Il risultato è una riduzione della latenza fino al 50-100% sull’handshake, con impatto diretto su TTFB, LCP e crawl efficiency.

Questo articolo copre in profondità i meccanismi di session resumption in TLS 1.2 e TLS 1.3, le implicazioni di sicurezza (incluse le CVE critiche del 2025), le configurazioni server ottimali, l’interazione con QUIC/HTTP/3 e l’impatto sulle performance web misurabili.

Full TLS handshake: il costo da eliminare

Prima di parlare di resumption, è necessario comprendere cosa accade durante un handshake TLS completo — il processo che la session resumption mira a evitare.

Handshake TLS 1.2 (2-RTT)

Un full handshake TLS 1.2 richiede lo scambio di quattro messaggi principali, distribuiti su due round trip aggiuntivi rispetto alla connessione TCP:

ClientHello — il client invia le cipher suite supportate, la versione TLS e un valore random
ServerHello + Certificate + ServerKeyExchange — il server seleziona la cipher suite, invia il certificato e i parametri per lo scambio di chiavi (Diffie-Hellman o ECDHE)
ClientKeyExchange + ChangeCipherSpec + Finished — il client completa lo scambio di chiavi e conferma
ChangeCipherSpec + Finished — il server conferma e la connessione cifrata è attiva

Con una latenza di rete di 50 ms per tratta, il solo handshake TLS aggiunge 200 ms prima che il primo byte di dati applicativi possa transitare. Sommando il TCP three-way handshake (1 RTT aggiuntivo), il costo totale sale a 300 ms.

Handshake TLS 1.3 (1-RTT)

TLS 1.3 (RFC 8446) ha ridotto il full handshake a un singolo round trip. La differenza architetturale chiave: il client invia le proprie key share già nel ClientHello, eliminando un intero RTT.

ClientHello + Key Share — il client propone cipher suite e invia direttamente i parametri (EC)DHE
ServerHello + EncryptedExtensions + Certificate + Finished — il server risponde con tutto il necessario in un singolo messaggio, già cifrato dal secondo messaggio in poi

Con la stessa latenza di 50 ms, il full handshake TLS 1.3 aggiunge solo 100 ms — la metà di TLS 1.2. Ma anche 100 ms sono significativi, specialmente su reti mobili dove la latenza base può superare i 150 ms.

Session resumption in TLS 1.2: Session ID e Session Ticket

TLS 1.2 offre due meccanismi distinti per la session resumption, entrambi con limiti significativi.

Session ID (RFC 5246)

Il meccanismo più semplice: durante il primo handshake, il server assegna un Session ID di 32 byte e memorizza lo stato della sessione (master secret, cipher suite negoziata) in una cache server-side.

Quando il client si riconnette, presenta il Session ID nel ClientHello. Se il server lo trova nella propria cache, l’handshake viene abbreviato a un singolo RTT — saltando lo scambio di certificati e la crittografia asimmetrica.

Limite critico: il Session ID richiede che lo stesso server gestisca la riconnessione. In un’architettura con load balancer, se la richiesta finisce su un nodo diverso, la cache non contiene il Session ID e si ricade in un full handshake. Soluzioni come la sticky session affinity esistono ma compromettono la distribuzione del carico.

Session Ticket (RFC 5077)

I Session Ticket risolvono il problema dello stato server-side: il server cifra l’intero stato della sessione con una Session Ticket Encryption Key (STEK) e lo invia al client come blob opaco. Il client lo memorizza e lo ripresenta nelle connessioni successive. Il server decifra il ticket, recupera lo stato e procede con l’abbreviated handshake.

Limite critico: la compromissione della STEK permette la decifratura retroattiva di tutte le sessioni resumpte con quella chiave, rompendo la forward secrecy. Inoltre, in un cluster, tutti i nodi devono condividere la stessa STEK — un requisito che introduce complessità operativa e rischi di sicurezza documentati.

Entrambi i meccanismi TLS 1.2 producono un abbreviated handshake a 1-RTT, senza possibilità di 0-RTT. Nessuno dei due garantisce forward secrecy sulla sessione resumpta.

Session resumption in TLS 1.3: PSK e 0-RTT

TLS 1.3 ha unificato e sostituito entrambi i meccanismi di TLS 1.2 con un sistema basato su Pre-Shared Key (PSK), architetturalmente diverso e più flessibile.

Come funziona il PSK in TLS 1.3

Dopo il completamento di un handshake TLS 1.3, il server invia uno o più messaggi NewSessionTicket come post-handshake message — non durante l’handshake come in TLS 1.2. Ogni ticket contiene un blob cifrato con lo stato della sessione.

Alla riconnessione, il client include l’identità PSK (il ticket) nel ClientHello insieme a PSK binder — valori HMAC calcolati sul transcript corrente usando una chiave derivata dal PSK. Questi binder incorporano transitivamente il transcript dell’handshake originale, prevenendo attacchi di ticket transplant.

Differenze chiave rispetto a TLS 1.2:

Ticket post-handshake — il client deve attendere il completamento dell’handshake per ricevere un ticket riutilizzabile
Ticket multipli — il server può emettere più ticket per connessione, migliorando privacy e riducendo la linkability tra sessioni
Forward secrecy opzionale — il PSK può essere combinato con un nuovo scambio (EC)DHE (modalità PSK+DHE), garantendo forward secrecy anche sulla sessione resumpta

Modalità PSK-only vs PSK+(EC)DHE

TLS 1.3 offre due modalità di utilizzo del PSK:

PSK-only — la sessione resumpta usa solo la pre-shared key per la derivazione delle chiavi. Più veloce, ma senza forward secrecy: la compromissione del PSK permette la decifratura di tutte le sessioni resumpte con quella chiave
PSK+(EC)DHE — le parti eseguono un nuovo scambio Diffie-Hellman alla riconnessione. Garantisce forward secrecy piena sulla sessione resumpta. È la modalità raccomandata da RFC 9325

0-RTT Early Data: latenza zero, rischio replay

La feature più aggressiva di TLS 1.3: il 0-RTT permette al client di inviare dati applicativi cifrati già nel primo messaggio (ClientHello), prima di ricevere qualsiasi risposta dal server. La chiave di cifratura per questi early data è derivata esclusivamente dal PSK della sessione precedente.

Il flusso 0-RTT:

Il client invia ClientHello con PSK identity, binder e early data cifrati
Il server valida il PSK, decifra e processa gli early data immediatamente
Il server risponde con ServerHello, completando l’handshake
Entrambe le parti passano alle chiavi di sessione complete derivate dal nuovo handshake

Il problema fondamentale del 0-RTT è la vulnerabilità al replay. Un attaccante on-path può catturare un pacchetto 0-RTT e ritrasmetterlo al server. Se gli early data contengono operazioni non idempotenti (un POST di pagamento, ad esempio), il replay potrebbe causare duplicazione dello stato. In una finestra di 500 ms, un attaccante può inviare decine di migliaia di replay.

Nota: gli early data 0-RTT non godono di forward secrecy — sono protetti solo dal PSK, che può essere long-lived (ore o giorni). Per questo motivo, il 0-RTT deve essere limitato esclusivamente a metodi HTTP idempotenti e sicuri (GET, HEAD, OPTIONS).

Meccanismi anti-replay definiti da RFC 8446

RFC 8446 definisce tre approcci per mitigare il rischio replay sui dati 0-RTT:

Single-use ticket — il server invalida il ticket dopo il primo utilizzo. Richiede sincronizzazione globale in ambienti distribuiti: tutti i nodi devono concordare su quali ticket sono stati consumati
Strike register — una struttura dati server-side che registra tutti i ClientHello 0-RTT osservati entro una finestra temporale, rifiutando i duplicati
Freshness check — il server usa il campo obfuscated_ticket_age per verificare che il tempo trascorso sia coerente con le aspettative, rifiutando 0-RTT con timestamp anomali

Confronto tra i meccanismi di session resumption

Caratteristica	TLS 1.2 Session ID	TLS 1.2 Session Ticket	TLS 1.3 PSK
Stato server-side	Obbligatorio (cache)	Non richiesto	Opzionale
Consegna ticket	Durante handshake	Durante handshake	Post-handshake
Ticket multipli	No	No	Sì
Supporto 0-RTT	No	No	Sì
Forward secrecy su resume	No	No	Sì (modalità PSK+DHE)
Full handshake RTT	2-RTT	2-RTT	1-RTT
Resumed handshake RTT	1-RTT	1-RTT	1-RTT (o 0-RTT)
Scalabilità cluster	Bassa (sticky session)	Media (STEK condivisa)	Alta (STEK + ticket multipli)

Sicurezza: STEK, CVE 2025 e rischi operativi

La gestione delle Session Ticket Encryption Key (STEK) è il punto debole operativo della session resumption, sia in TLS 1.2 che in TLS 1.3. Ricerche recenti hanno rivelato vulnerabilità sistemiche su larga scala.

STEK: il tallone d’Achille

Un paper USENIX Security 2023 (“We Really Need to Talk About Session Tickets”) ha analizzato l’implementazione delle STEK sui principali web server, scoprendo che oltre l’1.9% dei domini nel Tranco top 100k aveva implementazioni vulnerabili. In particolare, 1.903 server AWS Application Load Balancer utilizzavano una STEK composta interamente da zeri a causa di un bug nella rotazione delle chiavi. Il provider Stackpath presentava lo stesso problema su 20 host.

Un follow-up del 2025 (“STEK Sharing is Not Caring”, USENIX Security 2025) ha dimostrato che la condivisione di STEK tra virtual host consente bypass dell’autenticazione client e server in Apache, Nginx, LiteSpeed e Caddy. Sei cluster di provider, tra cui Fastly, risultavano vulnerabili.

CVE critiche del 2025

Il 2025 ha visto tre CVE direttamente legate alla session resumption TLS:

CVE-2025-23048 — Apache HTTP Server (critica)

Riguarda Apache 2.4.35–2.4.63. La session resumption TLS 1.3 tra virtual host con direttive SSLCACertificateFile diverse permette a un client autenticato per un virtual host di accedere a un altro virtual host tramite resumption, bypassando l’autenticazione del certificato client. Fix: aggiornamento ad Apache 2.4.64 o abilitazione di SSLStrictSNIVHostCheck.

CVE-2025-23419 — Nginx (CVSS 4.3)

Riguarda Nginx 1.11.4–1.26.2 e 1.27.0–1.27.3. Session resumption via ticket o session cache consente bypass dell’autenticazione certificato client quando più virtual host condividono lo stesso IP:porta. Fix: aggiornamento a Nginx 1.27.4 / 1.26.3.

CVE-2025-68121 — Go crypto/tls (CVSS 10.0)

Riguarda Go stdlib fino alla v1.25.4. Se i campi ClientCAs o RootCAs vengono modificati tra l’handshake iniziale e quello resumpto, la sessione resumpta può avere successo quando dovrebbe fallire. Fix: aggiornamento alla versione Go corretta.

Best practice per la gestione delle STEK

Rotazione frequente — ogni 1-12 ore (Cloudflare ruota ogni ora)
Storage in memoria — le STEK non devono mai essere persistite su disco o swap; usare tmpfs o equivalenti
Chiavi multiple attive — mantenere sempre almeno 2-3 chiavi (corrente + precedenti) per rotazione senza interruzioni
Distribuzione sicura — in ambienti cluster, distribuire le STEK su canale cifrato (Redis con TLS, secret manager)
Isolamento per virtual host — alla luce delle CVE 2025, evitare di condividere STEK tra virtual host con requisiti di autenticazione diversi

Impatto sulle performance: TTFB, LCP e crawl efficiency

L’handshake TLS è un componente diretto del Time to First Byte (TTFB). La session resumption riduce questo componente in modo misurabile.

Riduzione della latenza per scenario

Scenario	RTT totali (TCP + TLS)	Latenza aggiunta (100ms RTT)
TCP + TLS 1.2 full handshake	3 RTT	300 ms
TCP + TLS 1.3 full handshake	2 RTT	200 ms
TCP + TLS 1.3 resumed (1-RTT)	2 RTT	200 ms (cripto più leggera)
TCP + TLS 1.3 con 0-RTT	1 RTT	100 ms (dati nel primo flight)
QUIC full handshake	1 RTT	100 ms
QUIC con 0-RTT	0 RTT	~0 ms aggiuntivi

Impatto su Core Web Vitals

La riduzione del TTFB si propaga direttamente sul Largest Contentful Paint (LCP): un TTFB più basso significa che il documento HTML arriva prima, e con esso le risorse critiche (CSS, font, immagini above-the-fold). I dati Cloudflare mostrano che circa il 40% delle connessioni HTTPS sulla loro rete sono session resumption — con 0-RTT abilitato, un intero round trip viene eliminato per questa quota.

Su reti mobili, dove la latenza base è tipicamente 100-200 ms, l’impatto è amplificato: la session resumption con 0-RTT produce miglioramenti del TTFB nell’ordine del 20-40%.

Il benchmark Google per un TTFB “good” è sotto gli 800 ms, ma per ottenere un LCP sotto i 2.5 secondi è necessario puntare a un TTFB sotto i 200 ms. La session resumption contribuisce direttamente a raggiungere questo obiettivo.

Crawl efficiency e Googlebot

Anche Googlebot beneficia di connessioni TLS più veloci durante il crawling. Un handshake più rapido significa che il crawler può stabilire connessioni e recuperare pagine con meno overhead, portando a un utilizzo più efficiente del crawl budget. Per siti con decine di migliaia di URL, l’ottimizzazione cumulativa della session resumption è rilevante.

Configurazione server: Nginx, Apache e CDN

Nginx

server {
    listen 443 ssl;

    # Protocolli: TLS 1.2 per compatibilità, TLS 1.3 per performance
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher suite TLS 1.3
    ssl_conf_command Ciphersuites TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256;

    # Session cache per client TLS 1.2 (1 MB ≈ 4000 sessioni)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;

    # Session ticket (TLS 1.2; TLS 1.3 usa il proprio meccanismo)
    ssl_session_tickets on;

    # STEK custom per ambienti multi-server
    # Ruotare ogni 1-12 ore; la chiave più recente prima
    ssl_session_ticket_key /etc/nginx/tickets/current.key;
    ssl_session_ticket_key /etc/nginx/tickets/previous.key;

    # 0-RTT early data (solo TLS 1.3)
    ssl_early_data on;

    # Header per il backend: identifica richieste 0-RTT
    proxy_set_header Early-Data $ssl_early_data;
}

Nota: con ssl_session_tickets off, OpenSSL passa alla resumption stateful TLS 1.3 (cache server-side). Migliore per la forward secrecy, ma non scala su cluster senza stato condiviso. Dopo la CVE-2025-23419, verificare che ogni virtual host con autenticazione client usi una combinazione IP:porta unica, oppure aggiornare a Nginx 1.27.4+.

Apache

# Protocolli TLS
SSLProtocol -all +TLSv1.2 +TLSv1.3

# Session cache (shared memory circular buffer)
SSLSessionCache shmcb:/var/cache/mod_ssl/scache(512000)
SSLSessionCacheTimeout 3600

# Session ticket
SSLSessionTickets on

# Per ambienti multi-server con STEK condivisa
# SSLSessionTicketKeyFile /etc/httpd/ssl/ticket.key

Nota: Apache 2.4.35–2.4.63 è vulnerabile alla CVE-2025-23048. Aggiornare ad Apache 2.4.64 o abilitare SSLStrictSNIVHostCheck. La rotazione della STEK richiede un restart del server a meno di non usare un modulo custom.

CDN: Cloudflare, CloudFront e altri

Cloudflare — il 0-RTT è attivabile con un toggle nel dashboard (Speed > Optimization > Protocol). È automaticamente limitato a GET, HEAD, OPTIONS. Aggiunge l’header Early-Data: 1 alle richieste 0-RTT per l’origin. La rotazione STEK avviene ogni ora.

AWS CloudFront — la session resumption TLS 1.3 è abilitata automaticamente per le connessioni viewer. Nessuna configurazione aggiuntiva richiesta. Gli Application Load Balancer supportano sia Session ID che Session Ticket; i Network Load Balancer supportano solo i ticket.

In generale, terminare TLS a livello CDN è la soluzione che offre il miglior rapporto complessità/beneficio: la gestione della session resumption (inclusa la sincronizzazione STEK tra edge node) è delegata al provider.

QUIC, HTTP/3 e session resumption

QUIC (RFC 9000) integra TLS 1.3 (RFC 9001) direttamente nel protocollo di trasporto, eliminando la separazione tra TCP e TLS. I messaggi dell’handshake TLS sono trasportati dentro CRYPTO frame nei pacchetti QUIC, non su un byte stream TCP.

Questa integrazione amplifica i benefici della session resumption:

Full handshake QUIC = 1 RTT — TCP+TLS richiederebbero 2 RTT per lo stesso risultato
0-RTT QUIC = 0 RTT effettivi — il client invia dati applicativi nel primo pacchetto, senza attendere né TCP handshake né TLS handshake
Connection migration — QUIC supporta la migrazione di connessione (cambio IP/porta), eliminando la necessità di nuovi handshake quando l’utente cambia rete
Nessun head-of-line blocking — il multiplexing per-stream di QUIC elimina il problema del TCP head-of-line blocking, che in TLS/TCP causa stalli quando un pacchetto viene perso

Durante il 0-RTT QUIC, il client invia un pacchetto Initial contenente il ClientHello con PSK e early data, che possono includere sia i parametri di trasporto QUIC sia richieste HTTP/3. I parametri di trasporto della sessione precedente vengono memorizzati insieme al session ticket TLS e riutilizzati durante la resumption.

Un draft IETF attivo (“Carefully Resume QUIC Session”) propone di preservare anche lo stato di congestion control e bandwidth estimation attraverso le resumption 0-RTT, permettendo un ramp-up ancora più veloce del throughput.

Architetture distribuite: load balancer, cluster e Kubernetes

La session resumption in ambienti distribuiti introduce il problema della sincronizzazione dello stato: se il client riceve un ticket dal nodo A e si riconnette al nodo B, il nodo B deve poter decifrare quel ticket.

Strategie di sincronizzazione STEK

STEK condivisa via Redis/Memcached — tutti i nodi recuperano la STEK corrente da uno store centralizzato. La rotazione è gestita centralmente e i nodi aggiornano atomicamente. Soluzione raccomandata per cluster di medie dimensioni
Distribuzione file STEK — lo stesso file STEK viene distribuito a tutti i nodi. Più semplice ma richiede un meccanismo di distribuzione sicuro e rotazione coordinata
Sticky session / session affinity — il load balancer instrada i client sempre verso lo stesso nodo (basato su IP, cookie o TLS Session ID). Evita il problema della sincronizzazione ma compromette il bilanciamento del carico
HSM (Hardware Security Module) — le STEK sono conservate in HSM (AWS CloudHSM, Azure Dedicated HSM). Massima sicurezza, massima complessità operativa

Load balancer: comportamento per tipo

Load Balancer	Session ID	Session Ticket	Note
AWS Classic LB	Sì	No	Legacy, in fase di dismissione
AWS Application LB	Sì	Sì	Supporto completo
AWS Network LB	No	Sì (regionale)	Solo ticket
F5 BIG-IP	Sì	Sì	Cache configurabile (default 262.144 entry)

Kubernetes e container

In ambienti Kubernetes, gli ingress controller (es. ingress-nginx) affrontano il problema della sincronizzazione STEK tra repliche del pod. La configurazione ssl-session-ticket-key di ingress-nginx ha problemi noti con TLS 1.3 (GitHub issue #14621). L’approccio consigliato è montare la STEK come Kubernetes Secret condiviso, gestito da un controller esterno di rotazione.

Per architetture cloud-native, la soluzione a minore complessità operativa resta la terminazione TLS a livello CDN, delegando interamente la gestione della session resumption al provider edge.

Deprecazione TLS 1.0/1.1 e futuro di TLS 1.2

TLS 1.0 e 1.1 sono stati formalmente deprecati il 30 ottobre 2025. Microsoft ha confermato la fine del supporto TLS 1.0/1.1 per Azure Storage dal 3 febbraio 2026.

TLS 1.2 non ha ancora una data di deprecazione formale, ma la direzione è chiara: alcuni provider propongono configurazioni TLS 1.3-only. In pratica, TLS 1.2 resta necessario per la compatibilità con client legacy (browser aziendali, dispositivi IoT, tool di automazione), ma la session resumption ottimale richiede TLS 1.3.

Verifica e test della session resumption

Per verificare che la session resumption sia attiva e funzionante, è possibile usare OpenSSL da riga di comando:

# Test session resumption TLS 1.3
openssl s_client -connect example.com:443 -tls1_3 -sess_out /tmp/sess.pem
openssl s_client -connect example.com:443 -tls1_3 -sess_in /tmp/sess.pem

# Nell'output, cercare:
# "Reused, TLSv1.3" = session resumption attiva
# "New, TLSv1.3" = full handshake (resumption fallita)

# Test 0-RTT early data
openssl s_client -connect example.com:443 -tls1_3 -sess_in /tmp/sess.pem -early_data /tmp/request.txt

Per un monitoraggio continuo, il tasso di session resumption (hit rate) è una metrica chiave: un valore target è superiore al 60%. Valori inferiori indicano problemi di configurazione (timeout troppo bassi, STEK non sincronizzate in cluster, session cache insufficiente).

Raccomandazioni operative

Abilitare TLS 1.3 con session resumption su tutti gli origin server e CDN edge. Usare la modalità PSK+(EC)DHE per garantire forward secrecy
Abilitare 0-RTT per risorse statiche e cacheable (solo GET/HEAD). Non abilitare 0-RTT per endpoint che gestiscono operazioni non idempotenti
Ruotare le STEK ogni 1-12 ore e non persistirle su disco. In ambienti cluster, centralizzare la distribuzione
Verificare le CVE 2025 — aggiornare Apache a 2.4.64+, Nginx a 1.27.4+, Go alle versioni corrette
Usare preconnect hint (<link rel="preconnect">) per origin critici di terze parti, anticipando l’handshake TLS
Preferire HTTP/2 o HTTP/3 per multiplexare le richieste su una singola connessione TLS, riducendo il numero totale di handshake necessari
Monitorare il session resumption hit rate e il TTFB nei dati CrUX e Search Console per verificare l’impatto reale
Per architetture con mTLS, valutare se disabilitare la session resumption per connessioni interne dove l’autenticazione per-connessione è critica (alla luce delle CVE 2025)