IL SECURE SOCKETS LAYER (SSL) E LA SICUREZZA NEL PROTOCOLLO TCP/IP

IL SECURE SOCKETS LAYER (SSL) E LA SICUREZZA NEL PROTOCOLLO TCP/IP Mini lezione di reti Per comprendere a fondo l ambito nel quale ci stiamo muovendo, è fondamentale spiegare seppur brevemente e in maniera semplicistica, come il protocollo TCP/IP (Trasmission Control Protocol/Internet Protocol) funziona. Per ridurre la complessità di progettazione, la maggior parte delle reti sono organizzate come una serie di strati o livelli, ognuno costruito su quello inferiore: il livello inferiore fornisce dei servizi a quello superiore. (fig. 1) TCP/IP indica quindi il tipo di protocollo utilizzato, ed in particolare IP si riferisce al livello di rete (Internet Protocol), mentre il TCP (Trasmission Control Protocol) è il protocollo di livello di trasporto impiegato. Queste possono apparire solo come delle sigle ma dietro ad esse, esiste tutto il progetto di Internet. Il compito dell'ip è quello di permettere ad un host, di inserire pacchetti in una qualsiasi rete, in modo tale che questi viaggino indipendentemente verso la destinazione. L'importante è notare che questi pacchetti così instradati possono arrivare in un ordine diverso da quello con cui erano stati spediti, sarà poi compito del livello superiore (TCP) ordinarli per fornirli a sua volta all'applicazione (WEB, FTP, E-mail, ecc.). Si capisce quindi che il protocollo di livello di trasporto TCP, fornisce un ordinamento dei pachetti ed eventualmente richede quei pacchetti andati persi nel routing tra reti. A livello trasporto esiste anche il protocollo UDP (User Data Protocol) che è un protocollo non confermato, e viene utilizzato per lo più per applicazioni non affidabili, o che comunque non rientrano nell'utilizzo del TCP (quest'ultimo è un protocollo pesante e quindi per applicazioni real-time, quali voice su IP e videoconferenze viene utilizzato l'udp dato che dalla richiesta di un pacchetto andato perso a quando arriva effettivamente, la deadline scadrebbe) fig.2. Trust Italia SpA 1 di 13

Nei primi numeri di questa rivista, si è spiegato come in Java sia possibile tramite la classe Socket effettuare delle comunicazioni tra host. Quello era un esempio di connessione affidabile e quindi basata su TCP. Mentre la classe DatagramSocket costituisce il punto di accesso all'udp. La sicurezza in ambiente TCP/IP Sono possibili diversi di approcci per ottenere una sicurezza in ambiente TCP/IP. Questi sono simili nel servizio che forniscono e nei meccanismi che usano, ma differiscono rispetto al loro ambiente di applicabilità e nella loro relativa localizzazione all interno dello stack TCP/IP. Tra questi meccanismi vi è l IP Security. Con esso si fornisce trasparenza agli utenti finali e quindi alle applicazioni, e ottiene una soluzione general-purpose.inoltre, include una capacita di filtering, in modo da permettere al solo traffico selezionato, il processamento del suo header.implementando la sicurezza a livello IP, un'organizzazione può assicurare un networking sicuro non solo per le applicazioni che hanno meccanismi di sicurezza, ma anche per molte applicazioni che non le hanno, dette appunto security-ignorant. Altra soluzioni, relativamente general-purpose, permettono di implementare la sicurezza appena sopra al Trust Italia SpA 2 di 13

TCP. Il primo esempio di questo approccio e il Security Sockets Layer (SSL), e il susseguente internet standard del SSL conosciuto come Transport Layer Security(TLS). A questo livello, ci possono essere due scelte implementative. Per essere totalmente generale, SSL (o TLS) potrebbe essere pensato come parte della sottostante suite di protocolli e perciò essere trasparente all applicazione. Alternativamente, l SSL potrebbe essere inglobato in uno specifico packages. Servizi di sicurezza specifici sono inglobati in particolari applicazioni; il vantaggio di quest approccio e che la sicurezza potrebbe essere dettagliata per le specifiche necessita di una data applicazione (e quindi, ad esempio, una chiave abbastanza lunga). Nel contesto della web Security un importante esempio di questo approccio è dato dal Security Electronic Transaction (SET).In Internet, sono stati sviluppati meccanismi di sicurezza specifici per le applicazioni, quali e-mail (PGP, S/MIME), client/server (Kerberos) ecc. Secure Sockets Layer (SSL) Il Secure Sockets Layer è stato ideato dalla Netscape. La versione 3 del protocollo è stato esaminato pubblicamente e pubblicato come Internet draft document. Successivamente, quando è stato raggiunto un ampio consenso per stadardizzare il protocollo (come accade in Internet prima nasce lo "standard de facto" e poi quello effettivo), è stato formato nell IETF, il TLS working group, che studia standard comuni. Il corrente lavoro sul TLS è mirato allo sviluppo di una versione iniziale come Internet standard. La prima versione del TLS potrebbe essere vista essenzialmente come una SSLv3.1, ed è veramente vicino e quindi compatibile alla precedente SSLv3. Il protocollo SSL combina le capacità dei tre principali ma separati protocolli IPSec e li applica per una protezione a livello di trasporto. Il più comune uso che si fa dell SSL è di includerlo sul World Wide Web. Questi tre protocolli inclusi nell SSL comprendono autenticazione, criptaggio e scambio chiavi. Nell IPSec questi sono forniti dai protocolli separati: AH, ESP e protocolli per scambio chiave quali SKIP e ISAKMP. I dati dell SSL sono sempre trasmessi in un formato speciale che incorpora una checksum simile all AH e un identificatore per security association simile all ESP. Quando due host iniziano a comunicare usando l SSL, il messaggio iniziale usa uno speciale protocollo di handshake per stabilire gli algoritmi di criptaggio e le chiavi da usare. Vediamo comunque in dettaglio i vari aspetti del protocollo. SSL Architecture. SSL è stato progettato per essere usato dal TCP e fornire un servizio endto-end affidabile e sicuro. L SSL non è rappresentato da un singolo protocollo, ma piuttosto da un protocollo a due livelli: Trust Italia SpA 3 di 13

L SSL Record Protocol fornisce i servizi basilari di sicurezza ai vari protocolli di livello più alto. Ad esempio, l HTTP, che fornisce i servizi di trasferimento per le interazioni WEB clientserver, può operare alla cima del SSL. I tre più alti livelli del protocollo sono definiti come parte del SSL: l Handshake protocol, il Change Cipher Spec Protocol e l Alert Protocol. Questi specifici protocolli dell SSL sono usati nel management degli scambi SSL e saranno analizzati più avanti. Due importanti concetti dell SSL sono l SSL session e la SSL connection, che sono definiti nello specifico come segue: Connection: una connessione è un trasporto (nella definizione del modello di layering OSI) che fornisce un adatto tipo di servizio.per SSL, questa connessione è una peer-to-peer relationships. Le connessioni sono transitorie e ogni connessione è associata con una sessione. Session: una sessione SSL è un associazione tra un client e un server. Sessioni sono create dal Handshake Protocol. Sessioni definiscono un set di parametri di sicurezza crittografica che possono essere condivisi su multiple connessioni. Sessioni sono usate per permettere la negoziazione di nuovi parametri per ogni connessione. Tra ogni coppia di parti (i.e. client e sever nel HTTP) ci potrebbero essere più connessioni sicure. In teoria ci potrebbero essere anche mutiple e simultanee sessioni tra le parti, ma questa caratteristica in pratica non è usata. Ci sono anche un numero di stati associati con ogni sessione.appena una sessione è stabilita, esistono degli stati operanti per lettura e scrittura (i.e. recevive e send). In aggiunta, durante l'handshake Protocol, vengono creati degli stati quali "letture sospese" e/o "stati scrivibili". Quando si conclude con successo l Hanshake Protocol, gli stati sospesi diventano stati correnti. Uno stato di sessione è definito dai seguenti parametri: Session identifier: una sequenza di byte arbitrari scelta dal server per identificare uno stato di sessione, attivo o recuperabile Peer certificate: Un certificato X509.v3 del peer, elemento che potrebbe anche essere nullo. Compression method: l algoritmo usato per comprimere i dati prima della criptazione. Cipher spec: specifica l algoritmo di data encryption e l hash algorithm usato per il calcolo del MAC. Esso definisce anche attributi crittografici quali l hash_size. Master secret:48 byte segreti condivisi tra client e server. Is resumable: un flag che indica se la sessione può essere usata per iniziare una nuova connessione. Uno stato della connessione è definito dai seguenti parametri: Server e client random: una sequenza di byte random che sono scelti dal server e dal client per ogni connessione. Trust Italia SpA 4 di 13

Server write MAC secret: la chiave segreta usata nelle MAC operation sull invio di dati dal server. Client write MAC secret: la chiave segreta usata nelle MAC operation sull invio di dati dal client. Server write key: la chiave di encryption convenzionale per i dati criptati dal server e decriptati dal client. Client write key: la chiave di encryption convenzionale per i dati criptati dal client e decriptati dal server. Initialization vectors: quando viene usato un block cipher nel CBC mode, un vettore di inizializzazione è mantenuto per ogni key. Questo campo è prima inizializzato dal SSL Handshake Protocol. Dopo di ciò, il blocco di testo cifrato finale di ogni record è conservato per essere usato come vettore di inizializzazione nel seguente record. Sequence numbers: ogni parte mantiene numeri di sequenza separate per trasmettere e ricevere messaggi per ogni connessione. Quando una parte manda o riceve un change cipher spec message, l appropriato numero di sequenza è settato a zero. Il numero non può eccedere 2^64-1 SSL Record Protocol Il SSL Recor Protocol fornisce due servizi per la connessione SSL: Confidenzialità: definisce una chiave segreta comune che è usata per il criptaggio convenzionale del payload SSL. Integrità dei messaggi: l Handshake Protocol definisce anche una chiave segreta comune, che è usata per formare un message authentication code (MAC). Il Record Protocol prende un messaggio applicativo da essere trasmesso, frammenta i dati in blocchi manipolabili, opzionalmente comprime i dati, applica un MAC, cripta, aggiunge un header e trasmette la risultante unità in un segmento TCP. I dati ricevuti sono decriptati, verificati, decompressi e riassemblati e allora consegnati all utente del livello più alto. Trust Italia SpA 5 di 13

Il primo passo, è dunque la frammentazione. Ogni messaggio di livello più alto è frammentato in blocchi di massimo 2^14 byte. Successivamente è applicata la compressione, operazione comunque opzionale. Essa deve essere lossless, cioè priva di errori e non deve incrementare la lunghezza del contenuto di più di 1024 byte. Nella versione 3 dell SSL non è specificato nessun algoritmo di compressione, e quindi quello di default è il null. Lo step successivo consiste nel calcolare un Message Autentication Code (MAC) sui dati compressi. A tale scopo viene usata una chiave segreta. Il passo ancora successivo prevede che il messaggio compresso più il MAC, vengano criptati, usando una criptazione simmetrica. La criptazione non può aumentare la lunghezza del contenuto più di 1024 byte, così che la lunghezza totale non ecceda 2^14+2048. Sono permessi i seguenti algoritmi: Trust Italia SpA 6 di 13

Una fondamentale assunzione nella crittanalisi, enunciata per prima da Dutchman A. Kerckhoffs nello scorso secolo, è che la sicurezza di un algoritmo di crittografia deve risiedere interamente nella chiave. Kerckhoffs, assume quindi che il crittanalista, abbia una completa conoscenza dei dettagli dell'algoritmo e quindi una sua implementazione. In generale rompere un algoritmo di criptaggio, non necessariamente significa trovare un modo per permettere ad un intruso, di risalire al plaintext, dal ciphertext. Rompere un algoritmo di criptaggio semplicemente significa trovare delle debolezze, che possono essere espresse con una complessità minore del brute force attack (ricerca esaustiva delle chiavi). Quest'inciso permette di capire che in genere nella crittografia più lunga è una chiave e più sicure sono le informazioni (anche quì comunque esistono le eccezioni vedi il Two DES. Per gli stream encryption, il messaggio compresso più il MAC vengono criptati, da notare che il MAC è calcolato prima del criptaggio e inoltre il MAC è poi criptato con il plaintext o il plaintext compresso.per i block encryption, il padding può essere aggiunto dopo il MAC prima del criptaggio. Il padding è nella forma di un numero di padding byte seguiti da un byte che indica la lunghezza del padding. La quantità totale di padding è la più piccola quantità tale che la grandezza totale del dato da criptare (plaintext più MAC più padding) è un multiplo della lunghezza del blocco dell algoritmo di criptaggio. Ad esempio se il plaintext è di 58 byte, con un MAC di 20,usando un block cipher quale il DES con 8 byte di blocco, allora il campo padding.length sarà 78 byte, e per rendere la lunghezza totale un intero multiplo di 8, saranno aggiunti due byte come padding. Lo step finale dell SSL Record Protocol, è di preparare un header, consistente dei seguenti campi: Content Type (8 bits): il protocollo di più alto livello usato per processare il frammento. Major Version (8 bits): indica la maggiore versione dell SSL in uso. Per l SSL v3 questo valore è tre. Minor version (8 bits): indica la minore verisone in uso. Per l SSL v3 questo valore è zero. Trust Italia SpA 7 di 13

Compressed length (16 bits): la lunghezza in byte del frammento di plaintext (anche compresso nel caso in cui si usi una compressione). Il massimo valore è 2^14+2048. I Content Type che sono stati definiti, sono change_cipher_spec, alert,handshake, e application_data, dove i primi tre sono specifici protocolli dell SSL. Si noti inoltre che non viene fatta nessuna distinzione tra le varie applicazioni (HTTP, SMTP ecc.) che possono usare l SSL, rendendolo del tutto generale. Change Cipher Spec Protocol Esso è uno dei tre SSL-specific protocol, che usano l SSL Record Protocol, ed esso è anche il più semplice. Questo protocollo consiste di un singolo messaggio, che è un singolo byte con valore 1. L unico scopo di questo messaggio è che lo stato pendente è copiato nello stato corrente, e si aggiorna la suite di criptaggio per essere usata su questa connessione. Alert Protocol E usato per trasportare l SSL relativo alert alla peer entity. Come con altre applicazioni che usano l'ssl, i messaggi di alert sono compressi e criptati, come specificato dallo stato corrente. Ogni messaggio in questo protocollo è formato da due byte. Il primo byte ha il valore warning o fatal per trasportare la gravità del messaggio. Se il livello è fatale, l'ssl immediatamente termina la connessione. Altre connessioni sulla stessa sessione possono continuare, ma non nuove connessioni su questa sessione possono essere stabilite. Il secondo byte contiene un codice che indica lo specifico alert. Handshake Protocol Questa è la più complessa parte del SSL. Questo protocollo permette al server e al client di autenticare ogni altro e di negoziare un algoritmo di encryption, MAC e le cryptographic keys da essere usate per proteggere i dati inviati in un SSL record. L Handshake Protocol consiste in una serie di messaggi scambiati dal client e dal server. Questi hanno tutti un formato <tipo,lunghezza,valore>. Lo scambio iniziale necessario per stabilire una connessione logica tra client e server prevede quattro fasi: Fase 1 Stabilire le capacità di sicurezza Questa fase è usata per iniziare una connessione logica e per stabilire le capacità di sicurezza che saranno associate ad essa. Lo scambio è iniziato dal client che manda un client_hello message fig7a con i seguenti parametri: Trust Italia SpA 8 di 13

Versione: La più alta versione SSL capita dal client. Random: Una struttura random generata dal client, consistente di un 32 bit timestamp e di 28 byte generati da un sicuro generatore di numeri casuale. Questi valori servono per prevenire replay attacks e sono usati durante il key exchange. SessionID: un identificatore di sessione a lunghezza variabile. Un valore non zero indica che il client vorrebbe aggiornare i parametri di una esistente connessione o creare una nuova connessione su questa sessione. Un valore zero invece significa, che il client vorrebbe stabilire una nuova connessione su una nuova sessione. CipherSuite: questa è una lista che contiene la combinazione di algoritmi supportati dal client, in ordine decrescente di preferenza. Ogni elemento della lista (ogni cipher suite) definisce sia un algoritmo di scambio chiave sia un CipherSpec. Metodo di compressione: questa è una lista di metodi di compressione supportati dal client. Dopo l invio del messaggio client_hello, il client aspetta un server_hello message fig7b, che contiene gli stessi parametri del client_hello message. Per il server_hello message è applicata la seguente convenzione: Version field contiene la più bassa delle versioni suggerite dal client e la più alta supportata dal server. Il Random field è generato dal server ed è indipendente da quello del client. Se il campo SessionID era non zero, gli stessi valori sono usati dal server, viceversa il campo del server SessionID conterrà il valore della nuova sessione. Il campo CipherSuite contiene la singola cipher suite selezionata dal server tra quelle proposte dal client. Il campo di compressione contiene il metodo di compressione selezionato dal server tra quelli supportati dal client. Il primo elemento dei parametri del Cipher Suite è il metodo di scambio chiave (poi conventional encryption e MAC). Sono supportati i seguenti metodi di scambio chiave: Trust Italia SpA 9 di 13

RSA Fixed Diffie-Hellman Ephemeral Diffie-Hellman Anonymous Diffie-Hellman Fortezza Dopo la definizione di un metodo di scambio chiave abbiamo il CipherSpec che include i seguenti campi: Cipher Algorithm MAC Algorithm CipheType: cioè a blocchi o a stream IsExpotable HashSize Key Material IV Size A questo punto per far capire meglio cosa avviene, facciamo un esempio di questa fase dell'handshake protocol: in fig 7c si evidenzia un possibile messaggio del client verso il server che quindi viene svegliato (corrisponde alla fig. 7a) Una possibile risposta del server, può essere allora quella di figura 7d: Trust Italia SpA 10 di 13

Come si vede dall esempio sarà il client a dare la preferenza, ma la scelta finale spetta al server fornitore del servizio, che però deve rispettare la priorità. Si noti inoltre che il numero random del server è diverso da quello del client. Fase 2. Autenticazione del server e scambio chiave Il server inizia questa fase mandando il suo certificato, se esso è necessario, per essere autenticato. Il certificate message è richiesto per ogni metodo di scambio chiave su cui si è d accordo eccetto per anonymous Diffie-Hellman. Dopo, un server_key_exchange message potrebbe essere mandato, se richiesto. Esso non è richiesto in due casi: se certificati con il fixed Diffie-Hellman oppure se si usa un algoritmo RSA per lo scambio chiave. Questo messaggio è necessario quindi solo in alcuni casi. Il certificate_request message include due parametri: tipo certificato(indica l algoritmo a chiave pubblica) e l autorità del certificato (cioè una lista dei nomi distinti di varie autorità). Il messaggio finale della fase 2 è sempre richiesto: server_done message, che è mandato dal server per indicare la fine del server hello e associati messaggi. Dopo aver mandato questi messaggi il server aspetterà per una client response. Questo messaggio non ha parametri. In figura 8 vengono specificati questi messaggi dove quelli evidenziati sono opzionali e quindi dipendenti dalle particolari situazioni. Trust Italia SpA 11 di 13

Fase 3. Autenticazione del Client e scambio chiave Dopo la ricezione del server_done message, il client dovrebbe verificare che il server ha fornito un valido certificato, se richiesto e controlla che i parametri del server_hello sono accettabili. Se tutto è soddisfatto, il client manda uno o più messaggi indietro al server. Se il server ha richiesto un certificato, il client inizia questa fase mandando un certificate message. Se nessuna certificazione adatta è disponibile, il client manda un no_certificate alert. Successivamente il client_key_exchange message, che deve essere mandato in questa fase. Il contenuto di questo messaggio dipende dal tipo di key exchange. Infine, in questa fase il client potrebbe mandare un certificate_verify message che provvede ad una esplicita verifica del certificato del client (fig.9). Fase 4. Terminazione Questa fase completa il settaggio della connessione sicura. Il client manda un change_cipher_spec message e copia il CipherSpec pendente nel corrente CipherSpec. Si può notare che questo messaggio non è considerato parte del HandShake Protocol ma è mandato usando il Change Cipher Spec Protocol. Il client allora immediatamente manderà il finished message con il nuovo algoritmo. Il finished message verifica che lo scambio di chiave e il processo di autenticazione sono stati fatti con successo. In risposta Trust Italia SpA 12 di 13

a questi due messaggi il server manda un proprio change_chiper_spec message, trasferendo il pendente al corrente CipherSuite, e mandando il suo messaggio finale. A questo punto l handshake è completato (finalmente...) e il client e il server possono iniziare lo scambio di dati dell application layer. Questo è quindi il Secure Sockets Layer (per ulteriori approfondimenti si veda lo standard direttamente); il Transport Layer Security è grosso modo il SSL, ma con delle piccole eccezioni che riguardano per lo più la tipologia di algoritmi supportati: ad esempio il TLS non supporta il Fortezza come scambio chiave, e il calcolo degli schemi di MAC. Bibliografia Per la sicurezza in ambiente TCP/IP: William Stalling Cryptography and Network Security Prentice Hall ed. Richard E. Smith Internet Cryptography Addison Wesley ed. Andrew S. Tanenbaum Reti di Computer Prentice Hall ed. Per la crittografia in genere: Bruce Schneier Applied Cryptography second edition J.Wiley &Sons ed., un ottimo libro Trust Italia SpA 13 di 13