Analisi della risposta di Chrome ai dirottamenti dei ccTLD .gh, .sl e .as del 6 ottobre 2026, con focus su CRLSets, Certificate Transparency e l'uso di record CAA per prevenire l'emissione di certificati HTTPS non autorizzati.
Il 6 ottobre Google ha descritto dirottamenti nei registri dei domini nazionali .gh, .sl e .as, rispettivamente Ghana, Sierra Leone e Samoa Americane. Sono domini di primo livello nazionali, i ccTLD. Gli aggressori hanno modificato record DNS autorevoli e ottenuto certificati HTTPS non autorizzati per domini Google e di altre organizzazioni. L’incidente ha riguardato infrastrutture di terzi, non una compromissione dei sistemi Google. Google precisa inoltre di non avere motivo di ritenere che le autorità di certificazione coinvolte abbiano agito scorrettamente. [1]
Il punto da capire è il rapporto fra controllo di un nome e identità di chi dovrebbe gestirlo. La validazione di un dominio serve a verificare che il richiedente possa soddisfare una prova di controllo; se il DNS autorevole è nelle mani sbagliate, quella prova può perdere il significato che il proprietario si aspetta. Non occorre dedurne che la crittografia TLS sia stata spezzata. Il problema riguarda l’autorizzazione dell’emissione per quel nome. È una differenza pratica: per intervenire bisogna individuare certificati, registri e controlli compromessi, anziché cambiare alla cieca ogni impostazione del sito. [1]
Chrome ha bloccato i certificati non autorizzati individuati attraverso CRLSets, lavorando anche con le CA emittenti per la revoca. I CRLSets sono un meccanismo distribuito tramite gli aggiornamenti dei componenti del browser, usato soprattutto per blocchi urgenti. Non costituiscono l’elenco universale di ogni certificato revocato e non vanno descritti come una consultazione OCSP effettuata per ciascuna visita. La documentazione Chromium spiega lo scopo del sistema: intervenire sui certificati selezionati, con limiti di copertura che restano da considerare. [1][2]
Blocco nel browser e revoca da parte dell’emittente sono due interventi distinti. Il primo riguarda il client che riceve e applica la lista; la seconda riguarda lo stato del certificato presso la CA e i meccanismi con cui i vari client verificano quello stato. Per un amministratore questo significa che “Chrome non lo accetta più” non equivale a “nessun programma lo accetterà più”. L’annuncio documenta entrambe le azioni, senza offrire una garanzia per qualsiasi software. La domanda utile in un incidente è quali certificati siano stati individuati e quali client siano effettivamente coperti, non soltanto se una lista esista. [1][2]
Sintesi dei fatti documentati nell’articolo. I riferimenti sono riportati sotto lo schema.
Certificate Transparency aggiunge registri pubblici dei certificati e dei precertificati. I log sono append-only: le nuove voci si aggiungono senza riscrivere retroattivamente quelle precedenti. Un SCT, Signed Certificate Timestamp, è un impegno del log a includere la voce entro il periodo previsto, non un attestato che il proprietario abbia autorizzato il certificato. Chrome applica requisiti CT ai certificati pubblicamente attendibili; questo non significa che ogni certificato di qualsiasi rete privata debba seguire la stessa politica. [3]
I monitor osservano i log e aiutano il proprietario a individuare emissioni inattese. Nel caso descritto da Google, i dati CT hanno permesso di trovare altri soggetti potenzialmente coinvolti oltre ai domini inizialmente identificati. Il monitoraggio dà visibilità, ma non revoca un certificato e non ripristina un record DNS. Un avviso va quindi confrontato con i rinnovi e le distribuzioni autorizzate. Una nuova CA può indicare un’anomalia, ma può anche dipendere da una modifica legittima dell’infrastruttura: il valore dell’avviso sta nel consentire quella verifica, non nel trasformare automaticamente ogni nuova emissione in un attacco. [1][3][4]
I record CAA dichiarano quali CA sono autorizzate a emettere certificati. La RFC 8657 aggiunge parametri come accounturi, per associare l’autorizzazione a uno specifico account ACME, e validationmethods, per limitare i metodi di validazione ammessi. La loro applicazione dipende dal supporto e dal comportamento della CA. Non sono un’impostazione di Chrome e non rendono immutabile il DNS: chi controlla i record autorevoli può intervenire anche sulle autorizzazioni pubblicate al loro interno. [1]
La scelta di un parametro restrittivo richiede quindi una verifica con il servizio che emette e rinnova i certificati. Un account indicato in modo errato può ostacolare anche un rinnovo legittimo. Prima di modificare una politica occorre sapere quale CA e quale account usano i propri servizi, inclusi quelli gestiti da un fornitore. L’utilità di CAA è ridurre emissioni consentite dalla politica, non promettere una chiusura definitiva di ogni attacco ai registri. Il controllo dell’infrastruttura DNS e la gestione delle autorizzazioni restano attività distinte, da seguire entrambe. [5]
Per gli utenti Chrome, Google dichiara che non serve un’azione specifica per beneficiare della protezione introdotta contro i certificati individuati. Per i proprietari dei domini il messaggio è diverso: non affidarsi soltanto all’intervento del browser. La società non garantisce che l’analisi abbia identificato tutti i domini coinvolti, né che il blocco Chrome protegga in modo affidabile gli utenti di altri client. La copertura dell’incidente non deve essere generalizzata a ogni dominio dei tre namespace. [1]
C’è anche una differenza fra una connessione cifrata e un contenuto corretto. Un certificato riguarda il nome e la chiave presentati dal server; non verifica la verità di un articolo o l’affidabilità commerciale di chi lo pubblica. Nel caso di un’emissione non autorizzata, il nome stesso può essere associato alla chiave sbagliata. Per il lettore, un avviso sul certificato è perciò un motivo per interrompere l’accesso e verificare la destinazione, non per disabilitare i controlli e inserire comunque credenziali. Nessuna delle misure descritte richiede di aggirare gli avvisi del browser. [1]
Google raccomanda monitoraggio CT continuo dell’intero portafoglio di domini, compresi quelli regionali o parcheggiati, e revisione delle emissioni recenti per chi opera in .gh, .sl o .as. Come controllo organizzativo, conviene associare gli avvisi a un inventario dei certificati autorizzati: emittente, nomi coperti e periodo di emissione aiutano a ricondurre una voce a un rinnovo conosciuto. Il confronto va effettuato con chi gestisce realmente il servizio, evitando di pubblicare chiavi private o credenziali mentre si raccolgono gli elementi dell’incidente. [1][4]
Un esempio illustrativo è un certificato nuovo per un sottodominio regionale che l’azienda conserva ma non usa per il sito principale. Se nessun fornitore riconosce quell’emissione, la verifica deve includere il controllo dei record autorevoli e il contatto con l’emittente per gestire il certificato. Se invece si tratta di un rinnovo autorizzato, si aggiorna l’inventario per riconoscere i prossimi avvisi. L’esempio non ricostruisce un caso specifico dell’attacco: mostra perché anche un dominio poco visitato merita attenzione. Il lavoro utile consiste nel collegare segnalazione, verifica e intervento, mantenendo distinta la visibilità offerta da CT dalla revoca e dal ripristino del DNS. [1][5]
Anthropic apre le scansioni gratuite ai progetti open source idonei. I report arrivano senza verifica umana preventiva: ecco come aderire, preparare il codice e valutare le segnalazioni.
Lo studio Truffle conta 543.699 credenziali databili ancora valide nei controlli di luglio 2026. Come leggere il campione e distinguere blocco del caricamento, avvisi e revoca.
Come creare una passkey Google, accedere dal telefono o dal computer e preparare il recupero. Requisiti, differenze fra i gestori e controlli da fare prima di perdere un dispositivo.
Parliamone
Hai un’esperienza da condividere o una domanda? Scrivi un commento pertinente, senza pubblicità o link.