Fondamenti di sicurezza - SSL e sicurezza in rete

E’ un servizio di sicurezza a livello di trasporto, con lo scopo di fornire riservatezza, integrità ed

autenticazione tra due applicazioni che comunicano via internet.

L’utilizzo principale è per proteggere informazioni trasmesse tra browser e web servers.

Brevi cenni storici

Sviluppato da Netscape, la 3° versione è stata sviluppata con revisione pubblica, divenuto uno standard

IEFT noto come TLS (Transport Layer Security, ora TLS v 1.2 ha stesso protocollo ma cambiano gli

[fine cenni…]

algoritmi supportati è resistente agli attacchi noti)

(protegge quindi a livello di applicazioni, ultimo livello, layer 7)

SSL l’autenticazione,

Permette tramite certificati, del server ed eventualmente del client e la cifratura di

tutti i dati scambiati tra server e client per garantire autenticazione, riservatezza, integrità.

SSL implementa diverse fasi (negoziazioni chiavi, scambio certificati…) e protocolli.

Sessione SSL

Una sessione SSL è un’associazione tra client e server creata tramite il protocollo con cui si negoziano

i parametri di sicurezza (Protocollo Handshake), la sessione può essere usata da più connessioni.

Connessione SSL

Ogni connessione viene associata ad una sola sessione, la connessione identifica una relazione

transiente tra nodi (una forma di trasporto).

Protocolli SSL

SSL è costituito da 2 livelli di protocolli:

Protocollo SSL Record, che fornisce servizi di base (riservatezza, integrità…) per i protocolli

- di livello

superiore (come http)

- Tre protocolli di alto livello

1. Protocollo Handshake, che negozia i parametri di sicurezza e autentica server e client

2. Protocollo Change Cipher Spec, che termina negoziazione e autenticazione

3. Protocollo Alert (gestisce gli errori)

Protocollo SSL Record

Fornisce: tramite la cifratura simmetrica (DES, AES…) utilizzando una chiave segreta condivisa e

- riservatezza

definita dal protocollo Handshake (il msg è compresso prima della cifratura)

- integrità/autenticazione utilizzando MAC con chiave segreta condivisa

(le operazioni di cifratura simmetrica e generazione del codice MAC vengono eseguite con chiavi

diverse!!)

Funzionamento:

frammenta l’input in blocchi di dimensione 2^14 byte

-

- comprime i dati (i blocchi)

- computa un codice MAC sul blocco

- cifra il blocco con chiave simmetrica in modalità CBC

aggiunge un intestazione contenente il protocollo di livello più alto (es. Handshake, http, alert…), la

-

lunghezza in byte del frammento e la versione di SSL/TLS

- trasmette il risultato in un segmento TCP

n.b. La funzione MAC si computa oltre che sul frammento anche su type, version, lengh:

MAC(MAC_write_key, seq_num||SSLCompressed.type||SSLCompressed.lengh||SSLCompressed.fragment)

in cui:

- seq_num è il numero sequenziale associato al msg su cui si computa MAC

- SSLCompressed.type è il tipo del protocollo ad alto livello utilizzato per elaborare il frammento (alert,

changhe_cypher_spec, handshake, application data)

- SSLCompressed.lengh è la lunghezza del frammento

- SSLCompressed.fragment è il frammento

nello specifico…

Protocollo Alert

Costituito da 2 byte, viene utilizzato per mandare msg di alert di due tipi, distinti dal primo byte in:

1. “warning” (primo byte = 1)

2. “fatal” (primo byte = 2)

Il secondo byte specifica il msg di alert:

- fatal può essere: unexpected message, bad record mac, decompression failure, handshake failure,

illegal parameter

- warning può essere: close notify, no certificate, bad cartificate, unsupported certificare, certificate

revoked, certificate expired, certificate unknown

(anche i msg alert vengono compressi e cifrati come tutti i dati SSL)

Protocollo Change Cipher Spec

Costituito da un msg di 1 byte, contiene un unico valore, ha lo scopo di rendere definitiva la scelta degli

schemi crittografici che si utilizzeranno durante la connessione (chiudere la fase handshake)

Protocollo Handshake

Protocollo che viene eseguito prima di inviare qualunque dato applicativo, è la parte che garantisce

interoperabilità e permette a client e server di:

1. Negoziare gli algoritmi di cifratura (cipher suite) che verranno utilizzati nella sessione:

- il metodo per lo scambio delle chiavi

l’algoritmo di cifratura (utilizzato nel protocollo SSL Record)

- l’algoritmo per il

- MAC (utilizzato nel protocollo SSL Record)

2. Autenticarsi a vicenda, solo il server o nessuna autenticazione (sconsigliato), la verifica dell0identità

avviene attraversi i certificati digitali.

3. Scambiare informazioni necessarie per la generazione di una chiave segreta. (queste info

permettono la generazione di un segreto “premaster da cui poi si genera la

secret” master key lunga

48byte.) TLS/SSL prevede però chiavi diverse da parte del server e client per MAC e cifratura, sono

necessarie 4 chiavi diverse:

- server write MAC

- server write key

- client write MAC

- client write key

Più 2 eventuali vettori di inizializzazione (uno per client e uno per server) da utilizzare in CBC, tutti

questi 6 valori sono generati partendo dalla master key.

Il protocollo Handshake è composto da un insieme di messaggi, ed è suddiviso in 4 grandi fasi:

1. Fase di Attivazione delle funzionalità di sicurezza per negoziare gli algoritmi che verranno

utilizzati nella sessione (serve a negoziare la cipher suite utilizzata nella sessione)

1

Il msg di testo in chiaro “ClientHello” contiene:

- la versione di protocollo più alta supportata;

- un valore di nonce di 32 byte che viene utilizzato nella generazione della master key e nella

generazione delle keyblock

- un ID di sessione nel caso si volesse riaprire una sessione già negoziata

- gli algoritmi crittografici supportati

Il msg “ServerHello” ha la stessa struttura del client, ma indica la versione del protocollo più alta

supportata da entrambi e la cipher suite più sicura tra quelle offerte dal client e supportate dal server.

Nella cipher suite vengono specificate terne di algoritmi per:

- metodo per lo scambio della chiave (key exchange algorithm), il segreto che si intende scambiare è il

premaster secret, da questo, eseguendo gli stessi processi, client e server ottengono la master secret

key, usata per generare le chiavi per cifrare e per generare il MAC. (i metodi di scambio supportati

sono: RSA, RSA temp, Fixed Diffie-Hellmann, Ephemeral Diffie-Hellmann, Anonymous Diffie-Hellmann)

- algoritmi di cifratura

- algoritmi per il calcolo del MAC

n.b. Il contenuto dei messaggi scambiati nelle fasi successive dipende dal metodo di scambio delle

chiavi adottato.

Metodo per lo scambio della chiave con RSA

Dopo il “ServerHello”, e quindi aver scelto RSA come metodo di trasferimento, il segreto

(premaster secret) viene generato dal client e crittografato con chiave pubblica (RSA) del

server, è previsto lo scambio del certificato della chiave pubblica del server.

Metodo per lo scambio della chiave con RSA temporaneo

Dopo il “ServerHello”, il server potrebbe avere un certificato per una chiave pubblica valida solo

per la firma, ma non per la cifratura. Il server genera quindi una coppia di chiavi (privata e

pubblica) RSA temporanee e invia al client la nuova chiave pubblica firmata con la chiave RSA

iniziale allegandone il certificato, il client genera quindi il premaster secret e lo cifra con la nuova

chiave pubblica.

Metodo per lo scambio della chiave con Fixed Diffie-Hellmann

Utilizza l’algoritmo diffie-hellmann per generare il premaster secret, il server termina il metodo

“ServerHello” fornendo i propri parametri pubblici (a, q, Ys), contenuti in un certificato rilasciato

da un’autorità di certificazione, e il client risponde fornendo al server il parametro (Yc) e il

relativo certificato (se richiesto) (n.b. essendo i parametri sempre gli stessi anche la chiave è

sempre la stessa!!).

Metodo per lo scambio della chiave con Ephemeral Diffie-Hellmann

Utilizza algoritmo diffie-hellmann dove i parametri sono creati di volta in volta e firmati dal server

(e dal client se richiesto) prevede lo scambio dei certificati per validare la firma dei parametri



(n.b. parametri variabili chiavi variabili).

Metodo per lo scambio della chiave con Anonymous Diffie-Hellmann

Come il precedente ma senza autenticazione, è un unico metodo dove non c’è autenticazione

neanche del server. Vengono quindi generati i parametri e scambiati, senza scambio di

certificati.

2. Fase di Autenticazione del server e scambio delle informazioni per la generazione delle chiavi

Il server inizia questa fase inviando un certificate:

- nel caso di RSA/Ephemeral Diffie-Hellmann contiene il certificato X.509 v3 della chiave pubblica del

server

- nel caso di Fixed Diffie-Hellmann contiene il certificato dei parametri associati al server

- nel caso di Anonymous Diffie-Hellmann, questo messaggio non viene spedito

2

inviare anche un msg “serverKeyExchange” che:

Il server potrebbe

- nel caso di RSA e Fixed Diffie-Hellmann non viene inviato

- nel caso di RSA temp questo msg contiene la chiave pubblica temporanea firmata con la chiave RSA

iniziale, il cui certificato è stato inviato nel Certificate message precedente.

- nel caso di Ephemeral Diffie-Hellmann il msg contiene i parametri Diffie-Hellmann più la loro firma