Questo mese l’IETF ha pubblicato RFC 8446, la specifica di TLS 1.3: porta l’handshake completo da due round-trip a uno e fa della forward secrecy una proprietà non negoziabile della connessione. Il documento, curato da Eric Rescorla, chiude un lavoro del TLS Working Group cominciato nel 2014 e arrivato in pubblicazione dopo ventotto draft.

Contesto

Le versioni precedenti del protocollo si sono portate dietro un decennio di vulnerabilità che colpivano costruzioni ritenute corrette al momento della specifica: BEAST (2011) e Lucky Thirteen (2013) sui cifrari in modalità CBC, CRIME (2012) sulla compressione TLS, FREAK e Logjam (2015) sulle cipher suite export e sui parametri Diffie-Hellman deboli, DROWN (2016) sull’interazione con SSLv2 ancora attivo sugli stessi host, ROBOT (2017) sul padding RSA PKCS#1 v1.5. Quasi tutti questi attacchi hanno un filo comune che non è un errore di implementazione isolato: è la presenza, nello standard stesso, di costruzioni fragili che le implementazioni dovevano comunque tenere per interoperabilità.

TLS 1.2 (RFC 5246, 2008) scaricava sul deployment la scelta di una configurazione sicura tra molte combinazioni possibili, parecchie delle quali insicure. Una cipher suite come TLS_RSA_WITH_AES_128_CBC_SHA resta valida secondo lo standard pur usando scambio chiavi RSA senza forward secrecy e un cifrario CBC con MAC-then-encrypt. La superficie di configurazione era essa stessa il problema.

Cosa toglie la specifica

RFC 8446 elimina dallo standard — non solo dalle raccomandazioni di deployment — un insieme di costruzioni:

  • scambio chiavi RSA statico e Diffie-Hellman statico, privi di forward secrecy;
  • tutti i cifrari in modalità CBC e MAC-then-encrypt;
  • RC4, 3DES, MD5 e SHA-1 come primitive negoziabili;
  • la compressione a livello TLS;
  • la rinegoziazione e i ChangeCipherSpec con valore semantico (restano solo come byte di compatibilità per gli intermediari);
  • le cipher suite “export” e i gruppi Diffie-Hellman con parametri arbitrari forniti dal server.

Ne segue che ogni cipher suite ammessa dalla specifica usa uno scambio chiavi effimero (ECDHE o DHE) e un cifrario AEAD. Lo spazio delle cipher suite scende da diverse decine a cinque voci registrate, tre delle quali obbligatorie da implementare: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256. Nella nomenclatura 1.3 la suite identifica solo cifrario AEAD e funzione di hash; scambio chiavi e schema di firma si negoziano a parte.

Architettura dell’handshake

La differenza si vede nella prima coppia di messaggi. In TLS 1.2 il client manda ClientHello, riceve la scelta del server con i suoi parametri, poi in un secondo round-trip completa lo scambio chiavi: due round-trip prima di poter trasmettere dati applicativi. In TLS 1.3 il ClientHello porta già con sé, nell’estensione key_share, le chiavi pubbliche ECDHE per i gruppi che il client suppone il server accetti. Se l’ipotesi è giusta, il server risponde con ServerHello, la propria key_share, e da lì in poi tutto il resto dell’handshake — certificato, CertificateVerify, Finished — viaggia già cifrato. Il client chiude con il proprio Finished e può mandare dati applicativi: un round-trip.

Se il client sbaglia il gruppo, il server risponde con un HelloRetryRequest che chiede una key_share per un gruppo accettabile, e l’handshake ricade a due round-trip. Da qui l’importanza dell’ordine con cui il client propone i gruppi.

Tutto ciò che segue ServerHello è cifrato sotto chiavi derivate dal segreto di handshake. Il certificato del server, che in TLS 1.2 passava in chiaro, in 1.3 non è più visibile a un intermediario passivo. Le chiavi si derivano con HKDF (RFC 5869) attraverso uno schema a stadi che tiene separati i segreti di handshake da quelli del traffico applicativo.

Punto critico: 0-RTT e replay

Un client che ha già stabilito una sessione può, in TLS 1.3, mandare dati applicativi nel primo pacchetto di una nuova connessione, prima che l’handshake sia concluso, usando una pre-shared key derivata dalla sessione precedente. È il cosiddetto 0-RTT.

La specifica dice a chiare lettere che i dati 0-RTT non hanno le stesse garanzie del resto della connessione: non hanno forward secrecy rispetto alla PSK e, soprattutto, sono esposti a replay. Un attaccante che cattura il primo flight può ritrasmetterlo, e il server, dentro il protocollo, non ha un meccanismo generale per riconoscerlo come duplicato. La Sezione 8 dell’RFC entra nelle contromisure — ticket a uso singolo, finestre temporali strette — ma nessuna è completa, e limitare il 0-RTT alle sole richieste idempotenti resta un compito dell’applicazione. In pratica: niente POST che modifica lo stato sul primo flight. Si abilita sapendo cosa si sta concedendo, e non come default ovunque.

Implicazioni operative

Per chi gestisce server l’aggiornamento dipende dalla libreria TLS sotto più che dal web server. OpenSSL ha integrato TLS 1.3 nel ramo 1.1.1, atteso a breve come primo rilascio long-term-support con il protocollo abilitato; nginx e Apache httpd lo ereditano una volta ricompilati o aggiornati contro quel ramo. NSS lo ha già nelle versioni recenti di Firefox, BoringSSL lo porta in Chrome. Lato server l’attivazione è di solito una riga di configurazione, ma la coda lunga sta nella catena degli intermediari: alcuni middlebox che ispezionano il traffico TLS spezzano le connessioni 1.3 perché non riconoscono la nuova struttura dei messaggi, ed è il motivo per cui l’handshake si tiene campi e ChangeCipherSpec fittizi che lo fanno somigliare a 1.2 sul filo.

Cambia anche l’osservabilità. Con il certificato cifrato e i contenuti già protetti dopo ServerHello, gli strumenti che ricavavano informazioni dal traffico in chiaro dell’handshake adesso vedono meno. Resta in chiaro il Server Name Indication nel ClientHello: l’host richiesto è ancora leggibile da un osservatore passivo, e cifrare quel campo è un lavoro a parte, ancora allo stadio di draft in IETF.

Limiti

La specifica non tocca il modello di fiducia fondato sulle Certificate Authority: la validazione del certificato resta quella di sempre, con Certificate Transparency (RFC 6962) come integrazione e non come sostituto. Non introduce primitive resistenti al calcolo quantistico — lo scambio resta ECDHE su curve classiche, e la standardizzazione post-quantum è un processo a sé, ancora aperto. Non risolve l’esposizione dell’SNI. E il 0-RTT, come sopra, sposta un problema di sicurezza dal protocollo all’applicazione invece di eliminarlo. Quello che la pubblicazione chiude è una categoria precisa di rischio: le configurazioni TLS insicure-ma-conformi, che con 1.3 smettono di essere rappresentabili.

Immagine di copertina: Diagramma a sequenza dell’handshake completo TLS 1.3: scambio di messaggi tra client e server (ClientHello, ServerHello, Certificate,… — diagramma di Fleshgrinder, pubblico dominio — https://commons.wikimedia.org/wiki/File:Full_TLS_1.3_Handshake.svg