Un https migliore

Tutti sappiamo che il protocollo https permette ad Alice e Bob di scambiarsi messaggi senza che Charlie, costantemente in ascolto sulla linea, li legga.

Ogni browser utilizza degli espedienti grafici per indicare che la connessione in corso non è facilmente intercettabile e leggibile.

Ma c’è un tipo di https che offre una sicurezza maggiore rispetto ad un altro e, per ora, i browser non hanno sistemi di avviso immediatamente riconoscibili per informare l’utente in merito.

Innanzi tutto, una carrellata su come funziona il protocollo https. I due attori in gioco (Alice e Bob) sono il client (browser dell’utente) e il server. Lo scopo è fare in modo che Charlie non legga i dati che passano in ciascuna delle due direzioni.

La fase più delicata è quella iniziale (handshake) in cui client e server concordano un algoritmo da utilizzare e negoziano la chiave di cifratura della sessione, ecco cosa avviene:

1. il browser invia al server l’elenco degli algoritmi che riesce ad utilizzare per crittare i dati ed alcuni dati casuali;
2. il server risponde con altri dati casuali, i suoi dati identificativi e la sua chiave pubblica;
3. il client analizza le credenziali fornite e le verifica utilizzando i dati raccolti con altri metodi;
4. se le verifiche di cui al punto (3) hanno esito positivo, il browser crea una premaster secret, una chiave casuale ottenuta con un algoritmo concordato tra server e client crittata con la chiave pubblica ricevuta al punto (2), e la invia al server;
5. partendo dalla premaster secret, client e server creano una master secret che verrà utilizzata per (de)crittare i dati scambiati in quella sessione;
6. a questo punto inizia lo scambio di dati effettivo e la sessione sicura può iniziare.

Senza scendere troppo in tecnicismi, il problema del protocollo https eseguito con algoritmi classici è che la compromissione della chiave privata del server o il suo calcolo attraverso l’analisi dei pacchetti in transito, porta alla possibilità di decifrare tutto il traffico. Questo metodo prende il nome di restrospective decryption e, allo stato attuale della tecnologia, il calcolo della chiave privata attraverso l’analisi del traffico richiede anni, ma potrebbe comunque valere la pena se si tratta di dati che i governi mantengono segreti per decenni o più o, più semplicemente di dati privati che non vogliamo che nessuno legga mai.

Qualcuno si è posto questo problema e la soluzione è l’utilizzo di algoritmi che implementano la forward secrecy, una serie di algoritmi che garantiscono, allo stato attuale della tecnologia, che, se anche una chiave di sessione venisse compromessa, gli unici dati decrittati sarebbero quelli a cui è stato applicata l’azione di decrittazione.

Allo stato attuale della tecnologia, l’algoritmo di scambio di chiavi che implementa la forward secrecy è ECDH (Elliptic Curve Diffie–Hellman), che si basa sulle curve ellittiche, delle bestie molto strane che, nonostante il nome, poco hanno a che fare con dei cerchi schiacciati.

Un’implementazione della forward secrecy in https è il meccanismo di scambio delle chiavi ECDHE_RSA, che Google sta implementando in tutti i suoi servizi che supportano https. In base a questo algoritmo, la chiave di sessione e nessun dato utilizzato per calcolarla possono essere salvati su supporti permanenti (dischi o altro).

L’adozione di questa famiglia di algoritmi migliora notevolmente la sicurezza delle comunicazione, a prezzo, per il momento, di un calo di performance del server. Per facilitare l’adozione di questo algoritmo, Google ha condiviso i propri sforzi con il team degli sviluppatori della libreria open source OpenSSL (cercare le occorrenze di Google nel changelog).