CA intermedia compromessa: quando la fiducia si spezza

Ecco un’affermazione che sembra controintuitiva: gli incidenti più gravi con le certificate authority non sono quelli in cui un attaccante riesce a entrare. La compromissione della CA intermedia di eMudhra ne è la prova: otto chiavi di CA intermedie erano recuperabili dai certificati stessi, senza alcuna intrusione, perché la cerimonia di generazione delle chiavi della CA ha prodotto chiavi private così deboli che una di esse era letteralmente il numero 4. Nessuno ha rubato quelle chiavi. Sono nate già compromesse. Ed è una modalità di guasto più inquietante di qualsiasi violazione, perché non la risolvi ruotando le credenziali e tappando un buco. La fiducia stessa era difettosa fin dal primo giorno.

Se gestisci qualsiasi cosa che effettui connessioni TLS al di fuori di un browser — e lo fai — questo caso merita la tua attenzione. I browser sono stati protetti nel giro di pochi giorni. Il resto dell’ecosistema, le chiamate curl nei cron job, i servizi Python che fanno pinning di certifi, i binari Go con i root store incorporati, sta ancora recuperando terreno. Ti spiego cosa è successo davvero, perché la compromissione di una CA intermedia è categoricamente peggiore di quella di un certificato foglia, e cosa ci dice la correzione disomogenea sullo stato della revoca nell’internet moderno.

Cosa è andato storto davvero in eMudhra

Secondo la valutazione preliminare della stessa CA nel tracker di incidenti di Mozilla, la storia è di una banalità quasi dolorosa. Uno script della cerimonia di generazione delle chiavi — il processo controllato e sottoposto ad audit con cui una CA crea le sue chiavi più sensibili — è stato modificato con una deviazione approvata per testare una procedura di wrap/unwrap della chiave ai fini dell’esportazione. Un difetto in quel codice modificato ha fatto sì che un secondo set di chiavi ECC venisse generato sull’HSM, e quelle chiavi erano deboli. Non debolezza «di entropia ridotta». Debolezza da chiavi recuperabili in modo banale a partire dal certificato pubblico.

Pensa a cosa significa. Una chiave privata ECC dovrebbe essere un numero casuale a 256 bit. La sicurezza dell’intero schema si basa sul problema del logaritmo discreto: data la chiave pubblica, trovare lo scalare privato dovrebbe essere computazionalmente irrealizzabile. Ma se il tuo scalare «casuale» è un singolo byte, la chiave pubblica è semplicemente il punto generatore moltiplicato per quel byte, e chiunque può fare brute force su tutte le 256 possibilità in microsecondi su un portatile. Una delle otto chiavi era, secondo quanto riportato, l’intero 4. Non si tratta di una compromissione in senso tradizionale: è un certificato che non è mai stato davvero sicuro, emesso sotto una root fidata da Mozilla, Microsoft, Apple e Chrome.

Il ricercatore che l’ha segnalato, identificato come Wayne, ha dimostrato il possesso firmando un messaggio con ciascuna delle otto chiavi private e inviando le firme ai programmi root. Chiunque poteva verificare la prova con un paio di comandi OpenSSL: estrarre la chiave pubblica da ogni certificato intermedio, poi controllare che la firma sul messaggio sia valida rispetto ad essa. È questa la cosa elegante e inquietante della prova crittografica di possesso della chiave: non c’è ambiguità, nessuna nebbia da comunicato stampa del tipo «prendiamo la sicurezza sul serio». La matematica o torna o non torna. Qui è tornata.

Perché la compromissione di una CA intermedia è peggiore di quella di una foglia

Quando la chiave privata di un certificato foglia trapela — ad esempio la tua chiave per api.example.com finisce in un repository pubblico su GitHub — il raggio d’impatto è un singolo hostname, al massimo qualcuno se è un wildcard. Revochi il certificato, ne emetti uno nuovo e vai avanti. Seccante, non esistenziale.

Una chiave di CA intermedia è tutta un’altra bestia. Il Web PKI funziona come una catena di firme: una CA root (tenuta offline, protetta come materiale nucleare) firma le intermedie, e le intermedie firmano i certificati foglia che i server effettivamente presentano. Chi detiene la chiave privata di un’intermedia è quella CA, a tutti gli effetti crittografici. Può emettere un certificato valido per google.com, per la tua banca, per il dominio SSO interno — e ogni client che si fida della catena lo accetterà senza fiatare. Non ci sono limiti di frequenza, nessuna autorità centrale da contattare, nessun modo per distinguere una firma fraudolenta ma valida da una legittima.

L’incidente eMudhra moltiplica tutto questo per otto intermedie, alcune cross-firmate tramite root Sectigo, che confluiscono in trust store distribuiti su miliardi di dispositivi. Per circa un anno e mezzo — dalla creazione dei certificati difettosi fino alla divulgazione — qualsiasi client che si fidava di quelle intermedie e non imponeva la Certificate Transparency poteva essere impersonato da chiunque si fosse preso la briga di recuperare le chiavi. Questa è la finestra. Non sappiamo se qualcuno l’abbia sfruttata e, in assenza di una fortunata intercettazione nei log CT o di un attacco osservato, potremmo non saperlo mai.

È per questo che i programmi root trattano gli incidenti sulle intermedie con una gravità che quelli sulle foglie non ricevono mai. Non fidarsi di un’intermedia significa rendere non valido ogni certificato da essa emesso — migliaia di siti che si rompono in un colpo solo. La vicenda Symantec, durata anni, è l’esempio canonico di quanto sia dolorosa la bonifica completa quando le operazioni di una CA vengono giudicate inaffidabili. Il sistema funziona, ma funziona come un’amputazione, non come un intervento chirurgico.

La Certificate Transparency come eroe involontario

La parte della storia che merita più attenzione è questa: Chrome, Safari, Firefox ed Edge sono stati probabilmente protetti prima che qualcuno sapesse del problema. Non grazie alla revoca, ma grazie alla Certificate Transparency.

I browser che applicano la CT richiedono che ogni certificato pubblicamente fidato che accettano sia registrato in log CT pubblici e append-only. Le intermedie eMudhra compromesse non hanno voci nei log CT per il periodo in questione, il che significa che qualsiasi certificato foglia creato da un attaccante con quelle chiavi sarebbe stato comunque rifiutato dai client che applicano la CT: sarebbe arrivato senza valide signed certificate timestamp. La frode avrebbe dovuto essere pubblicata per essere creduta, e pubblicarla l’avrebbe esposta immediatamente.

La CT è stata progettata per individuare a posteriori le emissioni errate, per rendere rilevabili i certificati illegittimi. In questo incidente ha funzionato come controllo preventivo: ha reso le chiavi compromesse quasi inutili contro la popolazione dei browser, che è il bersaglio ad alto valore per le intercettazioni di massa. È una notizia davvero positiva per un’infrastruttura a cui la maggior parte degli ingegneri non pensa mai.

Ma — e qui devo ammettere i limiti del mio ottimismo — l’applicazione della CT è sostanzialmente un lusso dei browser. La stragrande maggioranza dei client TLS in internet non verifica le SCT. La tua chiamata curl non lo fa. La tua chiamata Python requests non lo fa. La flotta IoT che contatta il cloud del fornitore non lo fa. Per tutti questi, l’unica protezione era che i dati di revoca raggiungessero il trust store in tempo, ed è qui che la storia diventa brutta.

Il divario della revoca: browser contro tutto il resto

I produttori di browser hanno gestito bene la situazione, e meritano credito per un’infrastruttura costruita un decennio fa. Mozilla distribuisce da oltre dieci anni OneCRL — un meccanismo push per non fidarsi di intermedie e root — e ha risolto questo incidente per gli utenti Firefox in poche ore, senza bisogno di alcun aggiornamento del browser. CRLSets di Chrome e i meccanismi equivalenti di Apple hanno fatto lo stesso sulle proprie piattaforme nel giro di qualche giorno. La CA ha revocato le intermedie. Dal punto di vista dell’utente del browser, l’incidente era finito quasi prima ancora di cominciare.

Ora guarda il mondo non-browser. La lista delle correzioni sembra un inventario della supply chain del software: pacchetti ca-certificates aggiornati per Ubuntu, Debian, Fedora, Alpine, Arch, Gentoo; una nuova release di NSS; un nuovo bundle CA per curl; certifi per Python; rustls-webpki e webpki-roots per Rust; release point per Go; versioni patch di Electron su tre linee di rilascio; ca-bundle di Composer; castore di Elixir. Ognuno di questi è un artefatto separato, con una cadenza di rilascio separata, consumato da un meccanismo di aggiornamento separato. Alcuni erano ancora in sospeso giorni dopo la divulgazione.

E poi c’è la categoria che mi tiene sveglio la notte: il software che incorpora il proprio store di CA nel binario. Un servizio Go compilato con link statico l’anno scorso porta le sue root nell’artefatto compilato. Ricompilare e ridistribuire è l’unica correzione possibile — non c’è alcun pacchetto di sistema da aggiornare. Moltiplica per ogni immagine container nel tuo registry con un layer /etc/ssl/certs incorporato, ogni app Electron su ogni desktop, ogni immagine firmware su ogni dispositivo connesso, e vedi la forma del problema. Lo store di fiducia di sistema è la parte facile. Abbiamo già scritto di come i dispositivi embedded e OT trasformano gli incidenti di sicurezza in saghe pluriennali; una CA compromessa è esattamente il tipo di evento in cui quei dispositivi semplicemente non vengono mai corretti.

La lunga coda di trust store che nessuno possiede

C’è un caso particolare di questo incidente che merita un paragrafo tutto suo, perché è perfettamente illustrativo: macOS. La piattaforma Apple ha bloccato le intermedie compromesse a livello di sistema operativo in modo tempestivo. Ma il /usr/bin/curl incorporato verifica rispetto a /etc/ssl/cert.pem — un file che non è stato aggiornato — e non controlla la revoca. Quindi puoi avere un Mac completamente aggiornato in cui Safari rifiuta un certificato contraffatto mentre il curl della stessa macchina lo accetta senza problemi. Due decisioni di fiducia, una macchina, risposte opposte.

Questa frammentazione è la vera lezione. Tendiamo a parlare del «Web PKI» come se fosse un unico sistema. Sono decine di sistemi con proprietà molto diverse:

• Browser: revoca push (OneCRL, CRLSets), applicazione della CT, aggiornamenti automatici. Correzione in ore o giorni.
• Trust store di sistema: aggiornamenti gestiti dai pacchetti (ca-certificates, ca_root_nss). La correzione dipende dalla cadenza di rilascio della distribuzione e dal fatto che la macchina venga mai aggiornata.
• Ecosistemi linguistici: certifi, webpki-roots, root incorporate di Go, lo store Mozilla incluso in Node. Correggere significa pubblicare una release e attendere gli aggiornamenti delle dipendenze in migliaia di progetti.
• Artefatti compilati e immagini: binari, container, firmware. Correggere significa ricompilare e ridistribuire, che in pratica vuol dire una lunga coda vulnerabile che si estende per anni.
• IoT ed embedded: spesso nessun percorso di aggiornamento. Esposizione di fatto permanente.

I browser hanno passato un decennio a investire esattamente in questo scenario. Quasi nessun altro l’ha fatto. Un commento a monte da parte di Mozilla lo ha detto senza giri di parole: al di fuori dell’ecosistema dei browser c’è stato poco o nessun investimento nella revoca, e per quei client questa classe di incidenti è un problema enorme. Corrisponde a tutto ciò che ho visto gestendo infrastrutture. Se hai avuto a che fare con i punti ciechi nel modo in cui vengono registrati gli eventi di autenticazione cloud, riconoscerai lo schema: il percorso critico è ben strumentato e la coda lunga è una stanza buia.

Come verificare se i tuoi client sono ancora vulnerabili

Teoria a parte, dovresti testare davvero il tuo parco macchine, e il bello del TLS è che puoi farlo empiricamente. Membri della comunità hanno messo in piedi host che servono certificati firmati dalle intermedie compromesse; se il tuo client si connette senza errori di certificato, continua a fidarsi di loro. Lo schema generale per testare curl o qualsiasi altro strumento da riga di comando è questo:

# A certificate error here means you're protected.
# A successful response means this client still trusts a compromised intermediate.
curl -v https://dv-g3b-emudhra.we-have-a-problem.com/
# You can also test whether a client will accept a forged cert for an
# arbitrary hostname by pointing it at a test server:
curl -v https://example.org --connect-to example.org::2.29.126.86:

Eseguilo da ogni contesto che conta: i tuoi laptop di sviluppo, i tuoi runner CI, le immagini base dei container, le flotte di server. La risposta varierà tra loro, e le differenze sono proprio il punto. Per un rapido inventario di ciò che va aggiornato:

• Servizi Go: ricompila con Go 1.27.3 o 1.26.10 o successiva — le root sono compilate dentro.
• Python: certifi 2026.10.19 o successiva (controlla anche le versioni di pip e uv, che includono le proprie).
• Rust: rustls-webpki 0.103.16 e webpki-roots / webpki-root-certs 1.0.10.
• Node.js ed Electron: release in sospeso o patch per ciascuna linea di rilascio; controlla ogni artefatto distribuito.
• Store di sistema: i pacchetti ca-certificates aggiornati sono disponibili per Ubuntu, Debian, Fedora, Alpine, Arch, Gentoo; il ca_root_nss di FreeBSD era in sospeso al momento della stesura.

Se non puoi aspettare un pacchetto, la maggior parte delle distribuzioni Linux ti permette di non fidarti manualmente delle root interessate. Su Debian/Ubuntu basta marcare i certificati con un prefisso ! in /etc/ca-certificates.conf ed eseguire update-ca-certificates; sulla famiglia Fedora/RHEL estrai le root in /etc/pki/ca-trust/source/blocklist/ ed esegui update-ca-trust. NixOS ha un’opzione dichiarativa pulita:

security.pki.caCertificateBlacklist = [
"Comodo AAA Services root"
"emSign ECC Root CA - G3"
];

Nota cosa stai davvero rifiutando con questi workaround: le root a cui quelle intermedie sono concatenate. È la realtà dello strumento contundente nella correzione del PKI. Nella maggior parte degli strumenti di gestione dello store di fiducia non esiste una primitiva del tipo «non fidarti solo di questa intermedia», quindi metti in blocklist una root e accetti il danno collaterale ai certificati non correlati. È il compromesso giusto in un’emergenza, ma resta un compromesso.

Dove la mia tesi controcorrente si rompe

Ho aperto sostenendo che i fallimenti di generazione delle chiavi autoinflitti siano peggiori delle violazioni. Lasciami essere onesto su dove questo non regge. Una violazione tradizionale — pensa a DigiNotar — implica almeno che la CA operasse in modo competente finché un attaccante non l’ha superata, e le CA competenti sono ciò su cui scommette l’intero sistema. Una cerimonia di generazione delle chiavi che emette la chiave privata «4» implica che i controlli sottoposti ad audit, le procedure HSM, le caselle di conformità, nulla di tutto ciò ha individuato un difetto catastrofico nell’operazione più sensibile che una CA compie. Non è un problema di avversario; è un problema di garanzia, e la garanzia è l’intero prodotto che una CA vende.

Dove la tesi cede davvero: le violazioni sono più difficili da prevenire e possono restare silenziose più a lungo. Un attaccante che ruba con cautela una chiave di intermedia potrebbe usarla con parsimonia per intercettazioni mirate e non toccare mai un client che applica la CT. Le chiavi deboli, invece, sono individuabili da chiunque scandisca i certificati pubblici — ed è esattamente così che questa è emersa. C’è chi sostiene che un guasto catastrofico ma evidente sia meglio di uno sottile ma mirato. Non lo compro del tutto, ma non posso neppure scartarlo. La verità è che entrambe le modalità di guasto arrivano allo stesso punto: un’intermedia da non considerare più fidata e una lunga coda di client che non riceveranno il messaggio per mesi.

Cosa dovresti fare davvero

Non puoi riparare il Web PKI. Puoi però ridurre la tua esposizione al suo prossimo guasto:

• Testa, non dare per scontato. Sonda i tuoi client contro gli host che servono le catene compromesse. Basta un pomeriggio e ti sorprenderà.
• Ricompila gli artefatti compilati. I binari Go e le immagini container portano con sé i propri trust store. «Abbiamo corretto l’immagine base» non significa nulla finché non ridistribuisci.
• Inventaria i tuoi trust store. Non puoi correggere ciò che non hai enumerato. Conta le copie di certifi, i bundle incorporati e le app Electron come se contassero, perché contano.
• Preferisci gli store di sistema dove possibile. Ogni bundle incorporato è una patch che dimenticherai di distribuire. Centralizzare sullo store del sistema operativo non elimina il problema, ma ti dà un unico punto di controllo.
• Tieni d’occhio l’ecosistema CT e della revoca. Esistono progetti che puntano a portare una revoca di livello browser ai client non-browser e meritano supporto; questo incidente è il miglior argomento che otterranno mai per ottenere fondi.
• Tratta gli incidenti delle CA come incidenti di sicurezza. Dovrebbero far suonare il pager di qualcuno, avviare un’inventariazione e produrre una documentazione scritta — come una credenziale trapelata. Perché è esattamente ciò che sono.

La sintesi scomoda: il freno di emergenza del Web PKI funziona benissimo proprio nei client che ne avevano meno bisogno, perché la CT li copriva già. I client che avevano bisogno del freno — headless, embedded, vendorizzati, dimenticati — in gran parte non ne hanno uno. La prossima compromissione di una CA intermedia è questione di quando, non di se. L’unica variabile sotto il tuo controllo è se il tuo parco macchine se ne accorgerà.