Chiavi TLS compromesse: anche un sito HTTPS può diventare intercettabile

Otto chiavi private associate a certificati intermedi della CA (Certification Authority) eMudhra risultano compromesse con conseguenze che toccano direttamente la sicurezza di TLS, HTTPS e di numerosi software che si affidano agli archivi di certificati conservai a livello di sistema operativo.

Non si tratta del classico certificato emesso per errore a favore di un singolo dominio: in questo caso, chi possiede una delle chiavi coinvolte può arrivare a creare certificati validi per siti che non controlla. Mozilla ha ricevuto la segnalazione il 17 ottobre 2026 e ha reagito in meno di tre ore; Chrome, Apple, Microsoft e vari progetti software hanno successivamente introdotto blocchi o aggiornamenti specifici.

Cos’è la Web PKI e da cosa scaturisce il problema

Per capire la portata dell’incidente bisogna tornare alla struttura della Web PKI (Public Key Infrastructure), infrastruttura di fiducia basata su certificati digitali e autorità di certificazione che consente ai browser di verificare l’identità dei siti HTTPS.

Quando il browser avvia una connessione HTTPS, non verifica soltanto il certificato presentato dal sito: ricostruisce una catena di fiducia che parte dal certificato del server, passa attraverso una o più autorità intermedie e arriva infine a una root CA considerata attendibile. Le chiavi delle CA intermedie hanno quindi un ruolo estremamente delicato. Se una di esse finisce nelle mani sbagliate, l’aggressore non ottiene semplicemente l’identità di un sito: acquisisce la capacità crittografica di firmare altri certificati.

È proprio ciò che rende il caso eMudhra molto diverso dagli incidenti più comuni: il ricercatore che ha segnalato il problema ha dimostrato il possesso delle chiavi firmando un messaggio con ciascuna delle 8 chiavi private interessate. Le firme possono essere verificate pubblicamente con OpenSSL utilizzando le corrispondenti chiavi pubbliche.

Perché una CA intermedia compromessa è così pericolosa

Un certificato HTTPS contiene, tra le altre informazioni, il nome del dominio al quale è destinato e una firma crittografica. Il browser accetta quella firma se riesce a collegarla a una CA fidata. Una root CA non firma direttamente milioni di certificati: delega il lavoro a certificati intermedi, mantenendo maggiormente protetta la propria chiave principale.

eMudhra è una CA intermedia indiana: perché l’incidente occorso dovrebbe interessare anche noi?

I certificati TLS sono accettati in base alle catene di fiducia presenti nei browser, nei sistemi operativi e nelle librerie software di tutto il mondo. Se una CA intermedia compromessa conduce a una root considerata attendibile da un client in Italia, quella catena può essere accettata anche qui. In pratica, la nazionalità della CA conta poco: ciò che conta è se i suoi certificati rientrano tra quelli riconosciuti dai nostri dispositivi e dalle applicazioni che utilizziamo!

Non è invece ancora pubblicamente documentato il metodo con cui le chiavi siano diventate accessibili. Secondo quanto riportato, il meccanismo alla base della compromissione risulterebbe estremamente semplice da individuare e consentirebbe di calcolare le chiavi con mezzi banali, ma i dettagli tecnici non sono stati divulgati.

Le reazioni di Mozilla, Chrome, Apple e Microsoft

Gli sviluppatori Mozilla hanno immediatamente inserito i certificati intermedi interessati dal problema in OneCRL, il sistema con cui Firefox distribuisce informazioni di revoca senza aspettare il rilascio di una nuova versione del browser.

Sono quindi passate meno di 3 ore tra la segnalazione e la protezione della maggior parte degli utenti. Mozilla ha poi rilasciato Firefox 158.0.1 per desktop e Android, Firefox ESR 115.43.1 e Firefox ESR 153.5.1: gli aggiornamenti mettono in sicurezza anche quelle installazioni nelle quali le impostazioni remote o la distribuzione dinamica di OneCRL risultino disattivati o non raggiungibili.

Chrome e Firefox bloccano gli intermedi compromessi dal 17 ottobre; Apple ha introdotto la protezione il 19 ottobre e Microsoft il 20 ottobre.

Il problema più insidioso riguarda software, runtime e container

Come spiegato nel paragrafo precedente, i grandi browser dispongono di meccanismi che permettono di reagire a incidenti simili senza attendere necessariamente una normale rotazione dei certificati. Molti programmi, invece, non offrono un sistema di revoca dinamico paragonabile a quello dei browser.

Alcuni si limitano a consultare il trust store fornito dal sistema operativo; altri includono una propria copia delle root CA. Finché quell’archivio non cambia, la verifica TLS può continuare a considerare valida una catena che passa attraverso le autorità coinvolte.

È il motivo per cui l’incidente ha generato aggiornamenti in diversi progetti spaziando da Go a Python, passando per rustls-webpki, webpki-roots, webpki-root-certs ed Electron.

Numerose applicazioni Python basate su Requests e urllib3 non utilizzano  l’archivio certificati del sistema operativo: possono affidarsi al file cacert.pem distribuito dal pacchetto. Aggiornare Windows o Linux, quindi, non garantisce automaticamente che un ambiente virtuale Python con una vecchia versione dei certificati utilizzi lo stesso insieme di autorità fidate.

Lo stesso ragionamento vale per i container. Un’immagine Docker costruita settimane o mesi fa può contenere un pacchetto ca-certificates non aggiornato: ricostruire l’applicazione senza aggiornare l’immagine di base potrebbe lasciare inalterato il problema.

Un incidente raro che mostra quanto sia fragile la catena di fiducia

Gli incidenti a livello di autorità di certificazione non rappresentano una novità. La storia della Web PKI comprende certificati emessi per domini sbagliati, violazioni delle Baseline Requirements, procedure di revoca non rispettate e CA progressivamente rimosse dai browser. La compromissione della chiave privata di una CA intermedia, però, appartiene a una categoria decisamente più seria.

La capacità crittografica di firmare nuovi certificati esce, in questo caso, dal perimetro nel quale avrebbe dovuto rimanere.

HTTPS è sicuro non soltanto grazie agli algoritmi di cifratura, ma perché ogni anello della catena di fiducia mantiene correttamente protette le proprie chiavi. Quando una chiave intermedia “cade”, la crittografia continua a funzionare perfettamente. Il problema è che le garanzie di autenticità vengono meno: il browser può instaurare una connessione cifrata senza essere più certo che dall’altra parte ci sia davvero il server legittimo. I dati sono protetti durante il transito, ma potrebbero esserlo verso l’interlocutore sbagliato.