“È sufficiente usare HTTPS per essere sicuri: protegge la comunicazione cifrando il traffico e usando certificati validati da CA riconosciute”.
SBAGLIATO. Spesso si sente pronunciare questa frase, ma non è del tutto vero: ho recentemente letto con molta attenzione un paper presentato alla conferenza CCS 2012, una conferenza dedicata alla Computer Security. Il paper ha un titolo curioso: “The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software“.
Si parla di HTTPS/SSL in contesti in cui è richiesta una comunicazione cifrata tra due sistemi (trasmissione di dati sensibili); distinguiamo due tecnologie lato end-user per accedere a sistemi HTTPS: un browser (accediamo, per esempio, ad un sito di e-commerce e facciamo il checkout in modalità protetta) oppure un’applicazione 3rd party (per esempio, lo stesso sito di e-commerce tramite un’app dedicata a smartphone/tablets).
Bene: i browser non sono in discussione e non risentono dei problemi presentati nel paper. Invece, le libraries SSL (due nomi su tutti: OpenSSL e JSSE) che solitamente vengono utilizzate nei back-end o utilizzate dagli sviluppatori per costruire applicazioni che accedono a risorse tramite HTTPS soffrono di alcuni problemi che rendono l’intera comunicazione vulnerabile a diversi tipi di attacchi, come il famoso man-in-the-middle. In breve, il problema principale è il processo di validazione dei certificati SSL (solitamente: si risale la chain fino alla root CA). Se lato client non viene effettivamente fatta la validazione del certificato presentato dal server, il client è una facile preda! Questa non-validazione è causata da molteplici fattori:
- pigrizia dei developers che, nell’utilizzare queste librerie, disabilitano controlli fondamentali durante la fase di sviluppo (perché si usano dei certificati self-signed) che poi dovrebbero essere riabilitati al go-live. Ma così non accade;
- utilizzo sbagliato delle API che settano impostazioni non congruenti (setto il check per la verifica del certificato ma poi non ricordo/non so/non è specificato che devo leggere un’ulteriore return code per verificare se la validazione è andata a buon fine).
Nel paper sono presenti alcuni esempi interessanti con tanto di codice reverse engineered.
Quali sono i rimedi?
- Come sviluppatori: configurare correttamente i parametri di validazione SSL della libreria che si usa, controllando anche i valori di ritorno della validazione se devono essere richiamati tramite un’ulteriore chiamata alle API della library utilizzata
- Come sviluppatori: fare sempre un testing utilizzando certificati SSL non verificati.
La lettura del paper è davvero molto interessante ed è vivamente consigliata per tutti quelli che hanno a che fare con lo sviluppo di applicazioni 3rd party che accedono a risorse esposte tramite HTTPS/SSL.