TLS/SSL
SSL/TLS (Transport Layer Security, RFC 5246; SSL, Secure Sockets Layer è un protocollo predecessore, che poi è stato standardizzato come TLS) ha come obiettivo quello di fornire l'autenticazione (con identificazione), la riservatezza e l'integrità dei dati inviati da un'applicazione. TLS, infatti, agisce sia con uno schema di cifratura simmetrica che asimmetrica. In realtà, ancora una volta, con TLS si intende una suite di protocolli, alcuni collocati a livello applicativo, altri a livello di trasporto. Solitamente TLS viene etichettato come un protocollo di livello 4 Trasporto (a volte come di livello 5 Sessione).
Naturalmente TLS è client/server e opera sul numero di porta TCP utilizzato dall'applicazione che intende utilizzarlo (es., sulla porta TCP 443 quando viene utilizzato da HTTPS). Benché client/server, TLS si può realizzare in modo completamente simmetrico, se implementato da entrambi i versi in modo completo.
I sottoprotocolli fondamentali di TLS sono:
a) Handshake (livello 7), preliminare, negozia i parametri della sicurezza e li stabilisce.
b) Record (livello 4), crea i pacchetti dei dati dell'applicazione (che sta usando TLS) con cifratura simmetrica e integrità (digest).
I pacchetti Record saranno incapsulati in TCP. Per questa ragione, esattamente come IPsec, TLS è trasparente alle applicazioni. Rispetto ad IPsec, TLS fornisce in modo nativo l'identificazione degli interlocutori tramite certificati digitali.
La fase di Handshake è la più critica: gli interlocutori devono autenticarsi (singolarmente o mutuamente) tramite chiavi asimmetriche prestabilite e certificato digitale, quindi stabilire una chiave di sessione segreta condivisa per cifrare la comunicazione seguente. In realtà le chiavi simmetriche possono essere due, una per il client e l'altra per il server, dato che è possibile usare TLS anche in un solo verso. Al termine dell'handshake TLS ha creato una connessione. Ora, all'interno di una connessione definita con tutti i parametri necessari TLS può aprire più sessioni senza rinegoziare da capo i parametri di sicurezza. Si ricorda che le chiavi pubbliche degli enti certificatori sono sempre reperibili dai sistemi operativi, quindi il client non ha alcuna difficoltà a decifrare il CDs spedito dal server che, a sua volta, contiene la chiave pubblica del server (con cui il client cifrerà la chiave di sessione) oltre ai valori di certificazione.
Nello schema viene rappresentato un handshake completo, in cui sia il client che il server si autenticano a vicenda e si scambiano le due chiavi simmetriche per la cifratura. In realtà è abbastanza raro che un client possegga un certificato emesso da un ente certificatore ufficiale, quindi spesso TLS si accontenta della sola autenticazione del server (presso il client). In questi casi anche la sicurezza vale in un solo verso (una sola chiave simmetrica scambiata): le sessioni successive sono cifrate sui messaggi che vanno dal server al client e solo decifrate dal client. La fase di Record si limita ad applicare le operazioni negoziate nella fase di Handshake con quegli algoritmi e quelle chiavi. TLS Record, inserito prima di TCP, frammenta i pacchetti dell'applicazione, li comprime (opzionalmente), ne calcola il MAC (con la funzione di hash negoziata), cifra in modo simmetrico sia i dati che il MAC (con algoritmo e chiavi negoziate), aggiunge un header e passa il tutto a TCP.
Il protocollo SSL/TSL ha subito uno dei più gravi attacchi alla sicurezza dei sistemi informatici a causa di un bug di programmazione di tipo buffer overrun (mancato controllo di un’area di memoria allocata). Nel pacchetto applicativo OpenSSL (disponibile sia per sistemi unix-like che Windows), le cui librerie in linguaggio C implementano numerosi algoritmi crittografici oltre al protocollo TSL, fu inserito incautamente un errore di programmazione nella gestione della parte Heartbeat del protocollo SSL/TSL. Un protocollo Heartbeat (“battito cardiaco”) ha lo scopo di mantenere attiva la connessione tra due capi in comunicazione, per esempio tra un client e un server, in modo da evitare di rinegoziare la connessione in caso di periodi di inattività. In pratica, nel caso di TLS, la parte client del protocollo invia periodicamente un pacchetto di ‘heartbeat’ al server contenente una stringa di controllo e la sua lunghezza in caratteri; il server, per confermare la sua presenza e mantenersi attivo, risponde con la stessa stringa di controllo dimensionata sulla lunghezza ricevuta (keep alive). Nell’implementazione di Heartbeat per OpenSSL rilasciata nel 2012 il programmatore della parte server non ha effettuato il controllo tra l’effettiva dimensione della stringa e la dimensione ricevuta, utilizzando quest’ultima per costruire il pacchetto di ritorno. Ora un client malintenzionato può spedire pacchetti di ‘heatbeat’ malformati, cioè con stringhe di controllo corte ma lunghezze ampie (per esempio “ciao” e 1000); il server risponderà con la stringa corretta, ma la farà seguire da altri numerosi byte non richiesti, purtroppo contenenti aree di memoria utilizzate dal server per altre attività, come ad esempio la chiave privata utilizzata o le credenziali dei client usate nelle sessioni aperte (o comunque recenti). Tale falla, denominata Heartbleed (letteralmente “cuore sanguinante”), è rimasta aperta per due anni e ha colpito, tra gli altri, siti tra i più utilizzati in rete come Google, Facebook, Wikipedia e Twitter. Naturalmente nel frattempo sono uscite versioni corrette delle librerie OpenSSL, anche se può far riflettere che strumenti software così potenti siano gestiti da team di programmatori veramente molto ristretti, che nel caso della libreria in questione si riduceva a tre soli membri (www.openssl.org)