Certificati HTTPS post-quantistici in Google Chrome: come i Merkle Tree Certificates stanno cambiando la sicurezza del web

Google Chrome si sta preparando a uno dei cambiamenti più importanti degli ultimi anni per la sicurezza HTTPS. Nel febbraio 2026, Google ha annunciato l’intenzione di introdurre un sistema di autenticazione dei siti web resistente agli attacchi quantistici, basato sui Merkle Tree Certificates (MTC), un nuovo approccio progettato per proteggere le connessioni web dalle future minacce legate al calcolo quantistico. A differenza dei certificati HTTPS tradizionali, che si affidano a catene di firme digitali, gli MTC combinano l’emissione dei certificati con registri pubblici verificabili e prove matematiche compatte. L’obiettivo è introdurre una protezione crittografica più robusta senza rallentare sensibilmente la navigazione. Google ha già avviato i test della tecnologia insieme a Cloudflare, mentre gli esperti del settore stanno sviluppando standard comuni per favorirne un’adozione più ampia. Comprendere questo cambiamento è importante perché riguarda il modo in cui i browser stabiliscono l’affidabilità delle connessioni, i siti web dimostrano la propria identità e la sicurezza di Internet potrebbe evolversi nei prossimi anni.

Perché Google Chrome sta preparando HTTPS all’arrivo dei computer quantistici

HTTPS protegge le informazioni scambiate tra un browser e un sito web. Quando un utente accede a un servizio bancario online, effettua acquisti su Internet o entra nel proprio account, il browser stabilisce una connessione crittografata utilizzando il protocollo Transport Layer Security (TLS). Un certificato HTTPS contribuisce a verificare che il server appartenga al sito richiesto e non a un malintenzionato che tenta di impersonarlo. Questi certificati vengono rilasciati da autorità di certificazione affidabili, chiamate Certificate Authorities (CA), che verificano il controllo dei nomi di dominio prima di emettere le relative credenziali. Chrome controlla queste informazioni durante la creazione della connessione sicura, contribuendo a impedire che server non autorizzati si presentino come siti legittimi.

Il problema è che gran parte dell’attuale infrastruttura dei certificati dipende da sistemi di crittografia a chiave pubblica che computer quantistici sufficientemente potenti potrebbero compromettere in futuro. RSA e la crittografia a curve ellittiche sono particolarmente rilevanti perché un computer quantistico dotato delle capacità necessarie potrebbe utilizzare l’algoritmo di Shor per attaccare i problemi matematici su cui si basa la loro sicurezza. Al momento non risulta che esista un computer quantistico capace di violare concretamente le chiavi crittografiche utilizzate su larga scala in Internet. Tuttavia, modificare i sistemi di sicurezza impiegati da miliardi di dispositivi richiede anni. Attendere il primo attacco quantistico riuscito lascerebbe quindi pochissimo tempo per una transizione sicura. Per questo Google considera la crittografia post-quantistica una componente importante della propria strategia di sicurezza a lungo termine.

Nel marzo 2026, Google ha pubblicato un obiettivo più ampio, fissato al 2029, per portare avanti la migrazione verso la crittografia post-quantistica. Il programma dedicato ai certificati di Chrome rientra in questo percorso, anche se le singole fasi di implementazione seguono calendari e requisiti tecnici specifici. La difficoltà non consiste semplicemente nel sostituire un algoritmo con un altro. I browser devono continuare a riconoscere i siti legittimi, le autorità di certificazione devono adeguare le proprie infrastrutture e i servizi esistenti devono rimanere accessibili durante l’intera transizione. La soluzione proposta deve inoltre funzionare in modo efficiente sulle reti mobili e sui dispositivi meno potenti, dove messaggi di sicurezza più voluminosi possono aumentare i tempi di connessione e il consumo di dati.

Perché i certificati HTTPS tradizionali richiedono un nuovo approccio

I certificati HTTPS tradizionali utilizzano il formato X.509, che supporta l’autenticazione dei siti web da decenni. In genere, un sito presenta il proprio certificato insieme alle informazioni che lo collegano a un’autorità di certificazione attendibile. Il browser verifica le firme presenti in questa catena prima di accettare l’identità del server. Chrome richiede inoltre che i certificati pubblicamente attendibili rispettino i requisiti di Certificate Transparency, un meccanismo che aiuta a individuare i certificati emessi in modo errato o senza autorizzazione. Sebbene questo sistema sia ormai consolidato, comporta la presenza di firme aggiuntive e informazioni di supporto durante il processo di autenticazione.

Le firme digitali post-quantistiche sono considerevolmente più grandi rispetto a molte delle loro equivalenti tradizionali. Per esempio, l’algoritmo ML-DSA-44 standardizzato dal NIST utilizza firme di 2.420 byte, mentre quelle di ML-DSA-65 occupano 3.309 byte. Una firma Ed25519 tradizionale richiede soltanto 64 byte. Questi valori non rappresentano la dimensione complessiva di un certificato HTTPS, ma mostrano perché sostituire direttamente le firme esistenti potrebbe aumentare notevolmente la quantità di dati trasmessi durante l’autenticazione. Quando servono più firme per le catene di certificati e i registri di trasparenza, il traffico aggiuntivo diventa particolarmente significativo per i siti che gestiscono milioni di connessioni.

La soluzione proposta da Google consiste nel modificare il modo in cui viene dimostrata l’autenticità dei certificati, anziché limitarsi ad accettare file più grandi. Nell’annuncio del febbraio 2026, il team Chrome Secure Web Networking ha spiegato di non avere intenzione, nell’immediato, di aggiungere al Chrome Root Store pubblico i tradizionali certificati X.509 contenenti algoritmi crittografici post-quantistici. Google sta invece sviluppando i Merkle Tree Certificates insieme ai partner del settore. Questa tecnologia è progettata per supportare algoritmi più robusti, riducendo al tempo stesso la quantità di informazioni crittografiche ripetute durante le connessioni. I certificati HTTPS esistenti continueranno ad avere un ruolo importante durante la transizione e il nuovo approccio non significa che l’HTTPS tradizionale sia diventato improvvisamente insicuro.

Come i Merkle Tree Certificates cambiano l’autenticazione HTTPS

I Merkle Tree Certificates utilizzano un metodo diverso per dimostrare che un certificato è stato emesso da un’autorità attendibile. Anziché firmare separatamente ogni certificato e richiedere al browser di verificare una lunga catena di firme individuali, un’autorità può organizzare numerosi certificati emessi all’interno di un albero collegato crittograficamente. Successivamente firma una rappresentazione compatta dell’intero albero, nota come radice o tree head. Il sito web può quindi fornire una prova matematica che dimostra l’appartenenza del proprio certificato alla raccolta firmata. In questo modo è possibile autenticare i singoli certificati senza trasmettere ripetutamente tutte le grandi firme associate all’insieme dei documenti.

Un Merkle tree funziona calcolando gli hash crittografici dei singoli record e combinandoli attraverso livelli successivi, fino a ottenere un unico valore radice che rappresenta l’intera raccolta. Un hash è una breve impronta digitale calcolata a partire dai dati. La modifica di un record del certificato cambierebbe gli hash risultanti, impedendo alla relativa prova di inclusione di corrispondere alla radice attendibile dell’albero. Il browser non deve scaricare l’intero albero per controllare un certificato. Può invece verificare un insieme relativamente piccolo di hash adiacenti, sufficienti a dimostrare che il certificato appartiene alla raccolta autenticata.

La distinzione fondamentale è che i Merkle tree non sostituiscono direttamente la crittografia post-quantistica. Offrono piuttosto un metodo efficiente per organizzare e verificare informazioni autenticate tramite firme digitali. L’autorità di certificazione può firmare una radice condivisa dell’albero utilizzando un algoritmo resistente agli attacchi quantistici, distribuendo il costo dell’autenticazione tra numerosi certificati. Anche organizzazioni indipendenti, chiamate cosigner, possono verificare e firmare le rappresentazioni dell’albero, aggiungendo un ulteriore livello di controllo. Il sistema risultante combina autenticazione post-quantistica, prove di inclusione compatte e registri pubblicamente verificabili delle emissioni in un unico modello di certificazione.

Certificate Transparency e connessioni HTTPS più rapide

Certificate Transparency è un meccanismo di sicurezza consolidato che rende pubblicamente verificabile l’emissione dei certificati attendibili. Nel sistema tradizionale, i certificati vengono registrati in elenchi pubblici affinché i proprietari dei siti web, i ricercatori di sicurezza e i servizi di monitoraggio possano individuare eventuali emissioni sospette. I Merkle Tree Certificates integrano direttamente questo requisito nella propria struttura. Un certificato diventa parte dell’albero pubblico delle emissioni dell’autorità, collegando così la creazione di un certificato valido alla sua registrazione in una struttura verificabile. Questo riduce la separazione tra il rilascio del certificato e la documentazione della sua esistenza.

Il sistema proposto si affida anche a cosigner indipendenti e a organizzazioni che conservano copie dei registri di emissione. Il loro coinvolgimento aiuta a individuare informazioni incoerenti o tentativi di presentare versioni differenti di un registro dei certificati a osservatori diversi. Questo aspetto è importante perché un’autorità di certificazione non deve essere considerata affidabile soltanto per la sua capacità di produrre una firma digitale valida. La verifica pubblica e il monitoraggio indipendente offrono ulteriori garanzie contro errori, infrastrutture compromesse ed emissioni improprie di certificati. Questi meccanismi non eliminano ogni possibile abuso, ma rafforzano la responsabilità delle autorità e facilitano l’individuazione delle attività sospette.

Dal punto di vista delle prestazioni dei siti web, il principale vantaggio deriva dalla riduzione dei dati di autenticazione trasmessi ripetutamente. Google descrive due modalità di distribuzione degli MTC: certificati standalone e certificati landmark-relative. Gli MTC standalone mantengono le relative firme post-quantistiche durante l’autenticazione e offrono un approccio più semplice per la fase di transizione. Gli MTC landmark-relative possono invece evitare di trasmettere queste firme quando il browser dispone già di informazioni attendibili sull’albero firmato. In questo caso, il sito deve fornire soltanto una prova di inclusione compatta. I miglioramenti effettivi della velocità dipendono dal supporto del browser, dalle condizioni della rete, dalla configurazione dei certificati e dalle scelte di implementazione. Pertanto, gli MTC non devono essere interpretati come una garanzia che ogni sito web si caricherà più rapidamente.

Il lancio dei certificati post-quantistici in Google Chrome e i prossimi sviluppi

Nel corso del 2026, Google ha iniziato a testare i Merkle Tree Certificates insieme a Cloudflare, anche attraverso esperimenti che coinvolgono traffico Internet reale. Le prime verifiche di fattibilità servono a valutare se il metodo di autenticazione proposto possa funzionare in modo affidabile senza indebolire le protezioni esistenti. Durante questi esperimenti, le connessioni che utilizzano gli MTC sono supportate anche dai tradizionali certificati X.509 attendibili. Questo permette di mantenere un sistema alternativo mentre gli ingegneri analizzano compatibilità, prestazioni e comportamento della sicurezza. È una distinzione importante: il successo delle sperimentazioni dimostra un progresso tecnico, ma non significa che tutti gli utenti Chrome utilizzino già un’autenticazione dei siti completamente resistente agli attacchi quantistici.

Il piano di implementazione pubblicato da Google indica il primo trimestre del 2027 come periodo previsto per l’ingresso degli operatori qualificati dei registri Certificate Transparency nel programma pubblico iniziale degli MTC. Una fase successiva, prevista per il terzo trimestre del 2027, riguarda l’ampliamento del Chrome Quantum-resistant Root Store e il supporto di ulteriori autorità di certificazione. Queste date rappresentano gli obiettivi annunciati da Google e non impegni di rilascio incondizionati. Nell’ottobre 2026, Google ha inoltre pubblicato la versione 0.4.0 della bozza delle regole del Quantum-resistant Root Program, che descrive i requisiti per le autorità di certificazione, i mirror indipendenti, l’affidabilità operativa e la supervisione pubblica. Gli standard stessi rimangono in fase di sviluppo attivo presso l’Internet Engineering Task Force.

La strategia più ampia di Chrome suddivide l’autenticazione post-quantistica in quattro fasi. Inizialmente, il browser acquisisce nuove opzioni crittografiche, mantenendo i metodi esistenti. Le fasi successive introducono una protezione più robusta contro i tentativi di downgrade, rendono gradualmente obbligatorie le autorità di certificazione resistenti agli attacchi quantistici e, infine, puntano all’adozione di chiavi server anch’esse resistenti. Questa distinzione è importante perché il semplice supporto agli MTC non rende automaticamente ogni connessione HTTPS sicura contro i futuri computer quantistici. Finché rimangono disponibili metodi di autenticazione più deboli, senza restrizioni adeguate, un aggressore dotato di capacità sufficientemente avanzate potrebbe potenzialmente prendere di mira quelle alternative. La transizione deve quindi affrontare sia la robustezza crittografica sia le decisioni con cui il browser stabilisce quali identità considerare attendibili.

Cosa devono aspettarsi i proprietari dei siti web e gli utenti di Chrome

Per gli utenti comuni di Chrome, la transizione dovrebbe richiedere pochissimi interventi diretti. La verifica dei certificati avviene normalmente in modo automatico durante una connessione HTTPS e Google intende preservare questa esperienza di navigazione. Gli utenti dovrebbero continuare ad aggiornare Chrome, prestare attenzione agli avvisi di sicurezza del browser ed evitare i siti che presentano errori nei certificati. Non bisogna però presumere che la presenza di un lucchetto o di una connessione HTTPS dimostri l’onestà di un sito. HTTPS protegge la connessione e autentica l’identità del server secondo le regole di attendibilità del browser, ma non garantisce che un sito sia privo di truffe, download dannosi o contenuti ingannevoli.

I proprietari dei siti web dovrebbero seguire gli sviluppi comunicati dai rispettivi fornitori di hosting, dalle reti di distribuzione dei contenuti e dalle autorità di certificazione, anziché tentare di sostituire prematuramente i certificati esistenti. Quando i servizi MTC diventeranno disponibili, la loro adozione dovrebbe comportare aggiornamenti ai processi di emissione e rinnovo dei certificati, con un maggiore ricorso all’automazione. Le organizzazioni che utilizzano configurazioni TLS personalizzate, gateway di sicurezza interni o software meno recenti potrebbero avere bisogno di ulteriori verifiche di compatibilità. Le aziende che gestiscono informazioni sensibili dovrebbero inoltre esaminare dove viene utilizzata la crittografia all’interno dei propri servizi, perché l’autenticazione tramite certificati rappresenta soltanto una parte della preparazione alle minacce quantistiche. Lo scambio di chiavi post-quantistico, la firma del software, i sistemi interni e la protezione dei dati a lungo termine richiedono valutazioni separate.

I Merkle Tree Certificates rappresentano un cambiamento sostanziale nelle fondamenta della sicurezza dei browser, ma il loro successo dipenderà da un’implementazione attenta e da un’ampia collaborazione tra gli operatori del settore. Il coinvolgimento di Google, Cloudflare, Apple e altri contributori nella specifica IETF emergente dimostra che il lavoro va oltre una semplice funzionalità di un singolo browser. A novembre 2026, i principali risultati raggiunti comprendono uno standard tecnico in fase di sviluppo attivo, sperimentazioni in condizioni reali e un percorso più definito verso un’infrastruttura di certificazione resistente agli attacchi quantistici. Se la transizione procederà con successo, Chrome potrà verificare le identità dei siti web utilizzando una crittografia più robusta, senza introdurre un carico di autenticazione superfluo nella navigazione quotidiana. La priorità immediata rimane garantire connessioni HTTPS affidabili, preparando contemporaneamente il sistema di attendibilità sottostante ad affrontare i rischi futuri.