Da qualche versione, il browser Chrome protegge le connessioni sicure con un pezzo di crittografia nuovo, pensato per resistere ai futuri computer quantistici. È attivo per impostazione predefinita, quindi la maggior parte delle persone non deve fare nulla e non si accorge di niente. Per chi gestisce server e reti, però, c’è un dettaglio importante: questo cambiamento ha fatto emergere problemi latenti in alcuni apparati di rete mal implementati, con la conseguenza che qualche connessione smette di funzionare dopo l’aggiornamento del browser. Vale la pena capire cosa è cambiato, perché, e cosa conviene verificare.

La notizia in breve

Chrome ha abilitato di default, sui computer desktop, uno scambio di chiavi “ibrido” resistente ai computer quantistici a partire dalla versione 124, uscita nella primavera del 2024. Lo scambio di chiavi è il primo passo di ogni connessione sicura: il momento in cui il browser e il sito si mettono d’accordo su una chiave segreta condivisa, che poi serve a cifrare tutto il resto della conversazione. Tutto questo avviene dentro TLS, il protocollo che sta dietro all’https e al lucchetto che compare nella barra degli indirizzi.

La novità non richiede alcun intervento da parte dell’utente: se il sito la supporta, la connessione parte già protetta; se non la supporta, si usa il metodo di prima. Nessuno deve installare o configurare niente.

Contro quale minaccia: “raccogli ora, decifra dopo”

Per capire perché tutto questo serva bisogna partire da una minaccia dal nome poco rassicurante: harvest now, decrypt later, cioè “raccogli ora, decifra dopo”. L’idea è semplice e sgradevole. Oggi il traffico su Internet è cifrato: i dati che viaggiano tra il dispositivo e il sito sono resi illeggibili a chi li intercetta, e la protezione regge perché i computer attuali non hanno la potenza per forzarla in tempi ragionevoli.

I computer quantistici - una tecnologia ancora in sviluppo, basata su principi diversi da quelli dei computer tradizionali - potrebbero un giorno rompere buona parte della crittografia che usiamo adesso. Nessuno sa con certezza se e quando accadrà. Il problema, però, è già attuale: chi intercetta traffico cifrato oggi può registrarlo e archiviarlo, aspettando di poterlo decifrare in futuro. Dati che restano sensibili per molti anni - cartelle cliniche, segreti industriali, comunicazioni riservate - sono quindi a rischio già ora, anche se la macchina capace di aprirli non esiste ancora. Mettere in sicurezza lo scambio di chiavi serve proprio a togliere valore a questa raccolta preventiva.

Come funziona: uno scambio di chiavi ibrido

Nella pratica non si è buttata via la crittografia di prima per sostituirla con quella nuova. Si usa un approccio ibrido: si combinano un algoritmo classico, collaudato da anni, e uno post-quantum. La connessione resta protetta finché almeno uno dei due regge. Così, se in futuro si scoprisse una debolezza nell’algoritmo nuovo - cosa non impossibile, visto che è recente - resterebbe la protezione di quello tradizionale; e all’inverso, contro un attacco quantistico, protegge la parte nuova. In pratica, cintura e bretelle insieme.

Lo schema attivato da Chrome si chiama X25519Kyber768. Il nome è ostico, ma dice cosa contiene: X25519 è l’algoritmo classico usato da anni per lo scambio di chiavi, mentre Kyber768 è la parte post-quantum. Kyber, al momento dell’annuncio, era ancora una bozza dello standard poi pubblicato dall’ente statunitense NIST con il nome di ML-KEM, lo stesso ente che in seguito ha scelto HQC come algoritmo di riserva per non dipendere da un solo approccio matematico. Non è quindi l’esperimento di un singolo fornitore, ma un algoritmo su cui l’industria si sta allineando. Nelle versioni successive di Chrome lo schema è stato aggiornato alla versione definitiva dello standard.

L’effetto collaterale: il ClientHello diventa più grande

Ecco la parte che interessa direttamente i sistemisti. La chiave post-quantum occupa molto più spazio di quella classica. Questo gonfia il ClientHello, cioè il primo messaggio con cui il browser si presenta al server all’inizio della connessione. Nel messaggio il browser elenca cosa sa fare, comprese le chiavi che propone per lo scambio, la stessa busta che un’altra estensione recente, l’Encrypted Client Hello, prova a cifrare per nasconderne il contenuto a chi intercetta il traffico.

Con la parte post-quantum, questo primo messaggio diventa abbastanza grande da non entrare più in un singolo pacchetto di rete: viene quindi spezzato in due. Non è gratis: secondo l’annuncio di Google, la maggiore dimensione comporta un aumento di circa il 4% della latenza mediana su tutti gli handshake TLS di Chrome sul desktop. È un costo contenuto, ma reale, ed è una delle ragioni per cui il cambiamento è arrivato prima sul desktop, dove le connessioni sono in genere più veloci.

Perché alcuni apparati si rompono

Il costo in latenza è la parte prevista. Quella imprevista è che, con l’attivazione di default, sono venuti a galla difetti già presenti in diversi prodotti che stanno “in mezzo” alle connessioni. Nel gergo si chiamano middlebox: firewall, proxy, bilanciatori di carico e soprattutto i sistemi di ispezione TLS, cioè apparati che sbirciano o filtrano il traffico cifrato in transito, molto diffusi nelle reti aziendali.

In teoria un cambiamento del genere non dovrebbe rompere nulla. TLS è progettato per essere estensibile: se un apparato incontra un’opzione che non conosce, la regola è ignorarla e proseguire con quelle che conosce. Offrire lo scambio di chiavi post-quantum è quindi retrocompatibile, e i sistemi scritti a norma continuano a funzionare senza modifiche. Il problema è che non tutti sono scritti a norma. Alcuni apparati davano per scontato che il ClientHello fosse piccolo e arrivasse in un solo pacchetto, oppure gestivano male i messaggi di dimensioni inattese. Finché tutti i ClientHello erano piccoli, il difetto non si vedeva. Appena il messaggio è cresciuto e si è spezzato in due pacchetti, quegli apparati hanno iniziato a rifiutare o troncare la connessione.

Il punto da tenere a mente è questo: non è un difetto di Chrome, né della crittografia post-quantum. È un baco preesistente in un apparato di rete, che il cambiamento ha semplicemente reso visibile. Google ha confermato che il rilascio ha portato a galla diversi bug di questo tipo in prodotti di terze parti.

Cosa deve verificare chi gestisce i server

Il sintomo tipico è chiaro: dopo un aggiornamento di Chrome, alcuni utenti non riescono più a raggiungere un sito o un servizio, mentre con browser o versioni diverse tutto va. Se capita, conviene procedere così.

• Sospettare il percorso, non il browser. Il problema quasi sempre non è né il client né il server finale, ma qualcosa in mezzo: un proxy, un firewall con ispezione TLS, un bilanciatore, un apparato di sicurezza perimetrale.
• Isolare la causa. Chrome mette a disposizione una policy aziendale, PostQuantumKeyAgreementEnabled, che permette di disattivare temporaneamente lo scambio di chiavi post-quantum. Se disattivandola il problema sparisce, la diagnosi è confermata: c’è un apparato che non regge i ClientHello più grandi.
• Aggiornare l’apparato colpevole. La soluzione corretta è chiedere al fornitore una versione aggiornata che gestisca correttamente i messaggi grandi. La disattivazione via policy è pensata come rimedio temporaneo, per dare tempo di sistemare, non come stato definitivo.
• Non rimandare. Lo scambio di chiavi post-quantum non tornerà indietro, anzi diventerà la norma, tanto che oltre metà del traffico web globale è già cifrata in modo post-quantum. Un apparato che si rompe oggi con Chrome si romperà domani con gli altri browser e con i client aggiornati. Meglio sistemarlo adesso.

In sintesi

Per la maggior parte delle persone non c’è nulla da fare: basta tenere aggiornati browser e sistema operativo, e la protezione arriva da sola. Per chi gestisce infrastrutture il messaggio è duplice. Da un lato è una buona notizia, perché il traffico inizia a essere protetto contro una minaccia concreta anche se ancora futura. Dall’altro è un promemoria: gli apparati di rete che ispezionano o filtrano TLS vanno mantenuti aggiornati e conformi agli standard, perché ogni evoluzione del protocollo, dalla vita sempre più breve dei certificati alla crittografia dello scambio di chiavi, può far emergere scorciatoie prese in passato. Questa è la prima onda, non l’ultima.

Fonti

• Advancing our amazing bet on asymmetric cryptography - Chromium Blog
• PostQuantumKeyAgreementEnabled - Chrome Enterprise policy