Contenuto delle pagine HTTPS spiato con una funzionalità integrata in alcuni browser

I principali software antimalware utilizzano diverse tecniche per offrire agli utenti la possibilità di esaminare il contenuto delle pagine HTTPS e bloccare quelle che veicolano malware o pongono in essere attacchi phishing.
Fino a qualche tempo fa, molti software per la sicurezza installavano una sorta di componente proxy in locale insieme con un certificato radice, aggiunto al momento dell’installazione a quelli presenti sulla macchina (in Windows è possibile ottenere l’elenco dei certificati premendo la combinazione di tasti Windows+R quindi digitando certmgr.msc).

La connessione al sito remoto è effettuata dal componente proxy mentre il browser (Chrome, Firefox, Opera, Edge,…) useranno un certificato che non è quello originale, rilasciato dal sito web in corso di visita, ma uno generato dal produttore dell’antimalware.
Interponendo il suo proxy sul sistema dell’utente, l’antimalware diventa in grado di analizzare il contenuto di qualunque pagina HTTPS: è il principio su cui si basano noti web debugger come Charles (Monitorare il funzionamento delle applicazioni con Charles) o Fiddler.

A gennaio 2018 pubblicavamo l’articolo Protezione web degli antivirus: la scansione HTTPS è morta.
Come avevamo evidenziato in quell’articolo, ci sono molti problemi legati all’utilizzo di un proxy che di fatto, effettua un MITM (man-in-the-middle), di fatto interponendosi tra server web remoto e utente, seppur sul sistema locale di quest’ultimo.

Il problema principale consiste nel fatto che è molto difficile assicurarsi che il software proxy si comporti esattamente come il browser e non introduca vulnerabilità.
Se la logica utilizzata per la verifica del certificato soffrisse di qualche bug, allora potrebbe accettare un certificato fasullo da un server fasullo e l’utente non verrebbe avvertito. Avast, ad esempio, usava proprio quest’approccio che – come nel caso di altri produttori – soffriva di qualche lacuna di sicurezza.

Inoltre, il proxy potrebbe non supportare le versioni più sicure dei protocolli supportati dal browser e dal server (es. TLS/1.3) e quindi l’uso del certificato radice prodotto dalla società sviluppatrice del software antimalware può abbassare significativamente il livello di sicurezza.

A seguito delle controindicazioni legate all’utilizzo di certificati generati in proprio e al MITM, Avast ha recentemente cambiato strada e ha cominciato a usare una nuova tecnica. La spia del nuovo comportamento sono le segnalazioni pervenute da alcuni utenti circa la comparsa nel browser Chromium di un messaggio facente riferimento alla variabile d’ambiente SSLKEYLOGFILE.

Avviando Process Explorer e cliccando due volte su uno dei processi Chrome.exe, ci si accorgerà – accedendo alla scheda Environment – che il browser di Google sta davvero usando una variabile d’ambiente chiamata SSLKEYLOGFILE. Il suo valore, inoltre, inizia con \\.\ a conferma che essa non fa riferimento a un file conservato a livello di file system ma, addirittura, a una locazione di memoria.
L’impostazione SSLKEYLOGFILE viene richiesta proprio dalla soluzione per la sicurezza Avast con il preciso obiettivo di decifrare il traffico HTTPS all’interno del browser web.

Come conferma anche Eric Lawrence, autore di Fiddler, Firefox e Chromium supportano già questa caratteristica che permette la decodificare il traffico web senza ricorrere alla generazione di certificati root sulla macchina dell’utente.
Diversi utenti di Chromium hanno segnalato il problema e Avast ha confermato che la comparsa del messaggio è eliminabile proprio disattivando la scansione HTTPS dalle impostazioni dell’antimalware.

@WilliamJozef You can disable the feature by clicking Avast> Settings> Active Protection> Web Shield> uncheck “Enable HTTPS scanning”. 2/2

— Avast (@avast_antivirus) March 16, 2015

Non è detto che “la novità” faccia ingresso nella versione “stabile” di Google Chrome ma da più parti viene suggerito di desistere. Anche perché usando la semplice sintassi chrome --ssl-key-log-file=C:\temp\sslkeys.txt ci si accorgerebbe di quanto sia semplice accedere alle chiavi crittografiche realmente utilizzate nel corso delle varie connessioni HTTPS. Invocando l’eseguibile di Chrome con lo switch indicato, infatti, l’output non sarà più indirizzato a una locazione di memoria ma salvato invece come file di testo. Inutile dire che con Wireshark è possibile trasformare i dati in un formato leggibile (Mozilla documenta qui la funzionalità).