Il certificato è valido. L’identità no.

Ci siamo abituati a considerare il lucchetto del browser come una specie di certificato di buona condotta. La connessione è cifrata, il nome del sito è quello giusto, il certificato è accettato: possiamo procedere. È una semplificazione comoda. E, come spesso accade con le semplificazioni comode, nasconde proprio il punto in cui il sistema può rompersi.

All’inizio di ottobre 2026, alcuni attaccanti hanno preso il controllo di componenti dei registri nazionali dei domini .gh, .sl e .as. Non hanno violato i server di Google. Hanno agito su un livello precedente: l’infrastruttura che determina quali risposte DNS siano autorevoli per i domini di quelle estensioni. Modificando quelle risposte, sono riusciti a ottenere certificati HTTPS non autorizzati per alcuni domini di Google e di altre organizzazioni. La ricostruzione ufficiale del team Chrome lo dice senza giri di parole.

La notizia non è che la crittografia sia stata violata. È più interessante, e per chi progetta sistemi molto più scomoda: un controllo eseguito correttamente può restituire un risultato sbagliato quando la fonte su cui si basa non è più affidabile.

La firma è autentica. La premessa può essere falsa

Un certificato TLS lega un nome di dominio a una chiave pubblica attraverso la firma di una Certification Authority, o CA. Quando il browser verifica quella firma e completa la negoziazione crittografica, ha una ragione tecnica per fidarsi della chiave presentata. Ma questa verifica non dimostra che ogni passaggio precedente sia rimasto sotto il controllo del proprietario legittimo del dominio.

Per emettere un certificato di tipo Domain Validated, una CA deve verificare che il richiedente controlli il dominio. Esistono diversi metodi di validazione; alcuni dipendono da risposte DNS o da contenuti raggiungibili attraverso la risoluzione del nome. Se un attaccante può manipolare temporaneamente l’autorità DNS a monte, può presentare alla CA una prova di controllo apparentemente valida. Il certificato che ne risulta non è una firma contraffatta: può essere un certificato regolarmente emesso, ma non autorizzato dal titolare del dominio.

Questa distinzione conta. Dire che è stato “bucato HTTPS” fa scena, ma porta a cercare il difetto nel posto sbagliato. Il protocollo di cifratura non è il problema descritto da Google. Il problema è la catena delle premesse con cui si decide a chi consegnare un’identità digitale.

Il punto di rottura non era il sito

I registri dei domini nazionali gestiscono una parte della gerarchia DNS. Chi riesce a intervenire su quel livello può alterare la delega o le informazioni autorevoli per nomi appartenenti all’estensione interessata. È un tipo di dipendenza che normalmente resta invisibile a chi gestisce un’applicazione: il team può avere patch aggiornate, server ben configurati e credenziali protette, ma la risoluzione del suo nome pubblico dipende anche da soggetti esterni.

Secondo Google, le CA coinvolte non risultano aver operato in modo scorretto e l’infrastruttura interna di Google non è stata compromessa. Sono due dettagli fondamentali. Eliminano le spiegazioni più facili e lasciano in piedi quella più utile: il processo di validazione ha preso per buona un’informazione che arrivava da un livello temporaneamente controllato da altri.

È lo stesso problema architetturale che torna in molti sistemi: un controllo può essere impeccabile rispetto alle sue regole e comunque fallire rispetto all’obiettivo. Ne avevo discusso da un’altra prospettiva parlando di confini di fiducia e sicurezza nelle applicazioni Django. Cambia la scala, non il principio: prima di fidarsi di una risposta bisogna sapere chi ha davvero autorità per produrla.

Perché il browser non basta

Chrome ha reagito bloccando i certificati non autorizzati identificati tramite CRLSets e collaborando con le CA per revocarli. L’intervento riduce il rischio per gli utenti, ma non trasforma il browser in un sistema onnisciente. Google stessa avverte che non è possibile garantire di aver individuato ogni dominio coinvolto e che una protezione applicata a Chrome non equivale a una copertura uniforme di tutti i client.

Inoltre, la revoca e il blocco non sono la stessa cosa. Una revoca comunica che un certificato non deve più essere considerato attendibile; la sua efficacia concreta dipende dal comportamento dei client e dai meccanismi con cui recepiscono l’informazione. Un blocco distribuito direttamente dal browser può intervenire più rapidamente su un insieme noto di certificati. Sono livelli diversi della risposta, non due nomi per la stessa operazione.

Non abbiamo elementi, nella comunicazione primaria, per attribuire l’attacco a un gruppo specifico, stabilire quante persone siano state effettivamente intercettate o descrivere un furto di dati accertato. Un certificato non autorizzato rende possibile l’impersonificazione in determinate condizioni; non prova da solo che ogni possibilità sia stata sfruttata. La precisione, in sicurezza, serve soprattutto quando rovina un titolo sensazionalistico.

Certificate Transparency: vedere non significa impedire

La prima misura indicata da Google è il monitoraggio continuo dei log di Certificate Transparency. L’emissione dei certificati pubblicamente attendibili lascia tracce consultabili: questo consente a un’organizzazione di accorgersi che qualcuno ha ottenuto un certificato per un proprio nome senza autorizzazione.

Ma un log non è una serratura. È un registro osservabile. Può rendere più rapido il rilevamento e aiutare la risposta all’incidente, non annullare automaticamente un certificato già emesso. Per questo il monitoraggio dovrebbe coprire l’intero portafoglio dei domini, inclusi quelli locali, regionali, secondari o apparentemente inutilizzati. Un dominio parcheggiato non smette di essere un pezzo della superficie di fiducia solo perché non compare più nella home del sito.

Qui emerge un problema molto aziendale, oltre che tecnico: chi possiede davvero l’inventario completo dei nomi digitali dell’organizzazione? Chi riceve gli avvisi? Chi decide se un’emissione è attesa? Se il controllo produce notifiche che nessuno prende in carico, abbiamo comprato visibilità, non sicurezza.

CAA è una regola utile, non una bacchetta magica

Il secondo livello consigliato riguarda i record DNS CAA, che indicano quali Certification Authority siano autorizzate a emettere certificati per un dominio. Una configurazione restrittiva può limitare la superficie di emissione e, dove supportato, vincolare l’autorizzazione anche ad account ACME o metodi di validazione specifici.

Il limite è importante: CAA non impedisce necessariamente l’emissione mentre il DNS è sotto il controllo dell’attaccante. Se il livello che fornisce le risposte è stato alterato, anche il controllo della policy può trovarsi davanti a dati manipolati. Google sottolinea invece il valore delle restrizioni dopo il ripristino del controllo DNS: possono impedire che verifiche di possesso precedentemente superate vengano riutilizzate per nuove emissioni.

È la differenza fra prevenzione, contenimento e recupero. Un’architettura matura non chiede a un solo meccanismo di fare tutti e tre i lavori. Lo stesso vale per altri sistemi nei quali una certificazione formale non coincide automaticamente con la sicurezza dell’insieme, come nel caso della compliance FIPS fra container e kernel.

Il controllo vero sta nei confini

Se gestissi la sicurezza di un portafoglio di domini, da questo caso ricaverei un metodo prima ancora di una checklist: distinguere il livello che afferma qualcosa dal livello che può garantirlo. Un certificato afferma una relazione fra nome e chiave. Una CA ne verifica il controllo secondo regole definite. Il DNS rende possibile quella verifica. Il registry partecipa all’autorità che rende attendibile il DNS. Ognuno svolge una funzione; nessuno rende automaticamente infallibili gli altri.

Operativamente questo significa conoscere tutti i domini gestiti, monitorare le nuove emissioni nei log pubblici, restringere le CA e gli account autorizzati quando possibile, prevedere una risposta rapida a cambi DNS inattesi e sapere quali client potrebbero non ricevere subito una protezione del browser. Non è un elenco di prodotti da comprare. È una distribuzione esplicita di responsabilità e verifiche.

Il problema non è quando un controllo fallisce. È quando passa, perché abbiamo dimenticato di controllare la fonte da cui prende la verità.

Il lucchetto resta utile. La cifratura resta indispensabile. Ma un’icona verde non può sostituire un modello di fiducia. Il caso dei registri .gh, .sl e .as ricorda che la sicurezza di un sistema non si misura soltanto dalla solidità dei componenti: si misura anche dalla qualità delle assunzioni che li collegano. Ed è quasi sempre lì che si nasconde il lavoro più difficile.