Effetto degli algoritmi post-quantistici sulle prestazioni di rete

Nei primi due articoli di questa serie ho trattato due iniziative chiave della crittografia post-quantistica: una per correggere lo scambio di chiavi e l'altra per correggere l'autenticazione. Anche se sono due problemi diversi, hanno un elemento in comune: entrambi i cambiamenti influenzeranno le prestazioni dei protocolli di rete cifrati.

Degli effetti dei cambiamenti nello scambio di chiavi si parla molto, ma Google ha osservato solo un piccolo aumento della latenza dell'handshake. Non sembra molto, ma conta su larga scala. C'è una preoccupazione ben più grande riguardo alla dimensione delle firme post-quantistiche, i cui effetti potrebbero essere molto peggiori a seconda dell'approccio scelto.

Per capire perché accade tutto ciò, dobbiamo prima capire i principi fondamentali della crittografia e poi come TLS li utilizza per garantire la sicurezza. In questo articolo entro nei dettagli dell'handshake TLS, evidenziando le parti relative allo scambio di chiavi e all'autenticazione, e l'effetto dei cambiamenti post-quantistici su questa parte cruciale della comunicazione cifrata.

A livello generale, quando parliamo di crittografia vogliamo soprattutto ciò che essa può offrire, di solito descritto secondo tre aspetti: riservatezza, autenticazione e integrità. Per ottenere queste proprietà combiniamo primitive crittografiche per progettare protocolli. In qualsiasi protocollo crittografico, gran parte della complessità risiede nell'handshake, che svolge grosso modo quanto segue:

• Concordare i parametri di crittografia comuni
• Autenticarsi, idealmente da entrambe le parti ma più spesso solo lato server
• Concordare le chiavi di crittografia (scambio di chiavi)
• Convalidare l'integrità dell'handshake per garantire che non ci siano state manomissioni

C'è molto lavoro dietro le quinte. I protocolli diffusi devono anche risolvere il problema dell'interoperabilità, ossia l'arte di far dialogare centinaia di strumenti e prodotti realizzati da produttori diversi, nonostante siano spesso implementati male, datati e talvolta obsoleti.

La parte di crittografia vera e propria è quasi noiosa rispetto all'handshake, soprattutto oggi che la cosiddetta crittografia autenticata è la norma. In pratica basta indicare quale algoritmo di crittografia si vuole usare e con quale chiave, fornire dei dati in ingresso e ottenere dei dati in uscita. Per prevenire attacchi come replay, riordino ed eliminazione dei dati, tutti i pacchetti di dati cifrati formano una catena immutabile e condividono un controllo di integrità comune e continuo.

Abbiamo già stabilito quanto siano complessi i protocolli crittografici. In TLS, un handshake è composto da diversi flight. All'interno di ciascun flight, numerosi messaggi del protocollo vengono inviati da una parte all'altra, praticamente in contemporanea. Ecco uno schema semplice (nella RFC trovate uno schema più dettagliato, se siete interessati):

1. Il client avvia l'handshake inviando un messaggio ClientHello.
2. Il server accetta la connessione, passa alla crittografia, invia il proprio certificato, dimostra di possedere la chiave privata corrispondente e infine completa l'handshake.
3. Il client convalida i dati del server e completa l'handshake dal proprio lato. Procede quindi a inviare i dati applicativi (ad esempio HTTP).
4. Il server completa l'handshake dal proprio lato e poi risponde ai dati applicativi.

Osservando l'handshake dal punto di vista della rete, si nota che ogni flight è composto da uno o più pacchetti di rete, a seconda della quantità di dati da inviare. Poiché i pacchetti impiegano del tempo per raggiungere l'altra estremità, e altrettanto la risposta per tornare indietro, c'è anche una buona dose di attesa tra i vari flight. Un handshake TLS completo richiede due round trip tra client e server. Ci torneremo più avanti.

Ogni handshake comporta quanto segue:

• Operazioni crittografiche sulla CPU
• Costruzione dei messaggi del protocollo
• Invio di byte sulla rete
• Attesa di una risposta dall'altra parte
• Elaborazione dei pacchetti ricevuti

Se volete saperne di più, consultate la RFC 9846 di TLS 1.3, recentemente aggiornata. Dopodiché avviate Wireshark e osservate gli handshake reali eseguiti dai browser e da altri strumenti.

Paghiamo la crittografia con un maggiore carico sulla CPU e con la latenza di rete. Per il primo aspetto, basta acquistare più CPU. Per il secondo, la latenza di rete rallenta i nostri siti web, il che si traduce in minori entrate.

Vediamo questi due aspetti più nel dettaglio:

• CPU: Agli albori della crittografia, le CPU erano molto più lente di oggi e rappresentavano un collo di bottiglia significativo. All'epoca era comune cifrare solo una parte del traffico. Fortunatamente oggi le cose vanno molto meglio e possiamo cifrare tutto. La crittografia ha un costo misurabile, ma non è elevato rispetto ai benefici.
• Latenza: Il vero costo della crittografia risiede nei round trip aggiuntivi che comporta. Per eseguire un handshake TCP serve un round trip. Si invia una richiesta, che attraversa la rete, poi si attende che la risposta torni indietro. Per eseguire un handshake TLS sopra una connessione TCP già aperta servono altri due round trip. Quindi, avviando una nuova connessione da Londra a New York, non si può evitare di attendere 3x90=270ms solo perché i pacchetti facciano avanti e indietro. QUIC, che si basa su UDP, può aprire una connessione in meno tempo, appena 180ms.

Per quanto riguarda la crittografia post-quantistica, che nel contesto di TLS oggi significa ML-KEM (per lo scambio di chiavi) e ML-DSA (autenticazione), le differenze nei requisiti di CPU non sono significativamente diverse.

Con la latenza di rete la situazione è completamente diversa, ed è ciò che rischia di influire negativamente sulle prestazioni imponendo condizioni che aumentano il numero di round trip necessari durante la fase iniziale dell'handshake. Questo può avvenire tramite uno dei due meccanismi seguenti:

• Assunzioni sui key share: In TLS 1.3, i client devono "indovinare" quali key share potrebbero essere supportati da un server. Storicamente, tutti i server TLS 1.3 supportavano X25519, quindi è ciò che tutti inviavano. Oggi i client moderni inviano X25519 oltre a X25519MLKEM768, e questo funziona la maggior parte delle volte. Quando non funziona, il server deve richiedere un nuovo tentativo del ClientHello, tramite un messaggio HelloRetryRequest. Questo messaggio contiene le informazioni sui metodi di scambio di chiavi supportati dal server. Se il server supporta un algoritmo corrispondente, può riprovare, ma questo processo aggiunge un ulteriore round trip.
• Slow start: All'inizio di una nuova connessione, le condizioni di rete non sono note, e i protocolli in genere partono lentamente, aumentando la velocità man mano che vengono scambiati più pacchetti. Questo approccio viene solitamente chiamato Slow Start in TCP, e ne esistono equivalenti in altri protocolli (ad esempio QUIC). La quantità di dati che può essere inviata inizialmente si chiama finestra di congestione iniziale. Il valore predefinito per i server oggi è di circa 14,5 KB, sebbene i CDN possano consentire valori maggiori, ad esempio 30-45 KB. In sostanza, una volta inviati tutti i dati consentiti, occorre attendere una risposta, il che aggiunge un ulteriore round trip.

È quindi la finestra di congestione iniziale a rappresentare il nuovo collo di bottiglia. Se ricordate il mio precedente articolo in cui ho discusso le dimensioni delle firme post-quantistiche, una transizione diretta dalle firme ECDSA a ML-DSA nei certificati e nei messaggi del protocollo potrebbe aggiungere da 14KB a 18KB all'handshake TLS, il che manderebbe completamente in tilt la finestra di congestione iniziale predefinita per la maggior parte dei server.

Sebbene sia sempre possibile aumentare la dimensione della finestra di congestione iniziale (ammesso che le nostre reti lo consentano), dobbiamo anche considerare che negoziare TLS non è fine a sé stesso: bisogna poi far girare sopra un protocollo applicativo. In pratica questo significa che, idealmente, si vuole consegnare in un solo colpo l'intera homepage del sito, così che il browser possa iniziare a elaborarla.

Oltre a far costare di più e rallentare le cose, cambiamenti così importanti spesso causano anche malfunzionamenti. È comunque un problema di cui dobbiamo occuparci per quanto riguarda le prestazioni di rete.

Come abbiamo visto, in TLS l'handshake inizia con un ClientHello. In questo messaggio, il client invia la propria richiesta al server e fornisce i parametri iniziali. Molto tempo fa, questo messaggio era piuttosto piccolo, addirittura sotto i 256 byte. Con l'aumentare della complessità di TLS negli anni, la dimensione del ClientHello è cresciuta, ma è rimasta entro la dimensione di un singolo pacchetto di rete. Di conseguenza, molto software è stato scritto partendo dal presupposto che l'intero ClientHello sarebbe sempre arrivato in un unico pacchetto.

Questo presupposto è saltato di recente quando abbiamo aggiornato lo scambio di chiavi in TLS per includere ML-KEM-768, che richiede altri 1.216 byte. Controllando un ClientHello reale poco fa, ho osservato che era di 2.117 byte nell'ultima versione di Chrome. Un valore ben oltre quanto può essere inviato tramite un singolo pacchetto (circa 1.440 byte di dati utili).

Di conseguenza, questi nuovi ClientHello di grandi dimensioni attraversano la rete come due segmenti TCP, e alcuni software e dispositivi non riescono a gestire la cosa, per vari motivi. Di solito si tratta dei famigerati middlebox, dispositivi progettati per ispezionare il traffico di rete.

TLS ha una lunga storia di problemi con i middlebox. Quasi ogni volta che è stata necessaria un'evoluzione del protocollo, i middlebox si sono messi di traverso. Questo ha portato infine alla nascita di GREASE, un metodo che inserisce dati fittizi casuali per impedire assunzioni su cosa possa o non possa comparire nei pacchetti TLS.

Anche senza incorrere in problemi con dispositivi intermedi, un ClientHello più grande significa inviare più dati e più pacchetti. Le comunicazioni sono più lente, e aumenta la probabilità di perdita di pacchetti, con conseguente possibile ritrasmissione. Questo è ciò che è stato segnalato da Google come un aumento mediano del 4% della latenza dell'handshake. Su desktop, peggio su cellulare.