Otto certificati TLS con chiavi private tanto deboli da consentire la creazione di credenziali apparentemente affidabili per qualsiasi sito Internet hanno fatto scattare l’allerta tra i responsabili della sicurezza. I certificati appartengono all’autorità di certificazione indiana eMudhra Limited: entro la tarda mattinata di martedì, i produttori dei browser e alcuni importanti software avevano già introdotto blocchi. L’intervento sui programmi più diffusi lascia però aperto un lavoro molto più esteso, che coinvolge server, distribuzioni Linux e dispositivi connessi.
L’allarme è partito da un avviso informale pubblicato su un sito dedicato all’incidente. Il messaggio era firmato digitalmente con la chiave privata di uno degli otto certificati intermedi, dimostrando che chi lo aveva pubblicato ne aveva il controllo. La stessa chiave poteva quindi firmare certificati non autorizzati, riconosciuti come affidabili da milioni di server. Al momento della segnalazione, non risultavano utilizzi malevoli delle chiavi compromesse nei registri che tracciano l’emissione dei certificati considerati attendibili dai browser.
La debolezza delle chiavi ha sorpreso gli stessi specialisti. Una normale chiave privata basata sulla curva ellittica NIST P-384 dispone di circa 384 bit di entropia, corrispondenti a quasi 2 elevato alla 384 possibili combinazioni. Le chiavi compromesse avevano invece appena da 3 a 8 bit: i loro valori erano 4, 56, 66, 115, 155, 156, 230 e 237. Ben Cartwright-Cox, direttore di BGP.tools, ha ipotizzato che codice dimostrativo fosse finito accidentalmente in produzione, presentando questa spiegazione come una supposizione.
Lo sfruttamento richiede un attacco attivo di interposizione: l’aggressore deve collocarsi tra le due parti della comunicazione, ricevere il traffico cifrato, decifrarlo e cifrarlo nuovamente prima di inoltrarlo. Il controllo di una rete locale, come quella di un bar, di un’università o di un’organizzazione, rende questa operazione più accessibile. Nell’immediato, tra gli impieghi più esposti figurano le VPN, soprattutto nei Paesi in cui i governi possono cercare di intercettare le comunicazioni.
La risposta dei software procede con differenze significative. La maggior parte dei browser aveva già bloccato i certificati, mentre Edge su Windows 10, al momento della pubblicazione dell’allarme, continuava a collegarsi a 12 host vulnerabili. Microsoft aveva risposto che avrebbe fornito informazioni qualora avesse avuto aggiornamenti da condividere. Signal, WhatsApp e WireGuard, che non affidano a TLS la riservatezza delle comunicazioni, non sono interessati dal problema descritto.
Per le imprese, il lavoro si estende all’inventario e all’aggiornamento di sistemi spesso distribuiti tra ambienti e responsabili diversi. Filippo Valsorda, ingegnere crittografico e manutentore della crittografia del linguaggio Go, prevede una bonifica persino più impegnativa di quella di Heartbleed. Tra i sistemi da raggiungere cita dispositivi IoT, container Docker, macchine Linux dimenticate e strumenti da riga di comando non più mantenuti, che incorporano copie proprie dei certificati radice: una pratica presente, per esempio, in alcuni ecosistemi Python.
Il confronto con Heartbleed richiama un precedente preciso. Nel 2014, lo sfruttamento della vulnerabilità nella libreria OpenSSL consentì di decifrare comunicazioni protette da TLS e recuperare chiavi private, cookie di sessione e password, compromettendo migliaia di server. Il recupero richiese anni: aggiornamenti dei dispositivi, riemissione di milioni di chiavi, revoca dei vecchi certificati e sostituzione di password e token. Per Valsorda, l’attuale eterogeneità di sistemi e soggetti coinvolti rende il coordinamento ancora più difficile.
I registri di Certificate Transparency permettono di individuare emissioni non autorizzate, ma richiedono il monitoraggio attivo di enormi flussi di dati e intervengono dopo che i certificati sono stati emessi. Sul fronte operativo, alcune distribuzioni Linux stavano ancora preparando gli aggiornamenti; agli amministratori spetterà poi applicarli su molte macchine. È questa sequenza di interventi, dalle distribuzioni ai sistemi installati, a determinare quanto a lungo le chiavi compromesse potranno continuare a rappresentare una minaccia.