La fiducia del browser è ancora troppo fragile perché possa fallire in silenzio

E se l’icona del lucchetto stesse facendo il suo lavoro, ma il software che la sostiene no? È questa la lezione scomoda della compromissione dell’autorità di certificazione eMudhra. Nessun utente ha dovuto cliccare su un allegato dannoso o approvare una finestra di dialogo allarmante: il possesso delle chiavi private appartenenti a otto autorità di certificazione intermedie avrebbe potuto permettere a un aggressore di creare certificati apparentemente legittimi per i client vulnerabili.

L’incidente è stato reso noto dopo che un ricercatore ha individuato una vulnerabilità crittografica che interessava i certificati gestiti da eMudhra nell’ambito della sua infrastruttura emSign il 17 ottobre 2026. Mozilla ha recuperato autonomamente le chiavi interessate e ha dichiarato che il processo di generazione delle chiavi alla base del problema era difettoso e facile da sfruttare. Sei intermedi erano usati per i certificati TLS e due per la firma del codice. Il rischio non era teorico nel senso comune del termine: chiunque fosse entrato in possesso di una di quelle chiavi avrebbe potuto potenzialmente emettere certificati all’interno di una catena considerata attendibile.

I browser si sono mossi rapidamente. Chrome ha distribuito un blocco per i sei intermedi TLS il 17 ottobre e Firefox ha distribuito quella sera un blocco tramite OneCRL. Secondo The Hacker News, prima del blocco Chrome non aveva trovato certificati fraudolenti nei log di Certificate Transparency. È rassicurante, ma non equivale a una promozione a pieni voti per il modello di fiducia. Dimostra che un livello di difesa ha funzionato, non che ogni client abbia ricevuto la stessa protezione.

Il browser non è l’intero ecosistema HTTPS

Il dibattito pubblico tratta spesso la sicurezza del browser come se il browser fosse l’arbitro universale della sicurezza di Internet. Non lo è. Applicazioni, servizi, appliance, API e runtime di programmazione possono validare i certificati tramite archivi di sistema, file inclusi nel pacchetto o regole proprie. Alcuni non acquisiscono tempestivamente le informazioni sulla revoca e altri non applicano Certificate Transparency nello stesso modo dei browser.

È qui che entra in gioco CVE-2026-111943. Il Go Project ha aggiunto una denylist a crypto/x509 in Go 1.26.10 e 1.27.3, facendo fallire la verifica quando una catena contiene una delle chiavi note degli intermedi compromessi. Red Hat descrive chiaramente l’esposizione alla base del problema: un’applicazione Go avrebbe potuto accettare un certificato non autorizzato firmato da un certificato intermedio non più considerato attendibile, consentendo un attacco man-in-the-middle quando l’aggressore fosse stato in grado di intercettare la connessione.

A nostro avviso, questa è meno una storia su un singolo linguaggio vulnerabile e più una storia sulla manutenzione frammentata della fiducia. Un browser può ricevere rapidamente un blocco remoto mentre un servizio backend continua a usare un archivio obsoleto. Un utente desktop può essere protetto mentre un client API interno non lo è. La cifratura resta matematicamente solida; il problema è che il sistema deve prima decidere quale chiave meriti fiducia.

La revoca è un insieme di soluzioni incomplete, non una rete di sicurezza

La risposta rivela anche una gerarchia scomoda delle difese. Chrome e Firefox hanno bloccato gli intermedi interessati, mentre Google ha dichiarato che la rimozione di emSign ECC Root CA - G3 dal Chrome Root Store avrebbe dovuto essere distribuita ai dispositivi dipendenti il 27 ottobre 2026. Google ha avvertito che alcuni certificati legittimi concatenati a quella radice avrebbero smesso di funzionare e che i gestori dei siti interessati avrebbero dovuto ottenere nuovi certificati.

Questo compromesso è necessario. Quando si ritiene che le chiavi private siano state recuperate, preservare la comodità dei titolari dei certificati non è la priorità giusta. Ma si crea un problema pratico: l’azione difensiva può interrompere connessioni legittime, mentre un intervento tardivo può lasciare in circolazione quelle fraudolente. Gli operatori finiscono così sotto pressione per “risolvere” le interruzioni indebolendo la verifica, cioè adottando esattamente la risposta sbagliata. Come osserva Rescana, i client aggiornati possono generare errori TLS con partner o fornitori che usano ancora le catene compromesse; quegli errori dovrebbero far scattare la sostituzione dei certificati, non la disattivazione della validazione.

Il punto più preoccupante è che gli utenti comuni non possono distinguere in modo affidabile questi scenari. Un avviso del browser è visibile. Un backend che accetta una catena non valida non lo è. E un utente non può sapere se un servizio utilizza un archivio di fiducia aggiornato, un insieme di certificati incluso nel pacchetto o un runtime che ha ricevuto la correzione d’emergenza. L’architettura della fiducia è distribuita, ma la responsabilità per il suo anello più debole non lo è.

I blocchi rapidi dei browser hanno limitato i danni, ma hanno anche nascosto le lacune

Le prove disponibili non mostrano un uso esteso di certificati TLS fraudolenti prima della risposta difensiva. Il requisito di Certificate Transparency di Chrome sembra aver impedito che un certificato affidabile per il pubblico ma non registrato nei log venisse accettato da Chrome e dagli altri browser che applicano CT. Il 21 ottobre eMudhra ha dichiarato di non essere a conoscenza di prove che le chiavi deboli fossero state recuperate o sfruttate prima della divulgazione, mentre Mozilla ha affermato che più persone avevano recuperato autonomamente le chiavi in seguito.

La distinzione è importante. L’incidente è stato contenuto abbastanza bene da evitare prove di uno sfruttamento diffuso nei browser, ma “nessun abuso noto” non equivale a “nessuna esposizione significativa”. Tra i sistemi vulnerabili c’erano software che non acquisivano gli stessi segnali di revoca e trasparenza. L’avviso di Red Hat descrive per i suoi prodotti la conseguenza di una compromissione della chiave privata di una CA di terze parti, che interessa i sistemi attraverso i loro archivi di fiducia.

Per questo l’incidente non dovrebbe essere archiviato alla voce “i browser hanno gestito tutto”. I browser ne hanno gestito una parte. Il lavoro restante è passato a sistemi operativi, runtime, container, appliance aziendali e dipendenze delle applicazioni: luoghi in cui le modifiche d’emergenza alla fiducia sono più difficili da individuare e più lente da distribuire.

La lezione giusta è ridurre la fiducia, non limitarsi ad aggiornarla

Il consiglio immediato è semplice: aggiorna i runtime e le applicazioni interessati, verifica le catene dei certificati, sostituisci i certificati collegati agli intermedi compromessi e non disattivare mai la verifica dei certificati per far sparire un errore. La correzione di Go è particolarmente importante per le distribuzioni in cui la configurazione della fiducia del sistema potrebbe non aggiornarsi tempestivamente. La scheda CVE relativa a Go descrive la correzione circoscritta: rifiutare le catene che contengono gli intermedi compromessi.

La raccomandazione più ampia è più scomoda. Le organizzazioni dovrebbero censire chi valida le proprie connessioni TLS e in che modo, invece di presumere che “il browser” rappresenti ogni client. Il monitoraggio dei certificati, gli aggiornamenti delle dipendenze e una responsabilità esplicita per gli archivi di fiducia non sono controlli affascinanti, ma questo incidente ne dimostra il valore.

Il nostro verdetto: la risposta dei browser è stata rapida e il sistema di trasparenza sembra aver limitato gli abusi pubblici. Eppure il modello alla base resta troppo fragile, perché chiede a un numero enorme di sistemi indipendenti di concordare sulla fiducia, lasciando poi agli utenti pochissimi strumenti per individuare le discrepanze. HTTPS resta essenziale. L’icona del lucchetto resta utile. Ma nessuna delle due cose dovrebbe essere scambiata per la prova che ogni livello sottostante sia aggiornato.