Sicurezza Transport Layer: SSL, TLS, DTLS

Il Transport Layer è il quarto livello dello stack ISO/OSI, lo scopo di questo livello è creare un canale logico di comunicazione end-to-end tra due host. Quindi a questo livello è come se un host o una sua applicazione fosse in comunicazione diretta con l'altro host, senza preoccuparsi dei problemi affrontanti nei livelli inferiori (come i problemi di routing e gestione dei pacchetti IP). Per ottenere un canale logico end-to-end sicuro, che rispetti la triade Confidenzialità, Integrità e Autenticazione sono stati sviluppati SSL, TLS e DTLS.

Secure Sockets Layer

SSL usa TCP con confidenzialità, data integrity, server authentication e client authentication. Tecnicamente SSL risiede nell'application layer, però dal punto di vista dello sviluppatore, che può utilizzare delle chiamate API simili a TCP, si trova al livello trasporto.

SSL è composto da due fasi:

SSL Handshake – è lo schema usato per stabilire un canale sicuro, affidabile e autenticato tra client e server.
SSL Record - protocolli che incapsulano i messaggi in blocchi cifrati e autenticati.

Figura 1. Protocollo SSL

Il client U manda un messaggio al server S richiedendo una connessione SSL e una lista di algoritmi crittografici che esso supporta (cioè la cipher suite supportata dal client), insieme ad un client nonce.

Il server S riceve il messaggio "client hello" e seleziona un algoritmo di compressione e un cipher tra quelli listati da U. Poi S manda un "server hello" che contiene gli elementi selezionati e una nuova sequenza di byte random. Se U non riceve il "server hello" la comunicazione si stoppa.

Il server S si autentica inviando il certificato. Se i servizi offerti da S devono essere protetti allora S può richiedere a U il suo certificato. S manda il messaggio "server hello done" a U per stabilire la fine della fase in cui si verificano e si settano i parametri crittografici e la cipher suite.

Il client U costruisce un pre-master secret P come una nuova sequenza di byte random e invia P ad S dopo averlo cifrato con la propria chiave pubblica nel certificato usando l'algoritmo concordato. S decifra il messaggio di U e prende P. Client e server calcolano il master secret M nello stesso modo, siccome entrambi hanno gli stessi dati.

I messaggi della fase 4 sono costruiti basandosi sul master secret e contengono tutte le informazioni che i due partner hanno scambiato durante la fase di handshake. Questi messaggi servono a U e a S per fare un controllo sul settaggio della comunicazione e si assicurano di avere lo stesso master secret.

Server e client possono decidere di cambiare le specifiche del cipher da usare durante il data transfer. Per cifrare i dati si possono usare algoritmi a chiave pubblica, ma sono più costosi di quelli a chiave privata. Per questa ragione la crittografia a chiave pubblica è usata per scambiare le chiavi, ad esempio client e server si accordano su un segreto comune per la generazione di chiavi. Una volta che le chiavi sono state generate, il client e il server utilizzeranno un algoritmo di cifratura a chiave privata più efficiente.

Figura 2. Client Authentication

Siccome TCP è un protocollo byte stream, un approccio naturale per usare SSL è cifrare i dati dell'applicazione al volo e passarli al volo a TCP, il problema è che bisogna inserire il MAC, per il controllo dell'integrità. Quindi SSL rompe il data stream in record, mette il MAC ad ogni record per controllare l'integrità, e quindi cifra il record con il MAC.

Figura 3. SSL e MAC

Il pacchetto cifrato viene quindi passato a TCP per il trasporto su Internet. Tale approccio è vulnerabile a man-in-the-middle. L'avversario potrebbe catturare due segmenti inviati da Bob, invertire l'ordine dei segmenti, aggiustare il numero di sequenza di TCP (non sono cifrati), e inviare i due segmenti in ordine inverso ad Alice. In modo simile, l'avversario può anche replicare i messaggi. La soluzione a questo problema è usare i numeri di sequenza e includerli nel calcolo del MAC, cosi da prevenire MITM.

Il record SSL ha il campo type, version, lenght, data e MAC (i primi tre non sono cifrati):

il campo type indica se il messaggio è di handshake o contiene dati di applicazione;
in ricezione, il campo lenght viene usato per estrarre i record SSL dallo stream TCP di byte. Per terminare la sessione SSL, un approccio consiste nel terminare la connessione TCP inviando un TCP FIN. Il problema è che questo approccio è vulnerabile ad truncation attack: un Adv può inviare un TCP FIN e far chiudere la sessione SSL in maniera malevola. La soluzione è indicare nel campo type se il record serve a terminare la sessione SSL.

Transport Layer Security

SSL e TLS sono entrambi protocolli crittografici che forniscono autenticazione e cifratura su una rete. SSL è il predecessore di TLS, il quale è lo standard di cifratura usato in HTTPS, SSH, FTPS, ed e-mail sicura.

Differenza tra TLS e SSL:

TLS non supporta le cipher suite Fortezza/DMS, SSL invece supporta Fortezza. Con TLS è più facile definire nuove cipher suite.
SSL aggiunge il MAC al record dopo averlo compresso e poi cifra. Il protocollo per i record TLS invece usa l'Hash-based Message Authentication Code (HMAC).

HMAC usa due passaggi della computazione hash e la chiave segreta è usata per derivare le due chiavi: inner e outer. Il primo passaggio produce un hash interno derivato dal messaggio e dalla inner key. Il secondo passaggio produce il codice HMAC finale dall'inner hash e dall'outer key. Questo algoritmo fornisce la migliore immunità contro gli attacchi lenght extension.

In SSL per creare un master secret viene usato il message digest del pre-master secret. Con TLS, invece, si usa una funzione pseudocasuale per generare il master secret. TLS usa HMAC per creare un output pseudorandom, questa procedura prende un valore segreto e un seme iniziale e genera un output random. Questa procedura può creare tutti gli output random necessari, inoltre, non si basa su un algoritmo di hash particolare, quindi si può usare un algoritmo di hash qualsiasi (incluso MD5 e SHA).

Figura 4. Cifratura con HMAC

Infine, TLS usa la procedura per generare output pseudorandom per creare una funzione pseudorandom (PRF). La PRF combina due istanze separate della procedura di output pseudorandom: una usa l'algoritmo di hash MD5 e l'altra usa lo SHA. Questa procedura prende un valore segreto e un seme iniziale e genera l'output random. Questa procedura può creare tutti gli output random necessari.

Figura 5. Procedura per generare output pseudorandom

Datagram Transport Layer Security

Datagram Transport Layer Security è un protocollo di comunicazione che fornisce sicurezza alle applicazioni datagram-based fornendo comunicazioni che prevengono tampering, eavesdropping e message forgery.

DTLS ha un Record Layer che cifra i payload, li divide in frammenti e li incapsula in pacchetti, chiamati record, e fornisce la message authentication. Ha un sequence number, incrementato ad ogni messaggio, e ha l'epoca incrementata ad ogni handshake, entrambi usati per calcolare l'hash.

Figura 6. Record Layer

Il sequence number viene mantenuto da entrambi i peer, settato dopo aver stabilito la connessione e non viene inviato con lo scambio di messaggi: e usato per calcolare l'HMAC. Se un messaggio ricevuto non ha il sequence number atteso, l'hash non può essere verificato e la connessione viene chiusa. Il protocollo di handshake permette alle parti comunicanti di negoziare le impostazioni di sicurezza, mutua autenticazione e stabilire un canale sicuro per lo scambio dei record cifrati.

Figura 7. Prime 3 frecce: il client inizia l'handshake DTLS inviando un messaggio "ClientHello" che contiene dettagli riguardo le cipher suite supportate, parametri per le chiavi pubbliche e chiavi condivise per lo scambio di chiavi. Il server quindi calcola un cookie stateless e lo invia con il messaggio "HelloRetryRequest". Il cookie serve per dimostrare che è capace di ricevere pacchetti al suo indirizzo IP dichiarato, cosi fare attacchi DoS con IP spoofed è più difficile. La ClientHello iniziale contiene un cookie vuoto o potenzialmente un cookie conservato in cache da uno scambio precedente. Un server che non è in grado di verificare il cookie in entrata e desidera stabilire la liveness del client DTLS, invia un HelloVerifyRequest con il cookie. Alternativamente un server che vuole riprendere una sessione può saltare la fase di scambio cookie se viene presentata un’epoca (session ID) valida dal client.

Freccia 4: il server risponde con un ServerHello contenente la sua chiave condivisa e i parametri di sicurezza selezionati. La restante parte dell'handshake è completamente cifrata usando le chiavi derivate dal segreto condiviso usando Diffie-Hellman.

Freccia 5: il server continua con i seguenti messaggi:

EncryptedExtensions che contiene settaggi addizionali di protocollo;

CertificateRequest richiede l'autenticazione client;

Certificate è il certificato del server;

CertificateVerify per l'autenticazione lato server;

Finished per confermare la sicurezza del canale cifrato.

Freccia 6: il client risponde con il suo Certificate, CertificateVerify e Finished.

Freccia 7: siccome i pacchetti UDP si possono perdere e l'handshake non può essere completato se uno o più pacchetti vengono persi, la comunicazione deve essere affidabile e il server richiede gli Ack per questo insieme di messaggi finali. Questo termina l'handshake e le due parti possono scambiare gli ApplicationData cifrati con un nuovo set di chiavi derivate dai parametri di handshake.

DTLS implementa la ritrasmissione usando un timer a ogni end-point, e ritrasmette l'ultimo messaggio finché non riceve una risposta. Questo comportamento è descritto nella state machine. Quando si trova nel Read Message Fragment, le transizioni scattano all'arrivo dei data fragments o allo scadere del timer. Se il prossimo messaggio dell'handshake atteso viene ricevuto, allora viene passato ai livelli più alti e viene cancellato il timer. Altrimenti il frammento viene bufferizzato o scartato e il timer continua a scorrere. Quando il timer di ritrasmissione scade, l'implementazione ritrasmette l'ultimo volo di messaggi che ha trasmesso. Per incrementare l'efficienza, DTLS non usa un timer per ogni messaggio, ma li usa per bundle di messaggi, chiamati voli (flights). Un flight contiene tutti i messaggi creati prima del cambio del lato di invio. UDP è un protocollo message oriented senza meccanismo di frammentazione e riassemblaggio dei messaggi. Quindi solo messaggi più piccoli dell'MTU possono essere inviati. I messaggi che contengono i certificati potrebbero essere più grandi, quindi DTLS fornisce il proprio meccanismo di frammentazione: viene esteso l'Header del messaggio handshake e viene aggiunto il Fragment offset e il Fragment lenght. Inoltre, per il riordino dei messaggi, l'Handshake Message Header viene esteso con il campo Message Sequence Number.

Il design di DTLS è il più vicino a quello di IPSec, siccome le tecniche utilizzate per rendere i record DTLS sicuri per il trasporto di datagrammi sono state prese in prestito da IPSec. Tuttavia DTLS differisce da IPSec in vari aspetti:

DTLS è più facile da incorporare nelle applicazioni;
DTLS usa lo stesso stile di programmazione TLS, nel quale i security context sono controllati dall'applicazione e hanno relazioni uno-a-uno con i canali di comunicazione;
non c'è uno standard IPSec API o modello di programmazione e le implementazione IPSec deployate sono estremamente difficile da programmare;
il modello di gestione delle chiavi IPSec è estremamente complesso paragonato a quello di TLS.

Le differenza tra DTLS e TLS:

DTLS non è un implementazione di TLS su UDP, e la replay detection è una feature richiesta da TLS ma opzionale in DTLS. L'implementazione deve gestire il problema del riordino e della perdita dei pacchetti usati nell'handshake.
Anche se DTLS cerca di fornire le stesse garanzie di sicurezza di TLS, in realtà non lo fa, siccome si trova su UDP, e gli stream cipher non sono ammessi.
TLS consegna uno stream di dati in modo affidabile e con autenticazione e cifratura end-toend. DTLS è destinato a garanzie simili ma con una latenza inferiore a quella che si può ottenere quando è garantita la consegna di tutti i dati dell'applicazione.

A confronto, più o meno l'overhead è lo stesso in tutti i casi dello stesso ordine, eccetto per gli hash IPSec che hanno il doppio di byte in confronto con gli altri due protocolli.

Figura 8. Confronto IPSec, TLS, DTLS