Il lucchetto era valido, il sito era falso: i dirottamenti dei registri .gh, .sl e .as spiegati

Il 6 ottobre 2026, il team di sicurezza di Chrome in Google ha pubblicato un breve post dal titolo asciutto e dal contenuto allarmante: degli attaccanti avevano preso il controllo di tre registri di domini nazionali, il .gh del Ghana, il .sl della Sierra Leone e il .as delle Samoa Americane, modificato record DNS autoritativi e ottenuto certificati HTTPS validi per domini Google e per “diversi grandi marchi globali” che non ha nominato. Chiunque fosse finito su uno dei siti falsi avrebbe visto un lucchetto del browser senza nulla di strano.

L’incidente merita di essere capito a fondo, perché cade nel punto esatto in cui il modello mentale che la maggior parte delle persone ha della sicurezza del web è sbagliato. Il lucchetto non significa “questo è il sito vero”. Significa qualcosa di molto più stretto, e a fine settembre la distanza tra le due cose è diventata un attacco operativo.

Una definizione regge tutta questa pagina: un certificato a convalida di dominio prova una cosa sola, che al momento dell’emissione il richiedente controllava il DNS del dominio. Quando il registro sopra il DNS viene rubato, il ladro è, per ogni controllo automatico sulla terra, il proprietario.

Cosa è successo a .gh, .sl e .as?

Un registro nazionale è l’organizzazione che gestisce il database maestro di tutto ciò che vive sotto il suo dominio a due lettere: il .gh è operato da Network Computer Systems ad Accra, il .sl dalla società di telecomunicazioni Sierratel, il .as dall’AS Domain Registry. Comprometti quel database e non hai più bisogno di violare alcun singolo sito, perché puoi ridelegare qualsiasi nome sotto il TLD verso server che controlli tu.

È ciò che è accaduto, un registro alla volta. I certificati sono comparsi nei log pubblici per nomi .gh il 22 settembre, .sl il 25 settembre e .as il 27 settembre, il che si legge come una squadra che scorre una lista. Google dice che gli attaccanti hanno “modificato record DNS autoritativi e ottenuto certificati HTTPS non autorizzati che coprono diversi domini Google, oltre a domini appartenenti ad altre organizzazioni”, e che i suoi sistemi non sono stati toccati.

Una quantità notevole di cose resta non divulgata: come i registri siano stati violati, chi lo abbia fatto, se qualche certificato sia stato usato contro utenti reali, e l’elenco completo delle vittime. Nessuno dei tre operatori di registro aveva pubblicato un comunicato al momento in cui scriviamo. Noi diciamo “non divulgato” dove questo è lo stato delle cose, e dovrebbe farlo ogni resoconto che leggete.

Come hanno fatto gli attaccanti a ottenere certificati validi per domini Google?

Chiedendoli gentilmente. The Hacker News, lavorando sull’archivio pubblico di Certificate Transparency, ha contato almeno 12 certificati che coprono 7 domini Google e YouTube, tra cui google.com.gh, google.sl, google.as e varianti: 11 emessi da Let’s Encrypt e 1 da ZeroSSL, tutti a convalida di dominio. Un membro dello staff di Let’s Encrypt ha confermato l’emissione e le revoche sul forum del progetto.

Ecco la parte scomoda: le CA hanno seguito le proprie regole. Google stessa ha scritto di non avere “motivo di credere che le autorità di certificazione (CA) che hanno emesso i certificati coinvolti abbiano fatto qualcosa di sbagliato”. La convalida di dominio chiede al richiedente di dimostrare il controllo del DNS del dominio, tipicamente pubblicando un record. Gli attaccanti erano il DNS. Ogni controllo automatico che hanno affrontato lo hanno superato onestamente, nel senso stretto in cui le macchine intendono l’onestà.

Un dettaglio mostra che aspetto ha la vigilanza a questo livello: nei record dei log esaminati, risalendo almeno al 10 settembre, ogni altro certificato per google.com.gh, google.sl e google.as era venuto da Google Trust Services, la CA di Google stessa. Dodici certificati da due CA senza alcun legame erano di per sé l’anomalia, seduta in un log pubblico, in attesa che qualcuno guardasse.

Chi se n'è accorto, e come è stato fermato l'attacco?

Tre meccanismi, in ordine di velocità.

Primo, Certificate Transparency ha reso i certificati visibili, tanto per cominciare. Dal 30 aprile 2018 Chrome rifiuta qualsiasi certificato non divulgato nei log CT pubblici, così un attaccante che vuole un certificato funzionante nel browser più usato del mondo deve anche consegnare al mondo una confessione firmata della sua esistenza. Il contatore pubblico dell’ecosistema supera i 2,5 miliardi di certificati registrati nei log, e Let’s Encrypt da sola ha superato i dieci milioni di certificati emessi in un solo giorno a fine settembre 2025; trovare 12 certificati cattivi in quel pagliaio è esattamente ciò per cui l’infrastruttura dei log esiste.

Secondo, Chrome ha bloccato i certificati tramite i CRLSet, la sua lista di blocco d’emergenza, che viaggia con l’aggiornamento dei componenti del browser e ha effetto senza aggiornamenti né riavvii. Il team di sicurezza di Chrome sostiene da anni che i controlli di revoca online falliscono esattamente quando servono, perché l’attaccante nel mezzo può bloccare il controllo stesso; la lista di blocco viaggia invece con il browser. Google ha poi scavato nei dati CT alla ricerca di altre vittime, ha bloccato anche quei certificati, e dice di avere contattato le organizzazioni colpite dove ha potuto.

Terzo, la via lenta che copre tutti gli altri: le CA hanno revocato tutti i 12 certificati, i due certificati .gh e l’unico certificato ZeroSSL il 26 settembre, gli altri nove il 1 ottobre. La finestra più breve tra la comparsa di un certificato nel log e la sua morte è stata di circa un giorno e mezzo; la più lunga, di quasi una settimana. La clausola di onestà di Google merita la citazione: “non possiamo garantire che la nostra analisi abbia individuato ogni dominio colpito, né gli interventi di Chrome proteggono in modo affidabile gli utenti non Chrome”.

DNSSEC o i record CAA avrebbero impedito tutto questo?

Questo incidente è la dimostrazione più pulita da anni di cosa comprano, e cosa non comprano, queste due sigle.

DNSSEC per primo. Controllando la zona radice pubblicata: .gh e .sl non sono firmati affatto, il che li colloca tra i molti ccTLD che non hanno mai adottato DNSSEC, una tecnologia con il 99 per cento di adozione tra i registri in Europa ma il 65 per cento in Africa. E .as è firmato, ed è stato dirottato lo stesso. DNSSEC permette a un resolver di verificare che una risposta corrisponda a ciò che il registro ha pubblicato. Quando il registro stesso è ostile, pubblica i dati dell’attaccante, chiavi comprese. La firma su una menzogna resta una firma valida.

I record CAA, che permettono al titolare di un dominio di dichiarare quali CA possono emettere certificati per lui, hanno una forma più sottile. Durante il dirottamento sono inutili, perché il record CAA vive nello stesso DNS che l’attaccante controlla; lo standard CAA stesso ammette che un attaccante in grado di modificare il DNS può rimuovere il record. Dopo il dirottamento contano moltissimo, perché le CA possono riutilizzare una convalida completata fino a 200 giorni secondo le regole attuali del CA/Browser Forum, una finestra che scende a 100 giorni a marzo 2027 e a 10 giorni nel 2029, così un attaccante che ha perso il DNS potrebbe ancora coniare certificati freschi da verifiche in cache. Al 7 ottobre, tutti e sette i domini Google vittime noti portavano record CAA che nominano solo la CA di Google stessa. È la serratura che si monta dopo questo furto preciso, ed è una serratura vera.

Era già successo?

Gli attacchi ai registri e all’infrastruttura DNS sono un genere, non una novità. Il dossier datato:

Ci sono 316 TLD nazionali tra i circa 1.400 domini della zona radice, ciascuno legato a un Paese o territorio, ciascuno con il proprio budget, la propria governance e la propria postura di sicurezza, e alcuni gestiti da operatori privati. La stessa autorità statutaria del Ghana per i domini ha passato anni in una disputa pubblica su chi dovrebbe anche solo operare il .gh. Il modello di fiducia del web poggia, in parte, sull’idea che la meno finanziata di queste organizzazioni abbia un buon team di sicurezza.

Cosa avresti visto, e cosa ti protegge davvero?

Se fossi stato instradato verso uno dei siti falsi durante la finestra, non avresti visto nulla. Un certificato valido, un lucchetto normale, nessun avviso di alcun tipo; come ha scritto Ars Technica, il possesso di certificati simili “permette agli attaccanti di impersonare crittograficamente l’infrastruttura colpita”. Se qualcuno sia stato davvero instradato lì è uno dei fatti non divulgati.

Ciò che ha protetto gli utenti non è nulla che un utente abbia fatto. La traccia scritta obbligatoria di CT ha esposto i certificati, i CRLSet li hanno uccisi in Chrome senza richiedere alcuna azione, e la revoca ha coperto il resto. Un ulteriore strato merita menzione: le app native che fissano le proprie chiavi con il pinning. Nel caso togolese del 2017, il pinning di Chrome avrebbe comunque rifiutato il certificato google.tg fraudolento, e le app di Google come molte app bancarie usano il pinning ancora oggi. La difesa in profondità qui non è uno slogan; è una pila precisa, e a fine settembre ogni strato di quella pila ha portato peso.

Una VPN protegge da questo attacco?

Una pagina di sicurezza onesta risponde a questa domanda con precisione, quindi ecco la risposta precisa: no per questa classe di attacco, sì per le sue cugine molto più comuni, e sapere quale è quale è tutto il gioco.

Una VPN non partecipa a TLS. Il tuo browser convalida i certificati contro il suo archivio di fiducia in modo identico su qualsiasi rete, e questi certificati erano validi. Peggio ancora per qualsiasi strumento a valle del DNS: gli attaccanti hanno avvelenato i record autoritativi presso il registro, così ogni resolver onesto del pianeta, quelli di un fornitore VPN compresi, serviva le risposte dell’attaccante. Nessuna VPN, la nostra compresa, avrebbe bloccato tutto questo. A fermarlo è stata la filiera di CT, CRLSet e revoca descritta sopra.

Ciò che una VPN difende è il tuo lato della connessione. Su una rete locale ostile, un hotspot truccato o un ISP che manomette il traffico, l’attaccante sta tra il tuo dispositivo e internet, inietta risposte DNS o reindirizza il traffico. Una VPN sposta la tua risoluzione DNS e il percorso del tuo traffico dentro un tunnel cifrato che, come dice la guida della EFF, nasconde il tuo traffico “al tuo ISP e al proprietario della rete locale (come un bar o un hotel)”. Quella è la superficie di attacco comune, quella di tutti i giorni, quella che copriamo nelle nostre guide sulla crittografia VPN e sulla sicurezza sul Wi-Fi pubblico, ed è esattamente il livello che gli attaccanti dei registri non hanno mai avuto bisogno di toccare. Le due protezioni sono complementari, non intercambiabili, ed è anche per questo che manteniamo una pagina onesta a parte su cosa i siti vedono comunque con la VPN attiva.

Cosa dovrebbero fare adesso i titolari di domini?

Il consiglio di Google alle organizzazioni sta in due mosse, e vale per un’azienda con tre domini quanto per una con tremila. Monitora i log di Certificate Transparency per ogni dominio che possiedi, domini parcheggiati e regionali compresi; i 12 certificati fraudolenti sono rimasti per giorni nei log pubblici, visibili a chiunque guardasse. E pubblica record CAA restrittivi che nominano la tua CA, idealmente con il binding dell’account ACME, così che perfino la tua CA emetta solo verso il tuo account. Il regolamento delle CA aggiunge una terza mossa: se compare un certificato non richiesto, presenta un Certificate Problem Report, che i Baseline Requirements del settore obbligano la CA a istruire, con prime conclusioni entro 24 ore.

Per tutti gli altri, le lezioni sono più piccole ma reali. Tieni il browser aggiornato, perché la lista di blocco che ha salvato gli utenti di Chrome viaggia con lui. Tratta il lucchetto per ciò che è, una dichiarazione sulla cifratura in transito, non su chi c’è dall’altra parte. E colloca ogni strumento al proprio livello: il sistema dei certificati autentica i siti, una VPN protegge il percorso che il tuo traffico compie, e l’incidente di settembre esigeva che il primo fallisse in modo sicuro mentre la seconda non è mai stata in gioco.