Bibliografia:
Computer Networking. Autori: James F. Kurose (University of Massachusetts, Amherst) Keith W. Ross (Polytechnic Institute of NYU).

Secure Socket Layer

Sicurezza del livello Trasporto

La criptografia fornisce alle applicazioni le tecniche per garantire la riservatezza del messaggio, l'integrità dei dati e l'autenticazione delle parti in comunicazione. La criptografia può garantire gli stessi servizi anche al protocollo TCP. La versione del protocollo TCP, con l'integrazione di questi servizi, è nota come Secure Socket Layer (SSL). Una versione leggermente modificata di SSL, è stata standardizzata e denominata Transport Layer Security.

La libreria SSL è integrata in tutti i browser e server Web, ed è usata principalmente da tutti i siti di e-commerce (Amazon, eBay, Yahoo!, MSN, ecc). Chiunque abbia fatto un acquisto in Internet, usando la propria carta di credito, ha notato che, nella barra dell'indirizzo del browser, il protocollo era https anzichè http, per indicare che la comunicazione tra il browser e il server Web era basata su una connessione SSL.

Per comprendere la necessità di ricorrere alle librerie SSL, può risultare conveniente esaminare una tipica transazione su Internet. Bob, navigando sul Web, raggiunge il sito di Alice, che vende profumi. Il sito di Alice presenta un form nel quale Bob deve inserire il tipo di profumo, la quantità desiderata, il suo indirizzo, e il numero della carta di credito. Dopo aver completato il form con tutti i dati richiesti, Bob fa clic sul pulsante Submit, ed aspetta di ricevere (tramite corriere) i profumi acquistati;, inoltre si aspetta che l'importo gli venga addebbitato sul suo conto, come poi potrà verificare consultando il suo estratto conto. I rischi in cui può incorrere Bob sono:

SSL risolve tutti questi problemi dotando il TCP dei servizi di riservatezza dei dati, integrità e autenticazione del server e del client.

SSL è un insieme di librerie usato per fornire la sicurezza alle transazioni che avvengono su HTTP. Siccome SSL rende sicure le connessioni TCP, viene impiegato da qualsiasi applicazione che si basa sul TCP. SSL fornisce una semplice Application Programmer Interface (API) ai socket, del tutto simile all'API del TCP. Quando un'applicazione vuole impiegare SSL, l'applicazione include le librerie e le classi di SSL. Sebbene SSL risieda al livello applicazione, lo sviluppatore di applicazioni ritiene di chiedere servizi ad un protocollo di trasporto arricchito con i servizi di sicurezza.

Modello

Prima di entrare nei dettagli di SSL, conviene esaminare un modello elementare di SSL. In questo modello semplificato, indicato con quasi-SSL, si noterà l'esigenza di aggiungere alcune caratteristiche. Il quasi-SSL (e anche SSL) è composto di tre fasi:

.

Queste tre fasi verranno descritte per una tipica sessione di comunicazione tra un client (Bob) e un server (Alice), nel quale Alice possiede una coppia di chiavi, la privata e la corrispondente pubblica, ed un certificato che lega la sua identità alla sua chiave pubblica.

Handshake

Durante la fase di handshake, Bob ha bisogno di

  1. stabilire una connessione TCP con Alice,

  2. verificare che Alice sia realmente Alice,

  3. inviare ad Alice una chiave segreta master, che sarà usata sia da Alice sia da Bob per generare tutte le chiavi simmetriche che serviranno per la sessione SSL.

La figura mostra i tre passi. Notare che appena viene stabilita la connessione TCP, Bob invia ad Alice un messaggio "hello". Alice risponde con un messaggio contenente il suo certificato, nel quale c'è la sua chiave pubblica. Siccome il certificato è stato rilasciato da una CA, Bob è sicuro che la chiave pubblica contenuta nel certificato appartiene ad Alice. Bob, quindi, genera una chiave segreta Master (MS) (che sarà valida solo per questa sessione SSL), cripta la MS con la chiave pubblica di Alice per creare la "Encrypted Master Secret" (EMS), e trasmette l'EMS ad Alice. Alice decripta l'EMS con la sua chiave privata ed ottiene la MS. Al termine di questa fase, Bob ed Alice (e nessun altro) conoscono la chiave segreta master per questa sessione SSL.

Derivazione chiavi

In linea di principio, la MS, condivisa da Bob ed Alice, potrebbe essere usata come chiave simmetrica di sessione per tutte le successive operazioni di criptografia ed di verifica dell'integrità dei dati. Invece, si ritiene che sia più sicuro che Alice e Bob usino, ciascuno, chiavi diverse per la criptografia e chiavi diverse per il controllo dell'integrità. Alice e Bob, quindi, useranno la MS per generare quattro chiavi:

Alice e Bob generano ognuno le quattro chiavi dalla MS. Potrebbero farlo semplicemente scomponendo la MS in quattro chiavi. (Ma nell'SSL reale è un po' più complicato, come si vedrà). Al termine della fase di derivazione delle chiavi, Alice e Bob hanno le quattro chiavi. Le due chiavi di criptografia saranno usate per criptare i dati; le due chiavi MAC saranno usate per verificare l'integrità dei dati.

Trasferimento dati

Adesso che Alice e Bob condividono le stesse quattro chiavi di sessione (EB, MB, EA, ed MA), possono iniziare a scambiarsi dati in modo riservato sulla connessione TCP. Poichè il TCP è un protocollo basato sul flusso di byte, si potrebbe pensare che SSL cripti i dati ricevuti dall'applicazione, nel momento stesso in cui li riceve, e li passi già criptati direttamente al TCP. Ma nasce il problema di calcolare il MAC. Non si può attendere la fine della sessione TCP per verificare l'integrità dei dati trasmessi. SSL risolve questo problema, scomponendo il flusso dei byte in record, aggiunge un MAC ad ogni record per consentire di verificare l'integrità dei dati ed infine cripta il record concatenato con il MAC. Per creare il MAC, Bob applica una funzione hash ai dati che compongono il record concatenati con la sua chiave MB. Per criptare il pacchetto record+MAC, Bob usa la sua chiave di sessione EB. Questo blocco criptato viene consegnato al TCP per trasportarlo su Internet.

Questo procedimento soffre ancora di una certa vulnerabilità agli attacchi all'integrità. In particolare, in un attacco man-in-the-middle, l'attaccante che ha l'abilità di cancellare, inserire e sostituire segmenti nel flusso TCP, scambiati tra Alice a Bob, potrebbe intercettare due segmenti trasmessi da Bob, invertirne l'ordine, correggere i numeri di sequenza TCP (che non sono criptati), e consegnare i due segmenti scambiati al destinatario Alice. Assumendo che in ogni segmento TCP sia incapsulato un solo record, Alice dovrebbe elaborare i segmenti nel seguente modo:

  1. il TCP in esecuzione dal lato di Alice non nota niente di errato e passa i due record al sotto livello SSL.

  2. SSL dal lato di Alice decripta i due record.

  3. SSL dal lato di Alice usa il MAC in ciascun record per verificare l'integrità dei due recorda.

  4. SSL consegna il flusso dei byte decriptati dei due record al livello applicazione; A questo punto l'applicazione dovrebbe accorgersi che, a causa dell'inversione dei record, la sequenza completa dei byte ricevuti da Alice non è ordinata (è compito del TCP ordinare i segmenti).

Come esercizio, esaminare il caso della rimozione o della ripetizione di segmenti da parte di un intruso.

La soluzione a questo problema è l'uso dei numeri di sequenza. Il modo in cui SSL applica il controllo dei numeri di sequenza è il seguente: Bob mantiene un contatore, che parte da zero e viene incrementato per ogni record SSL che trasmette. Bob non inserisce i numeri di sequenza nel record stesso, ma include il numero di sequenza nel calcolo del MAC. Quindi, il MAC è l'hash dei dati concatenati con la chiave MAC MB e con il numero di sequenza corrente. Alice controlla i numeri di sequenza di Bob, per verificare l'integrità dei dati in un record, includendo l'appropriato numero di sequenza atteso nel suo calcolo del MAC. L'uso dei numeri di sequenza di SSL impedisce all'intruso di organizzare un attacco man-in-the-middle, come ad esempio scambiare l'ordine dei record o sostituire i segmenti. (Perch` l'attaccante non riesce a sostituire segmenti?)

Record SSL

TipoVersioneLunghezzaDatiMAC
← Criptati con EB →

Il record SSL è mostrato nella figura. Il record contiene il campo tipo, il campo versione, il campo lunghezza, il campo dati ed il campo MAC. Notare che i primi tre campi non sono criptati. Il campo tipo indica se il record è un messaggio di handshake o un messaggio che contiene dati dell'applicazione. Questo campo ha anche lo scopo di chiudere la connessione (come descritto dopo). Il campo lunghezza serve alla libreria SSL per estrarre i record SSL dal flusso dei byte ricevuti.

Modello completo

Il modello del protocollo quasi-SSL è servito per avere un'idea generale di SSL. Mentre si esamina il modello reale di SSL, si dovrebbe verificare quanto appreso, esaminando una comunicazione, tra un host ed un server https, con un software di cattura pacchetti.

Handshake

SSL non obbliga Alice e Bob ad usare uno specifico algoritmo a chiave simmetrica, uno specifico algoritmo a chiave pubblica, o uno specifico MAC. SSL consente ad Alice e Bob di concordare gli algoritmi di criptografia da usare all'inizio della sessione SSL, durante la fase di handshake. Inoltre, durante la fase di handshake, Alice e Bob si scambiano i nonce, che verranno usati per la creazione delle chiavi di sessione (EB, MB, EA, MA). I passi del reale handshake di SSL sono i seguenti:

  1. Il client invia un elenco di algoritmi di criptografia che conosce, insieme ad un nonce del client.

  2. Dalla lista, il server sceglie un algoritmo di criptografia a chiave simmetrica (ad esempio, AES), un algoritmo a chiave pubblica (ad esempio, RSA con una specifica lunghezza della chiave), ed un algoritmo MAC. Risponde al client comunicando le sue scelte, ed invia anche il certificato ed il nonce del server.

  3. Il client verifica la validità del certificato, estrae la chiave pubblica del server, genera la chiave Pre-Master Secret (PMS), cripta la PMS con la chiave pubblica del server, e trasmette la PMS criptata al server.

  4. Usando la stessa funzione di derivazione della chiave, il client ed il server, indipendentemente, calcolano la Master Secret (MS) dalla PMS e dal nonce. La MS viene allora scomposta per generare le due chiavi di criptografia e le due chiavi MAC. Inoltre, se il cifrario a chiave simmetrica scelto usa CBC (come 3DES o AES), anche i due Vettori di Inizializzazione (IV), uno per ogni lato della connessione, sono ottenuti dalla MS. Da questo momento, tutti i messaggi scambiati tra client e server sono criptati ed autenticati (con il MAC).

  5. Il client trasmette un MAC di tutti i messaggi di handshake.

  6. Il server trasmette un MAC di tutti i messaggi di handshake.

Gli ultimi due passi proteggono la fase di handshake dalla falsificazione. Infatti, si osservi che, nel passo 1, il client propone un elenco di algoritmi, alcuni dei quali possono essere vulnerabili facilmente. Questo elenco è trasmesso in chiaro, perchè non si è ancora concordato l'algoritmo di criptografia e la chiave da usare. L'intruso, come man-in-the-middle, potrebbe cancellare gli algoritmi più robusti dalla lista, costringendo il client a selezionare un algoritmo più debole. Per prevenire questo attacco, nel passo 5 il client invia il MAC della concatenazione di tutti i messaggi di handshake inviati e ricevuti. Il server può confrontare questo MAC con il MAC dei messaggi di handshake che ha ricevuto ed inviato. Se manca la corrispondenza tra i MAC ricevuti e calcolati, il server termina la connessione. Analogamente, il server invia un MAC dei messaggi di handshake che ha visto, consentendo al client di applicare un controllo di validità.

Ci si potrebbe chiedere qual è lo scopo dei nonce nei passi 1 e 2. Per contrastare l'attacco di ripetizione, potrebbero bastare i numeri di sequenza? La risposta è sì ma, da soli, non impediscono l'attacco di ripetizione di apertura della connessione. Si ipotizzi il seguente attacco di ripetizione della connessione. Si supponga che l'intruso intercetti tutti i messaggi scambiati tra Alice e Bob. Il giorno dopo, l'intruso mascherato da Bob trasmette ad Alice esattamente la stessa sequenza di messaggi che Bob aveva inviato ad Alice il giorno precedente. Se Alice non usasse i nonce, risponderebbe con la stessa identica sequenza di messaggi che ha inviato il giorno prima. Alice non sospetterebbe alcun inganno, perchè ogni messaggio supera il controllo di integrità. Se Alice è un server di e-commerce, penserebbe che Bob sta sottoponendo un secondo ordine (per acquistare le stesse cose). In altri termini, includendo un nonce nel protocollo, Alice invierà differenti nonce per ogni sessione TCP, producendo chiavi di criptografia diverse, per ogni sessione. Quindi quando Alice riceve i record SSL registrati dall'intruso, i record non supereranno il controllo di integrità, e la falsa transazione commerciale verrà rifiutata. Per riepilogare: in SSL i nonce sono usati per difendersi dagli attacchi di ripetizione di apertura della connessione, mentre i numeri di sequenza servono per difendersi dagli attacchi di ripetizione di singoli pacchetti durante una sessione.

Chiusura connessione

Ad un certo punto, Bob o Alice decideranno di terminare la sessione SSL. Bob potrebbe terminare la sessione SSL chiudendo semplicemente la connessione TCP sottostante. Cioè Bob invia un segmento TCP con la flag FIN impostata a 1 ad Alice. Ma questo procedimento si presta a subire un attacco di troncamento della connessione, nel quale l'intruso (in the middle) chiude in anticipo una sessione inviando un segmento TCP FIN. Alice, ricevendo questo segmento, dovrebbe pensare di aver ricevuto tutti i dati, mentre in realtà ne ha ricevuto una parte. La soluzione a questo problema è quella di indicare nel campo tipo se il record serve per terminare la sessione SSL. (Il tipo è trasmesso in chiaro, è però autenticato al ricevitore con il MAC del record). Includendo un tale campo, se Alice dovesse ricevere un segmento TCP FIN prima di ricevere un record SSL di chiusura, capisce che deve ignorarlo.