La scoperta di otto certificati TLS intermedi con chiavi private troppo deboli ha spinto browser, grandi applicazioni e alcuni linguaggi di programmazione a intervenire rapidamente. Il rischio è che chi controlla una di quelle chiavi possa creare certificati apparentemente affidabili per qualunque sito Internet.
I certificati appartengono all’autorità di certificazione indiana eMudhra Limited. Non risultano per ora usi malevoli nelle certificate transparency logs, ma il blocco e l’aggiornamento dei sistemi coinvolti potrebbero richiedere tempo, soprattutto fuori dai browser moderni.
Che cosa è stato scoperto
Al centro dell’allerta ci sono otto certificati TLS intermedi di eMudhra Limited. Un certificato intermedio è uno degli anelli della catena che consente a browser e applicazioni di verificare l’identità di un sito e stabilire connessioni cifrate.
La gravità non riguarda un semplice errore di configurazione: secondo Ars Technica, le chiavi private associate ai certificati erano abbastanza deboli da poter consentire a terzi di ottenerne il controllo. Una delle chiavi è stata usata per firmare digitalmente un breve avviso pubblicato su un dominio dedicato, come prova del possesso della chiave stessa.
Chi disponesse di una chiave privata di questo tipo potrebbe firmare certificati non autorizzati che apparirebbero validi ai sistemi che ancora si fidano della relativa catena. In pratica, il problema tocca il meccanismo su cui poggia la fiducia nelle connessioni HTTPS e in altri servizi che usano TLS.
Il blocco è già partito
Entro la tarda mattinata di martedì, i produttori di browser e alcuni grandi software e linguaggi di programmazione avevano bloccato tutti e otto i certificati intermedi. È un passaggio essenziale per impedire che nuovi certificati firmati con quelle chiavi vengano accettati dai programmi aggiornati.
Non sono emerse segnalazioni di certificati fraudolenti nei registri di trasparenza dei certificati, che tengono traccia delle emissioni considerate affidabili dai browser. È un elemento rassicurante, ma non chiude l’incidente: la protezione effettiva dipende anche dall’aggiornamento dei componenti che conservano ancora copie delle autorità fidate.
Perché la correzione può richiedere molto tempo
Browser e principali piattaforme hanno già applicato il blocco dei certificati, mentre il resto dell’ecosistema è molto più frammentato. La fonte cita distribuzioni Linux, dispositivi embedded e prodotti Internet of Things tra le aree che potrebbero richiedere interventi più lenti.
Il problema può estendersi anche a container Docker, macchine Linux dimenticate o strumenti da riga di comando non più mantenuti che includono una propria copia delle autorità radice. In questi casi non basta il blocco già applicato dai browser: devono arrivare correzioni nei singoli pacchetti o nei sistemi che li usano, poi gli amministratori devono applicarle.
Filippo Valsorda, ingegnere di crittografia e manutentore del linguaggio Go, ha descritto ad Ars Technica una lunga coda di aggiornamenti. Il confronto con Heartbleed riportato dalla testata rende l’idea dell’ampiezza potenziale delle attività di bonifica, non certifica però che l’impatto sarà identico a quello di quell’episodio.
FAQ
Che rischio corrono gli utenti comuni?
I browser aggiornati hanno già bloccato gli otto certificati indicati. Il punto più delicato resta nei software e nei dispositivi che ricevono aggiornamenti più lentamente o che utilizzano archivi di certificati separati dal sistema principale.
Ci sono prove di attacchi già avvenuti?
No: la fonte afferma che non risultano certificati usati in modo malevolo nei certificate transparency logs. La scoperta delle chiavi deboli resta comunque sufficiente a giustificare il blocco preventivo dei certificati da parte dei programmi coinvolti.
Perché sono coinvolti anche Linux e l’Internet of Things?
Molti sistemi mantengono copie proprie degli archivi di certificati fidati o dipendono da aggiornamenti distribuiti separatamente. Questo rende più complessa e lunga la rimozione delle catene considerate non più sicure.
Considerazioni finali
La rapidità con cui browser e piattaforme principali hanno bloccato i certificati è il dato più importante nell’immediato: riduce il rischio nei programmi che vengono mantenuti con regolarità. Ma un’infrastruttura di fiducia non finisce nel browser, e proprio i sistemi meno visibili rendono questo incidente rilevante.
La lezione concreta è che la sicurezza delle connessioni dipende anche dalla manutenzione di software vecchio, container e dispositivi con cicli di aggiornamento lenti. Il blocco dei certificati è solo il primo passaggio; il punto decisivo sarà raggiungere le copie della catena di fiducia ancora presenti nei sistemi distribuiti.