TLS 1.3: 0-RTT, dati anticipati e ripresa della sessione

TLS 1.3 (RFC 8446, 2018) ha riprogettato l'handshake TLS per ridurre la latenza e rimuovere i residui delle versioni precedenti. Un handshake TLS 1.3 completo si conclude in 1-RTT: il client invia ClientHello con i key_shares supportati (chiavi pubbliche ECDH effimere) nel primo scambio; il server risponde con ServerHello, il proprio key_share, le estensioni crittografate, il certificato e Finished, tutto in un'unica risposta. Il client invia il proprio Finished e può trasmettere immediatamente i dati applicativi. Rispetto all'handshake TLS 1.2 in 2-RTT, questo dimezza il tempo di configurazione della connessione per le nuove sessioni.

TLS 1.3 utilizza HKDF (HMAC-based Key Derivation Function) con una gerarchia strutturata per la derivazione delle chiavi. Dopo lo scambio di chiavi ECDHE, il segreto condiviso alimenta una gerarchia: Extract(early_secret, DHE) -> handshake_secret; quindi Extract(handshake_secret, 0) -> master_secret. Da questi valori, HKDF-Expand-Label deriva chiavi separate per il traffico di handshake del client e del server, il traffico applicativo e la ripresa della sessione. Questa netta separazione garantisce che la compromissione di un livello di chiavi non influisca sugli altri, con un miglioramento significativo rispetto alla derivazione delle chiavi più ad hoc, basata su PRF, di TLS 1.2.

La ripresa della sessione in TLS 1.3 utilizza Pre-Shared Keys (PSK) derivate da sessioni precedenti. Dopo un handshake completato, il server invia un messaggio NewSessionTicket contenente un'identità PSK e un valore ticket (un blob cifrato che contiene il segreto per la ripresa). Alla riconnessione, il client include l'identità PSK in ClientHello. Se il server la riconosce, entrambe le parti derivano una nuova chiave di sessione dalla PSK e da un nuovo ECDHE, ottenendo una ripresa in 1-RTT con forward secrecy. Il ticket ha una durata configurabile (in genere 24 ore) e dovrebbe essere cifrato con una chiave lato server a rotazione.

TLS 1.3 consente di inviare dati anticipati 0-RTT nelle sessioni riprese. Il client utilizza la PSK di una sessione precedente per cifrare i dati applicativi, inviandoli nel primo scambio, prima che il server abbia fornito qualsiasi conferma. In questo modo elimina un round trip per le connessioni a server visitati in precedenza, offrendo una latenza prossima allo zero nelle connessioni ripetute. Il server pubblicizza il supporto per 0-RTT in NewSessionTicket tramite l'estensione early_data con un max_early_data_size. Il server deve disporre di un meccanismo per accettare o rifiutare i dati 0-RTT e segnala l'accettazione in EncryptedExtensions.

I dati 0-RTT presentano una limitazione di sicurezza fondamentale: sono vulnerabili agli attacchi di replay. Un aggressore che si trova sul percorso e cattura il primo scambio può riprodurlo verso il server, inducendolo a elaborare nuovamente i dati anticipati. Questo è intrinseco al meccanismo: il server non ha ancora inviato alcun messaggio, quindi non ha contribuito alcun elemento di freschezza. Mitigazioni: (1) Ticket monouso (il server invalida un ticket dopo il primo utilizzo, usando una cache distribuita come memcached/Redis). (2) Ticket con limite temporale (rifiutare 0-RTT dopo una breve finestra, ad esempio 5 secondi). (3) Idempotenza a livello applicativo (consentire 0-RTT solo per operazioni sicure equivalenti a GET).

Il meccanismo anti-replay più robusto per 0-RTT consiste nell'utilizzare ticket di sessione monouso. Il server mantiene un archivio dei ticket utilizzati, costituito da una cache distribuita nelle implementazioni con più server. Quando arrivano dati 0-RTT, il server verifica se il ticket è già stato visto: in caso affermativo, rifiuta i dati anticipati e ripiega su 1-RTT. In caso contrario, contrassegna il ticket come utilizzato ed elabora i dati anticipati. Per garantire la correttezza, tutti i server di un cluster devono condividere la cache dei ticket utilizzati. Redis con TTL brevi, corrispondenti alla durata dei ticket, è un'implementazione comune. Senza questo meccanismo, 0-RTT non è sicuro per operazioni non idempotenti come i pagamenti.

La ripresa tramite PSK in TLS 1.3 senza DHE non offre forward secrecy per la sessione ripresa: se la PSK viene compromessa in seguito, tutto il traffico della sessione ripresa può essere decifrato. Per mantenere la forward secrecy, TLS 1.3 supporta PSK-with-DHE: ClientHello include sia un'identità PSK sia un nuovo key_share. Il server combina la PSK con l'output ECDHE per derivare le chiavi di sessione. Anche se la PSK viene compromessa, il contributo ECDHE garantisce che il traffico passato rimanga protetto. RFC 8446 raccomanda PSK-with-DHE per tutti i casi di ripresa in cui è necessaria la forward secrecy.

TLS 1.2 aveva oltre 300 combinazioni di cipher suite, molte delle quali insicure. TLS 1.3 le riduce a 5 cipher suite, tutte basate su AEAD: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_AES_128_CCM_SHA256 e TLS_AES_128_CCM_8_SHA256. Lo scambio di chiavi e l'autenticazione vengono negoziati separatamente tramite le estensioni supported_groups e signature_algorithms. Questa separazione elimina la complessità combinatoria di TLS 1.2 e garantisce che ogni connessione TLS 1.3 utilizzi la crittografia autenticata.

Nella pratica, 0-RTT è particolarmente utile per le connessioni HTTP/2 in cui il client ripete una richiesta GET (sicura e idempotente) verso un server già visitato. I browser implementano 0-RTT con cautela: Chrome lo abilita per i metodi HTTP sicuri; le richieste POST non vengono mai inviate come dati 0-RTT. HTTP/3 su QUIC integra nativamente TLS 1.3: lo 0-RTT di QUIC riutilizza il meccanismo di TLS 1.3. In QUIC, 0-RTT ripristina anche i parametri di trasporto (controllo del flusso, limiti degli stream) della sessione precedente, riducendo ulteriormente il sovraccarico di configurazione oltre il solo livello TLS.

TLS 1.3 include meccanismi per prevenire gli attacchi di downgrade della versione. Il campo random di ServerHello contiene un valore sentinella quando viene negoziato TLS 1.3: gli ultimi 8 byte sono impostati su un valore fisso (0x44 0x4F 0x57 0x4E 0x47 0x52 0x44 01 per il fallback a TLS 1.2). I client compatibili con TLS 1.3 verificano la presenza di questo valore sentinella quando il server negozia TLS 1.2, rilevando i tentativi di downgrade attivo. Inoltre, l'hash della trascrizione di Finished copre l'intero handshake, inclusa la negoziazione della versione, rendendo rilevabile qualsiasi manomissione. SCSV (Signaling Cipher Suite Values) come TLS_FALLBACK_SCSV forniscono un segnale di downgrade separato per le versioni precedenti di TLS.

Il deployment di TLS 1.3 richiede attenzione a diversi aspetti operativi. Le chiavi di cifratura dei ticket di sessione devono ruotare (in genere ogni 24 ore) ed essere sincronizzate tra i cluster di server, per consentire la ripresa con qualsiasi server. Le vecchie chiavi di decifratura dei ticket devono essere conservate per tutta la durata dei ticket, così da evitare falsi errori di handshake. OCSP stapling è ancora più importante in TLS 1.3, perché elimina un ulteriore round trip per verificare lo stato del certificato. I load balancer devono inoltrare ClientHello di TLS 1.3 senza modificarlo: alcuni middlebox meno recenti danneggiano le estensioni sconosciute e richiedono modalità di compatibilità.

Perché i dati anticipati 0-RTT sono vulnerabili agli attacchi di replay in TLS 1.3?

TLS 1.3 consente handshake completi in 1-RTT e la ripresa in 0-RTT tramite ticket di sessione PSK. La derivazione delle chiavi utilizza HKDF con una gerarchia strutturata che produce chiavi separate per ogni livello di traffico. I dati anticipati 0-RTT eliminano un round trip, ma sono vulnerabili al replay: il rischio viene mitigato con ticket monouso e limitando 0-RTT alle operazioni idempotenti. PSK-with-DHE mantiene la forward secrecy durante la ripresa. TLS 1.3 limita le cipher suite a 5 opzioni AEAD, eliminando le combinazioni insicure delle versioni precedenti. La prevenzione del downgrade utilizza valori sentinella nel campo random del server.