1 Introduzione

SSL (Secure Socket Layer protocol) è un protocollo aperto e non proprietario; è stato sottoposto da Netscape Communications all'Engineering Task Force per la sua standardizzazione, anche se di fatto è stato accettato come uno standard da tutta la comunità di Internet ancor prima del verdetto dell'IETF. La versione 3.0 del protocollo rilasciata nel novembre 1996, è un'evoluzione della precedente versione del 1994 la SSL v2.0, e rappresenta al momento una delle soluzioni più utilizzate per lo scambio di informazioni cifrate. Tale evoluzione introduce un livello di sicurezza superiore rispetto alla precedente grazie ad una maggiore attenzione nella fase di autenticazione tra client e server. Il futuro di SSL è rappresentato dal protocollo TLS v1 (SSL v3.1) sottoposto a standardizzazione nel novembre 1998.
Il protocollo SSL è nato al fine di garantire la privacy delle comunicazioni su Internet, infatti permette alle applicazioni client/server di comunicare in modo da prevenire le intrusioni, le manomissioni e le falsificazioni dei messaggi. Il protocollo SSL garantisce la sicurezza del collegamento mediante tre funzionalità fondamentali:

• Privatezza del Collegamento: Per assicurare un collegamento sicuro tra due utenti coinvolti in una comunicazione, i dati vengono protetti utilizzando algoritmi di crittografia a chiave simmetrica (ad es. DES, RC4, ecc.);
• Autenticazione: L'autenticazione dell'identità nelle connessioni può essere eseguita usando la crittografia a chiave pubblica (per es. RSA, DSS ecc.). In questo modo i client sono sicuri di comunicare con il server corretto, prevenendo eventuali interposizioni. Inoltre è prevista la certificazione sia del server che del client;
• Affidabilità: Il livello di trasporto include un controllo sull'integrità del messaggio basato su un apposito MAC (Message Authentication Code) che utilizza funzioni hash sicure (per es. SHA, MD5 ecc.). In tal modo si verifica che i dati spediti tra client e server non siano stati alterati durante la trasmissione.

• Protocollo SSL Handshake, permette al server ed al client di autenticarsi a vicenda e di negoziare un algoritmo di crittografia e le relative chiavi prima che il livello di applicazione trasmetta o riceva il suo primo byte. Un vantaggio di SSL è la sua indipendenza dal protocollo di applicazione, in tal modo un protocollo di livello più alto può interfacciarsi sul protocollo SSL in modo trasparente;
• Protocollo SSL Record, è interfacciato su di un protocollo di trasporto affidabile come il TCP. Questo protocollo è usato per l'incapsulamento dei dati provenienti dai protocolli superiori.

SSL è un protocollo a due strati, SSL Record a livello inferiore ed SSL Handshake a livello superiore, che si interfaccia con una applicazione ad esempio HTTP.

2 Obiettivi

Gli scopi del Protocollo SSL v3.0, in ordine di priorità, sono:

• Sicurezza del collegamento: SSL stabilisce un collegamento sicuro tra due sistemi;
• Interoperabilità: Programmatori di diverse organizzazioni dovrebbero essere in grado di sviluppare applicazioni utilizzando SSL 3.0, accordandosi sui parametri utilizzati dagli algoritmi di crittografia senza necessità di conoscere il codice l'uno dell'altro;
• Ampliamento: SSL cerca di fornire una struttura dentro la quale i futuri metodi di crittografia a chiave pubblica e chiave simmetrica possano essere incorporati senza dover per questo creare un nuovo protocollo;
• Efficienza: Le operazioni di crittografia tendono a essere molto laboriose per la CPU, particolarmente le operazioni con le chiavi pubbliche. Per questa ragione l'SSL ha incorporato uno schema di session caching opzionale per ridurre il numero di collegamenti che hanno bisogno di essere stabiliti ex-novo. Particolare attenzione è stata posta nel ridurre l'attività sulla rete.

3 Il protocollo SSL: soluzioni tecniche

SSL prevede una fase iniziale, detta di handshake, usata per iniziare una connessione TCP/IP. In particolare il risultato di tale fase è l'avvio di una nuova sessione che permette la contrattazione da parte del client e del server del livello di sicurezza da usare ed il completamento delle autenticazioni necessarie alla connessione. Quindi SSL procede con la cifratura (e/o con la messa in chiaro) della sequenza di byte del protocollo applicazione usato, ad esempio nell'HTTP tutte le informazioni sia di richiesta che di risposta sono completamente cifrate, incluso l'URL richiesto dal client, qualsiasi contenuto di form compilati (quindi anche eventuali numeri di carte di credito...), ogni informazione sulle autorizzazioni all'accesso come username e password, e tutti i dati inviati in risposta dal server al client.

3.1 Protocollo SSL Handshake

Il protocollo SSL usa una combinazione di chiavi pubbliche e chiavi simmetriche. La cifratura a chiave simmetrica è molto più veloce della cifratura a chiave pubblica, anche se quest'ultima provvede ad una tecnica di autenticazione migliore. Una sessione SSL inizia sempre con uno scambio di messaggi chiamati di SSL handshake. L'handshake consente al server di autenticarsi al client usando una tecnica a chiave pubblica, quindi permette al client ed al server di cooperare per la creazione delle chiavi simmetriche usate per una veloce cifratura, decifratura e controllo delle intrusione durante la sessione avviata. Eventualmente, l'handshake permette anche al client di autenticarsi al server.
Nel protocollo SSL Handshake l'avvio di una nuova connessione può avvenire o da parte del client o da parte del server. Se è il client ad iniziare, allora questo invierà un messaggio di client hello, iniziando così la fase di Hello, e si porrà in attesa della risposta del server che avviene con un messaggio di server hello. Nel caso in cui sia il server ad iniziare la connessione, questo invierà un messaggio di hello request per richiedere al client di iniziare la fase di Hello. Con lo scambio di questi messaggi, il client ed il server si accorderanno sugli algoritmi da usare per la generazione delle chiavi; in particolare il client ne proporrà una lista, quindi sarà il server a decidere quale di essi dovrà essere utilizzato.
A questo punto può iniziare o meno, a seconda del metodo di autenticazione impiegato (autenticazione di entrambe le parti, autenticazione del server con client non autenticato, totale anonimato), uno scambio di certificati tra client e server. L'autenticazione è un controllo che si può effettuare per provare l'identità di un client o di un server. Un client abilitato può controllare che il certificato del server sia valido e che sia stato firmato da un'autorità fidata (CA). Questa conferma può essere utile, per esempio, se un utente invia il numero di carta di credito e vuole controllare l'identità del ricevente.
Allo stesso modo un client può essere autenticato, questo potrebbe essere utile se il server è ad esempio una banca che deve inviare dati finanziari confidenziali ad un suo cliente che necessita quindi di essere autenticato.
E' importante notare che sia l'autenticazione del client che quella del server implica la cifratura di alcuni dati condivisi con una chiave pubblica o privata e la decifratura con la chiave corrispondente. Nel caso dell'autenticazione del server, il client deve cifrare dei dati segreti con la chiave pubblica del server. Solo la corrispondente chiave privata può correttamente decifrare il segreto, così il client ha delle assicurazioni sulla reale identità del server poichè solo lui può possedere tale chiave. Altrimenti il server non potrà generare le chiavi simmetriche richieste per la sessione, che verrà così terminata. In caso di autenticazione del client, questi deve cifrare alcuni valori casuali condivisi con la sua chiave privata, creando in pratica una firma. La chiave pubblica nel certificato del client può facilmente convalidare tale firma se il certificato è autentico, in caso contario la sessione verrà terminata.
Avvenuta l'autenticazione si procede con la generazione delle chiavi per la cifratura e per l'autenticazione dei dati provenienti dal livello di applicazione, tutto questo attraverso i messaggi di server key exchange e client key exchange. Terminata questa operazione, il server annuncerà la fine della fase di Hello al client, con l'invio di un messaggio di server hello done, dopodichè con l'invio di un messaggio di change CipherSpec entrambi controlleranno la correttezza dei dati ricevuti e se tutto è avvenuto in maniera corretta, da questo punto in poi useranno gli algoritmi di sicurezza concordati. La fase di handshake terminerà con l'invio, da entrambe le parti, di un messaggio di finished che sarà il primo dato ad essere cifrato.

Le fasi che caratterizzano l’handshake sono rappresentate nella figura seguente:

Il client ed il server possono decidere di riabilitare una precedente sessione o di duplicarne una esistente invece di negoziare di nuovo i parametri di sicurezza; in questo caso si parla di riesumazione di sessioni:

3.1.1 Messaggi di handshake

I messaggi usati dal protocollo SSL Handshake vengono descritti nei paragrafi seguenti, nell'ordine in cui devono essere spediti.

3.1.1.1 Messaggi di Hello

I messaggi di Hello vengono utilizzati nella fase iniziale del protocollo SSL Handshake per avviare una nuova connessione.
L'inizio della connessione tra il client ed il server può avvenire in due modi:

• con l'invio da parte del server del messaggio hello request. Questo messaggio può essere inviato dal server in ogni momento, ma viene ignorato dal client se il protocollo handshake è già iniziato;
• con l'invio del messaggio client hello, da parte del client, al quale il server deve rispondere con un messaggio di server hello. Qualora il server non dovesse rispondere si verifica un errore fatale e la connessione fallisce.

3.1.1.1.1 Hello request

Il messaggio di hello request è una richiesta di comunicazione che il server invia al client. Se il client risponde alla richiesta del server, con il messaggio client hello, si avvia la fase di negoziazione. Dopo aver mandato un hello request il server non deve ripeterlo finché la fase di handshake non sarà terminata.

3.1.1.1.2 Client hello

Il messaggio di client hello è utilizzato da un client per:

• avviare una nuova connessione con un server;
• rispondere ad un hello request del server;
• rinegoziare i parametri di sicurezza di una connessione esistente.

Il  messaggio client hello ha i seguenti campi:

• protocol version: sono due byte utilizzati per indicare la versione di SSL in uso;
• random byte: sono dei byte casuali generati dal client che vengono memorizzati nella struttura seguente:

  struct {

  uint32 gmt_unix_time;
  opaque random_byte[28];
  } Random;

  dove gmt_unix_time è la data e l'ora corrente nel formato UNIX standard a 32-bit e random_byte è una sequenza di 28 byte prodotti da un generatore di numeri casuali.
  Con il tipo opaque indicheremo un byte che SSL non può risolvere ulteriormente, né come numero, né come carattere, in quanto tale byte fa parte del flusso di dati di livello applicazione trattato in modo trasparente da SSL.

• session identifier: sono 32 byte contenenti l'identificativo di una precedente sessione di una connessione che potrebbe essere riesumata. Se sono tutti zero, indicano che si tratta di una nuova sessione.
  

  La struttura usata è la seguente:

  opaque SessionID<0..32>;
  
  

  Con le parentesi angolari si indica il numero di elementi che un vettore può contenere.
  
  

• lista delle CipherSuite (cipher_suites): è la lista contenente le combinazioni di algoritmi di crittografia supportati dal client, ordinata secondo le sue preferenze.
  Il server effettuerà una scelta tra gli algoritmi presenti nella lista, se nessuno di questi è supportato verrà restituito un messaggio di errore e la connessione verrà chiusa.
  In definitiva la lista delle CipherSuite è una successione di coppie di byte rappresentanti:
  • l'algoritmo per lo scambio di chiavi (stabilisce il modo con cui viene calcolato il pre master secret e il metodo di autenticazione);
  • la CipherSpec, contenente l'algoritmo di cifratura dei dati (ad es. null, DES, etc.) con le eventuali caratteristiche implementative e l'algoritmo per il Message Authentication Code (per es. MD5 o SHA);
  
  Ogni CipherSuite è cosi definita:

  uint8 CipherSuite[2];

  Nella seguente lista vengono elencate le principali CipherSuite:
  
  

  CipherSuite	Key Exchange	Cipher	Hash
  SSL_NULL_WITH_NULL_NULL	NULL	NULL	NULL
  SSL_RSA_WITH_NULL_MD5	RSA	NULL	MD5
  SSL_RSA_WITH_NULL_SHA	RSA	NULL	SHA
  SSL_RSA_EXPORT_WITH_RC4_40_MD5	RSA_EXPORT	RC4_40	MD5
  SSL_RSA_WITH_RC4_128_MD5	RSA	RC4_128	MD5
  SSL_RSA_WITH_RC4_128_SHA	RSA	RC4_128	SHA
  SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5	RSA_EXPORT	RC2_CBC_40	MD5
  SSL_RSA_WITH_IDEA_CBC_SHA	RSA	IDEA_CBC	SHA
  SSL_RSA_EXPORT_WITH_DES40_CBC_SHA	RSA_EXPORT	DES40_CBC	SHA
  SSL_RSA_WITH_DES_CBC_SHA	RSA	DES_CBC	SHA
  SSL_RSA_WITH_3DES_EDE_CBC_SHA	RSA	3DES_EDE_CBC	SHA
  SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA	DH_DSS_EXPORT	DES40_CBC	SHA
  SSL_DH_DSS_WITH_DES_CBC_SHA	DH_DSS	DES_CBC	SHA
  SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA	DH_DSS	3DES_EDE_CBC	SHA
  SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA	DH_RSA_EXPORT	DES40_CBC	SHA
  SSL_DH_RSA_WITH_DES_CBC_SHA	DH_RSA	DES_CBC	SHA
  SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA	DH_RSA	3DES_EDE_CBC	SHA
  SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA	DHE_DSS_EXPORT	DES40_CBC	SHA
  SSL_DHE_DSS_WITH_DES_CBC_SHA	DHE_DSS	DES_CBC	SHA
  SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA	DHE_DSS	3DES_EDE_CBC	SHA
  SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA	DHE_RSA_EXPORT	DES40_CBC	SHA
  SSL_DHE_RSA_WITH_DES_CBC_SHA	DHE_RSA	DES_CBC	SHA
  SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA	DHE_RSA	3DES_EDE_CBC	SHA
  SSL_DH_anon_EXPORT_WITH_RC4_40_MD5	DH_anon_EXPORT	RC4_40	MD5
  SSL_DH_anon_WITH_RC4_128_MD5	DH_anon	RC4_128	MD5
  SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA	DH_anon	DES40_CBC	SHA
  SSL_DH_anon_WITH_DES_CBC_SHA	DH_anon	DES_CBC	SHA
  SSL_DH_anon_WITH_3DES_EDE_CBC_SHA	DH_anon	3DES_EDE_CBC	SHA
  SSL_FORTEZZA_DMS_WITH_NULL_SHA	FORTEZZA_DMS	NULL	SHA
  SSL_FORTEZZA_DMS_WITH_FORTEZZA_CBC_SHA	FORTEZZA_DMS	FORTEZZA_CBC	SHA

  
  
  
• la prima CipherSuite della lista non prevede nessun algoritmo per la sicurezza, infatti tale CipherSuite viene usata come default da client e server quando si avvia una connessione e ancora non è stato pattuito nessun algoritmo;
• nelle CipherSuite inizianti con SSL_RSA viene richiesto al server un certificato con chiave RSA (es. X.509), che verrà usato per lo scambio delle chiavi e opzionalmente per l'autenticazione del server. In tale caso il server potrà richiedere al client tramite certificate request un certificato con chiave RSA o chiave per la firma DSS;
• in quelle inizianti con SSL_DH si denota una CipherSuite in cui il certificato del server contiene i parametri Diffie-Hellman firmati da un'autorità di certificazione (CA);
• invece SSL_DHE denota ephemeral Diffie-Hellman, dove i parametri Diffie-Hellman sono autenticati da un certificato DSS o RSA che viene firmato da un autorità fidata. L'algoritmo di firma usato viene specificato dopo i parametri DH o DHE. In tutti i casi, il client deve avere lo stesso tipo di certificato e deve usare i parametri Diffie-Hellman scelti dal server;
• le CipherSuite inizianti per SSL_DH_anon sono usate per comunicazioni Diffie-Hellman completamente anonime in cui nessuna delle due parti viene autenticata. Tali CipherSuite sono fortemente sconsigliate perchè non garantiscono il controllo delle intrusioni;
• infine vengono elencate due CipherSuite che usano Fortezza come algoritmo per lo scambio di chiavi.

  CipherSuite addizionali possono essere implementate e prese in considerazione dalla Netscape Communications Corporation che agisce come un interim registration office, finchè un ufficio pubblico per gli standard non assumerà tale incarico.

• lista di compression method (compression_methods): è una lista di algoritmi di compressione, in ordine di preferenza, supportati dal client. Se il server non supporta nessuno di quelli specificati dal client, la sessione fallisce.
  
  Un metodo di compressione è un enumerato:

  enum { null(0), (255) } CompressionMethod;

  Il tipo enum specifica una lista di costanti seguite da un numero tra parentesi che indica la numerazione assegnata alle costanti. Si assume che la dimensione del tipo enum sia quella sufficiente ad esprimere il numero d'ordine più alto assegnato ad una costante. Un numero tra parentesi non preceduto da una costante (255 per esempio) è usato per forzare la dimensione del tipo enumerato ad essere tale da poter esprimere almeno tale numero.

La struttura complessiva del messaggio di client hello è quindi la seguente:

struct {
         ProtocolVersion client_version;
         Random random;
         SessionID session_id;
         CipherSuite cipher_suites<0..2¹⁶-1>;
         CompressionMethod compression_methods<0..2⁸-1>;
} ClientHello;

Dopo aver mandato un client hello, il client aspetta un messaggio di server hello, qualsiasi altro messaggio di handshake provocherebbe un errore fatale, tranne un hello request che sarebbe ignorato.

3.1.1.1.3 Server hello

Il messaggio di server hello è inviato dal server al client in risposta al messaggio di client hello.
Il messaggio è composto da:

• protocol version: si tratta di una coppia di byte che rappresenta la versione del protocollo scelto. Questo valore corrisponde al minimo tra la versione del protocollo proposta dal client e la massima supportata dal server;
• random byte: sono dei byte casuali generati dal server che vengono memorizzati nella struttura Random, la cui definizione è uguale a quella usata per memorizzare i byte casuali generati dal client;
• session identifier: identifica la sessione che deve essere avviata. Se l'identificativo di sessione inviato dal client è diverso dal valore zero, il server cercherà nella sua session cache per trovare un valore di riscontro: se lo trova, risponderà con lo stesso valore indicato nel client hello e la vecchia sessione verrà riesumata. Se non lo trova, il server ritornerà un identificativo vuoto per indicare che la sessione non era memorizzata e quindi non può essere ripresa. Nel caso in cui l'identificativo nel client hello è pari a zero il server setterà un nuovo identificativo per la sessione da avviare.
• CipherSuite: questa coppia di byte rappresenta la famiglia di algoritmi scelta dal server tra quelli proposti dal client.
• compression method: rappresenta il metodo di compressione scelto dal server tra quelli proposti dal client.
  
  Per le sessioni riesumate i precedenti due campi corrispondono a quelli della sessione ripresa:

La struttura del server hello è simile a quella del client hello:

struct {

ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;

3.1.1.2 Server certificate

Dopo lo scambio dei messaggi di hello, tra client e server può iniziare una fase di autenticazione tramite lo scambio di un certificato.

Un certificato è una struttura dati composta da dati in chiaro come: una chiave pubblica, una stringa identificativa e dalla firma di un autorità che lega chiave ed identità.

Un esempio di certificato è il Certificato X.509 che è stato definito nel 1988; la versione 3 contiene delle estensioni della 2 aggiunte nel 1995 come gli identificatori chiave e l'uso della chiave.

I campi di un certificato X.509 sono:

• version
• serial number
• signature algorithm ID
• issuer name
• validity period
• subject name
• subject public key information
• issuer unique identifier
• subject unique identifier
• extensions
• firma dei campi precedenti

3.1.1.3 Certificate request

Il messaggio certificate request è inviato dal server al client per richiederne il certificato utilizzato per fornire le informazioni necessarie all'algoritmo di scambio di chiavi.
In particolare il messaggio certificate request contiene una lista di tipi di certificati, ordinati secondo le preferenze del server, ed una lista di nomi di autorità fidate che emettono certificati.
Se un server anonimo richiede l'identificazione del client si verifica un errore fatale.

3.1.1.4 Messaggio di server key exchange

Se il messaggio server certificate non deve essere inviato o se non contiene una chiave pubblica di cifratura, ma solo una per la firma, o infine se il server non ha certificato, quest'ultimo invia il messaggio server key exchange che contiene o i parametri per l’accordo di chiavi Diffie-Hellman o i parametri per una cifratura RSA oppure i parametri per Fortezza. La scelta di uno di questi tre dipende dalla CipherSuite selezionata; se viene inviato uno dei primi due allora ci sarà anche una firma nel caso in cui il server abbia presentato un certificato.

3.1.1.5 Server hello done

Il messaggio di server hello done è inviato dal server al client per indicare che la fase di Hello dell'handshake è completata. Dopo l'invio del messaggio il server si mette in attesa di una risposta dal client, il quale verificherà che il server abbia una valida certificazione, se richiesta, e controlla che i parametri del server hello siano accettabili.

3.1.1.6 Client certificate

Il messaggio client certificate è il primo messaggio che il client può mandare dopo aver ricevuto il messaggio server hello done e la richiesta di un certificato da parte del server. Se non è disponibile un certificato, il client lo segnalerà per mezzo di un messaggio di alert, al quale il server potrebbe rispondere con un errore fatale se è necessaria l'autenticazione del client.

3.1.1.7 Messaggio di client key exchange

Il messaggio client key exchange deve essere inviato obbligatoriamente dal client al fine di fissare il pre master secret la cui struttura è illustrata di seguito:

struct {
         ProtocolVersion client_version;
         opaque random[48];
} PreMasterSecret;

Il pre master secret è utilizzato per calcolare il master secret, cioè un valore condiviso da client e server necessario alla generazione di:

• Chiavi MAC:
  • server_write_MAC_secret: chiave segreta che sarà utilizzata per calcolare il MAC sui blocchi generati nel livello inferiore del protocollo e inviati dal server;
  • client_write_MAC_secret: chiave segreta che sarà utilizzata per calcolare il MAC sui blocchi generati nel livello inferiore del protocollo e inviati dal client;
• Chiavi simmetriche:
  • server_write_key: chiave simmetrica di sessione per i dati cifrati dal server e messi in chiaro dal client;
  • client_write_key: chiave simmetrica di sessione per i dati cifrati dal client e messi in chiaro dal server;
• Vettori di inizializzazione:
  • server_write_IV: sequenza di byte utilizzata per le cifrature in modalità CBC del server;
  • client_write_IV: sequenza di byte utilizzata per le cifrature in modalità CBC del client;

La figura seguente illustra come le chiavi e i vettori di inizializzazione su indicati vengano utilizzati (indichiamo con il colore verde i blocchi contenenti tali valori):

master_secret =MD5(pre_master_secret + SHA('A' + pre_master_secret +
                         ClientHello.random + ServerHello.random)) +
                         MD5(pre_master_secret + SHA('BB' + pre_master_secret +
                         ClientHello.random + ServerHello.random)) +
                         MD5(pre_master_secret + SHA('CCC' + pre_master_secret +
                         ClientHello.random + ServerHello.random));

dove ClientHello.random e ServerHello.random sono i byte casuali generati nella fase iniziale dell'handshake dal client e dal server.

Una volta calcolato il master secret, per generare le chiavi su indicate, bisogna effettuare il seguente calcolo:

key_block =MD5(master_secret + SHA('A' + master_secret +
                         ClientHello.random + ServerHello.random)) +
                         MD5(master_secret + SHA('BB' + master_secret +
                         ClientHello.random + ServerHello.random)) +
                         MD5(master_secret + SHA('CCC' + master_secret +
                         ClientHello.random + ServerHello.random)) + [. . .];

finchè non viene generato un numero abbastanza grande di byte necessari alla formazione di tutte le chiavi.

Infine il key_block viene partizionato in:

client_write_MAC_secret[CipherSpec.hash_size];
server_write_MAC_secret[CipherSpec.hash_size];
client_write_key[CipherSpec.key_size];
server_write_key[CipherSpec.key_size];
client_write_IV[CipherSpec.IV_size];      /* ciphers non esportabili */
server_write_IV[CipherSpec.IV_size];     /* ciphers non esportabili */

la parte restante di key_block che non viene utilizzata da nessuna chiave verrà scartata.

Algoritmi di crittografia esportabili (per cui il valore CipherSpec.is_exportable è true) richiedono un'elaborazione addizionale per derivare i valori finali delle chiavi:

final_client_write_key = MD5(client_write_key +
                         ClientHello.random + ServerHello.random);
final_server_write_key = MD5(server_write_key +
                         ServerHello.random + ClientHello.random);

client_write_IV = MD5(ClientHello.random + ServerHello.random);
server_write_IV = MD5(ServerHello.random + ClientHello.random);

Riassumendo lo schema del processo di generazione delle chiavi è il seguenete:

Il contenuto del messaggio di client key exchange dipende dall'algoritmo per lo scambio di chiavi specificato nella CipherSuite:

• RSA: il client genera il pre master secret di 48 byte, lo cifra con la chiave pubblica presa dal certificato del server o con una chiave temporanea RSA presa dal messaggio server key exchange e spedisce il risultato in un messaggio cifrato, che ha la seguente struttura:

  struct {
           public-key-encrypted PreMasterSecret pre_master_secret;
  } EncryptedPreMasterSecret;

  Il server userà la sua chiave privata per mettere in chiaro il pre master secret, come indicato in figura:
  
  

  
  

• Fortezza KEA: il client deriva una chiave simmetrica, denominata Token Encryption Key (TEK), usando Fortezza Key Exchange Algorithm (KEA). In tali calcoli sono usate sia la chiave pubblica del server, ricavata dal suo certificato, sia i parametri privati del client. Il client genera la chiave di sessione, la protegge usando il TEK e la spedisce al server, insieme al vettore di inizializzazione (IV) usato nel CBC; quindi genera un pre master secret di 48 byte, lo cifra usando il TEK e lo spedisce. Il server metterà in chiaro il pre master secret e lo convertirà in master secret; che in questo caso verrà usato solo per i calcoli del MAC.

• Diffie-Hellman: è usato un convenzionale algoritmo Diffie-Hellman per negoziare una chiave che sarà usata come pre master secret.
  

la struttura del messaggio di client key exchange è la seguente:

struct {
            select (KeyExchangeAlgorithm) {
                case rsa: EncryptedPreMasterSecret;
                case diffie_hellman: ClientDiffieHellmanPublic;
                case fortezza_dms: FortezzaKeys;
            } exchange_keys;
} ClientKeyExchange;

3.1.1.8 Certificate verify

Se il client in precedenza ha inviato un certificato, ora col messaggio certificate verify  invierà un hash dei messaggi di handshake, scambiati a partire da client hello fino a questo punto, e della master secret, in modo che il server possa verificarne l’autenticità.

La struttura di certificate verify è la seguente:

struct {
            select(SignatureAlgorithm) {
                case anonymous: struct { };
                case rsa:
                    opaque md5_hash[16];
                    opaque sha_hash[20];
                case dsa:
                    opaque sha_hash[20];
            };
} Signature;

struct {
          Signature signature;
} CertificateVerify;

CertificateVerify.signature.md5_hash =
      MD5(master_secret + pad_2 + MD5(handshake_messages + master_secret + pad_1));
Certificate.signature.sha_hash =
      SHA(master_secret + pad_2 +  SHA(handshake_messages + master_secret + pad_1));

dove :
pad_1  è il carattere 0x36 ripetuto 48 volte per l'MD5 o 40 volte per SHA.
pad_2  è il carattere  0x5c ripetuto 48 volte per l'MD5 o 40 volte per SHA.

3.1.1.9 Change CipherSpec

Questo messaggio ha lo scopo di segnalare i cambiamenti delle strategie di cifratura. Esso è inviato sia dal client che dal server per comunicare alla parte ricevente che i dati seguenti saranno protetti dalle chiavi e dal CipherSpec appena negoziato. Il client invia un messaggio di change CipherSpec dopo l'invio dei messaggi di key exchange e certificate verify della fase di handshake, ed il server ne invia uno dopo che il messaggio di key exchange è stato ricevuto dal client con successo. Quando si riprende una vecchia sessione il messaggio di change CipherSpec è inviato dopo i messaggi di Hello.

3.1.1.10 Finished

Questo messaggio è sempre mandato dopo un messaggio change CipherSpec per verificare che i processi di scambio di chiavi e autenticazione abbiano avuto successo, se non è preceduto da questo si verifica un errore fatale. Questo è il primo messaggio protetto con l'algoritmo negoziato.
Adesso la fase di handshake è completata ed il client ed il server possono cominciare a scambiare i dati del livello applicazione.
Il messaggio finished si ricava dal valore di master secret applicando a quest'ultimo la composizione di MD5 e SHA come indicato di seguito:

struct {
         opaque md5_hash[16];
         opaque sha_hash[20];
} finished;

finished.md5_hash = MD5(master_secret + pad2 + MD5(handshake_messages + Sender +
                                   + master_secret + pad1));
finished.sha_hash = SHA(master_secret + pad2 + SHA(handshake_messages + Sender +
                                   +  master_secret + pad1));

enum { client(0x434C4E54), server(0x53525652) } Sender;

Il messaggio di finished mandato dal server conterrà nel campo Sender: Sender.server; quello mandato dal client Sender.client.

Illustriamo di seguito lo schema del messaggio finished :

In linea generale il protocollo SSL prende i messaggi che devono essere trasmessi, li frammenta in blocchi di dati (record di 214 byte o meno), opzionalmente li comprime, applica un MAC (Message Authentication Code che viene utilizzato per il protocollo dell’integrità dei dati), li cifra, e trasmette il risultato. I dati ricevuti vengono decifrati, verificati, decompressi, e riassemblati, quindi vengono trasmessi al livello più  alto.

3.2.1 SSLPlaintext record

I blocchi creati dal Protocollo SSL Record sono organizzati in record SSLPlaintext la cui struttura è illustrata di seguito.

Il SSLPlaintext record utilizza le seguenti strutture:

struct {
         uint8 major, minor; /* uint8 indica un unsigned int di 8 bit */
} ProtocolVersion;

enum {
         change CipherSpec(20), alert(21), handshake(22), application_data(23), (255);
} ContentType;

Ricordiamo che la presenza di (255) nel caso in esame, comporta che il tipo ContentType sarà rappresentato con 1 byte, necessario a rappresentare il numero 255, anche se in realtà un dato di tipo ContentType può assumere solo 4 valori: 20, 21, 22 e 23

Pertanto la definizione di SSLPlaintext è:

struct {
         ContentType type;
         ProtocolVersion version;
         uint16 length;
         opaque fragment[SSLPlaintext.length];
} SSLPlaintext;

Ricordiamo che con il tipo opaque indichiamo un byte che SSL non può risolvere ulteriormente, né come numero, né come carattere, in quanto tale byte fa parte del flusso di dati di livello applicazione trattato in modo trasparente da SSL.

I campi della struttura SSLPlaintext hanno il seguente significato:

• type: indica quale tra i protocolli di livello più alto, cioè SSL Handshake o HTTP, è usato per processare il frammento.
• version: la versione del protocollo impiegato, nel nostro caso SSL v3.0.
• length: la lunghezza in byte del frammento SSLPlaintext che segue. Non può eccedere 2¹⁴ byte.
• fragment: i dati provenienti dal livello applicazione. Questi dati sono trasparenti e considerati come un blocco indipendente per essere poi trattati dal protocollo di livello più alto specificato nel campo type.

3.2.2 Compressione e Decompressione del SSLPlaintext record

Tutti gli SSLPlaintext record sono compressi. L'algoritmo di compressione trasforma un SSLPlaintext record in un SSLCompressed record definito di seguito:

struct {
         ContentType type; /* come SSLPlaintext.type */
         ProtocolVersion version; /* come SSLPlaintext.version*/
         uint16 length;
         opaque fragment[SSLCompressed.length];
} SSLCompressed;

Significato dei campi:

• length: la lunghezza in byte del frammento SSLCompressed. La lunghezza non deve eccedere 2¹⁴ + 1024.
• fragment: la forma compressa del SSLPlaintext.fragment.

La compressione deve essere senza perdita di dati e non può aumentare la lunghezza del contenuto più di 1024 byte. Se la decompressione del campo fragment relativo al SSLCompressed record fosse lungo più di 2¹⁴ byte, verrà segnalato un errore irreversibile.

3.2.3 Protezione degli SSLCompressed record

Tutti i record sono protetti usando gli algoritmi di crittografia e MAC definiti nel corrente CipherSpec. Le tecniche usate per le operazioni di crittografia e di MAC trasformano una struttura SSLCompressed in una SSLCiphertext. La decifratura inverte tale trasformazione. Le trasmissioni includono anche un numero di sequenza, in modo che i messaggi persi, alterati o intrusi siano rilevabili.

La struttura SSLCiphertext è la seguente:

struct {
         ContentType type;
         ProtocolVersion version;
         uint16 length;
         select (CipherSpec.cipher_type) {
             case stream: GenericStreamCipher;
             case block: GenericBlockCipher;
         } fragment;
} SSLCiphertext;

Il significato dei campi è il seguente:

• type: come il SSLCompressed.type .
• version: come il SSLCompressed.version .
• length: la lunghezza in byte del SSLCiphertext.fragment non può eccedere 2¹⁴ + 2048.
• fragment: la forma cifrata del SSLCompressed.fragment, incluso il MAC. Vengono selezionate per tale campo due strutture diverse a seconda che sia stato scelto l'uso di un algoritmo di crittografia che lavora su tutto lo stream di bit dei dati, GenericStreamCipher, o su dei blocchi, GenericBlockCipher.

3.2.3.1 CBC block cipher

Gli algoritmi block cipher, come RC4 o DES, trasformano la struttura SSLCompressed.fragment in un blocco SSLCiphertext.fragment tramite la seguente struttura:

block-ciphered struct {
         opaque content[SSLCompressed.length];
         opaque MAC[CipherSpec.hash_size];
         uint8 padding[GenericBlockCipher.padding_length];
         uint8 padding_length;
} GenericBlockCipher;

dove:
padding: sono dei byte aggiuntivi utilizzati per forzare la lunghezza del plaintext ad essere un multiplo della lunghezza dei blocchi cifrati dall'algoritmo di crittografia.
padding_length: è la lunghezza del padding che deve essere minore di quella del blocco cifrato; questo parametro deve essere tale che la dimensione totale della struttura GenericBlockCipher sia un multiplo della lunghezza dei blocchi cifrati dall'algoritmo usato. La lunghezza dei dati cifrati è complessivamente la somma della SSLCompressed.length, CipherSpec.hash_size, padding_length più uno.

Il MAC di ogni blocco è così generato:

hash (MAC_write_secret + pad_2 + hash (MAC_write_secret + pad_1 + seq_num +length + content));

dove:
" + " denota la concatenazione.
pad_1: è il carattere 0x36 ripetuto 48 volte per MD5 o 40 volte per il SHA.
pad_2: il carattere 0x5c ripetuto lo stesso numero di volte del precedente.
seq_num: il numero di sequenza del messaggio.
hash: l'algoritmo hash definito nella CipherSpec.
MAC_write_secret: è la sequenza segreta usata come chiave per le operazioni di MAC sui dati inviati.

Inseriamo ora un grafico indicante la velocità delle possibili CipherSpec (algoritmi per la cifratura e per il MAC dei record) e dell'algoritmo per la compressione:

Il test sulla velocità delle ChiperSpec è stato effettuato su un computer con processore Pentium II a 333 MHz e sistema operativo Linux.

3.3 Protocollo di Alert

I messaggi di alert sono utilizzati per notificare eccezioni che possono avvenire nella comunicazione. Essi contengono il livello di severità e una descrizione dell'evento occorso. Ad esempio un messaggio con livello "fatal" si risolve con l'immediata terminazione della sessione. Come gli altri messaggi anche quelli di alert sono cifrati e compressi.

Le strutture usate sono le seguenti:

enum {
          warning(1), fatal(2), (255)
} AlertLevel;

enum {
         close_notify(0), unexpected_message(10), bad_record_mac(20), decompression_failure(30),
            handshake_failure(40), no_certificate(41), bad_certificate(42), unsupported_certificate(43),
            certificate_revoked(44), certificate_expired(45), certificate_unknown(46), illegal_parameter(47), (255)
} AlertDescription;
 

struct {
         AlertLevel level;
         AlertDescription description;
} Alert;

I messaggi di alert definiti nella struttura AlertDescription sono descritti di seguito:

close_notify: notifica al ricevente che il mittente non trasmetterà più su quella connessione.
unexpected_message: un messaggio inappropriato è stato ricevuto. Questo tipo di allerta è sempre fatale.
bad_record_mac: questa allerta è spedita quando un record è ricevuto con un errato MAC. Questo tipo di allerta è sempre fatale.
decompression_failure: la funzione di decompressione ha ricevuto un errato input, ad esempio dati che si espandono oltre la lunghezza loro assegnata. Questo tipo di allerta è sempre fatale.
handshake_failure: indica che il mittente è incapace di negoziare un set accettabile di parametri di sicurezza tra quelli possibili. Questo tipo di allerta è sempre fatale.
no_certificate: può essere mandato in risposta ad un certificate request se non è disponibile una certificazione appropriata.
bad_certificate: in caso di certificazione errata (ad esempio se contiene una firma che non è verificata correttamente).
unsupported_certicate: se una certificazione è di un tipo non supportato.
certificate_revoked: una certificazione è stata revocata dal suo firmatario.
certificate_expired: una certificazione è scaduta o attualmente non valida.
certificate_unknown: qualche altro non specificato problema è sorto nel processare la certificazione.
illegal_parameter: un campo del handshake è di dimensione errata o inconsistente con altri campi. Questo tipo di allerta è sempre fatale.

3.3.1 Allerta di chiusura

Per chiudere una connessione, il client ed il server devono avviare lo scambio dei messaggi di chiusura. In particolare il messaggio close notify notifica al ricevente che il mittente non trasmetterà più su quella connessione. La sessione diviene non riesumabile se la connessione è terminata senza il dovuto messaggio close_notify con livello warning.

4 Utilizzo di SSL

Per sfruttare la protezione offerta da SSL è necessario che un sito web disponga di un server in cui sia integrata la tecnologia SSL. Attualmente l'implementazione SSLref v3.0b1 della Netscape Communications Corporation è multipiattaforma anche se sono differenziate le versioni per Windows 95/NT e per Solaris, in forma di pre-build file.
Le versioni precedenti la data del 12 Gennaio 2000 destinate alla vendita negli USA provvedono un più alto livello di sicurezza a causa della vecchia legislazione USA in materia di export di algoritmi di crittografia. Il 12 Gennaio 2000 invece il dipartimento del Commercio Bureau of Export Administration ( BXA ) annuncia il nuovo regolamento per le esportazioni di prodotti crittografici: alle compagnie statunitensi viene consentita l'esportazione di ogni prodotto crittografico alle società straniere a loro associate senza alcuna revisione. Persistono, comunque, restrizioni per le esportazioni verso: Cuba, Iran, Iraq, Libya, North Korea, Sudan, and Syria. Le società di telecomunicazioni e gli internet provider possono utilizzare, senza alcuna restrizione, ogni tipo di prodotto se destinato all'utenza pubblica, invece, è necessaria una licenza per offrire i propri servizi all'utenza governativa, come ad esempio la gestione di una rete privata virtuale per un'agenzia governativa. Pertanto il BXA dovrà classificare i prodotti già precedentemente esportati, ed ora modificati revisionando la loro funzionalità. Il codice sorgente disponibile al pubblico, e per il quale non è necessario alcun pagamento per la licenza, può essere esportato senza revisioni tecniche. Tutti gli altri tipi di codice sorgente possono essere esportati dopo un periodo di trenta giorni necessario al BXA per eseguire una revisione tecnica.
Per Unix, Windows 3.1/9x/NT e Solaris esiste la versione SSLLeay 0.9.0 che implementa SSLv2, SSLv3.0, TLSv1 oltre librerie matematiche che comprendono algoritmi come DES, RSA, DSA, Diffie-Hellman e funzioni hash come MD5 e SHA oltre che programmi per la gestione dei certificati. Questo pacchetto software che è free sia per uso privato che commerciale, ha permesso lo sviluppo di un progetto che prevede la cooperazione di volontari che usano internet per comunicare tra loro al fine di implementare una versione open di SSL (OpenSSL).
Con questi mezzi è possibile usare, per esempio, https, cioè il protocollo http con SSL, e scambiare informazioni con un client per mezzo di https. Poichè http+SSL e http sono protocolli differenti ed usano porte diverse, lo stesso sistema server può far girare contemporaneamente sia il server http+SSL che quello http. Questo permette ad un server di offrire agli utenti sia informazioni non sicure che informazioni sicure. I client browser dovranno quindi supportare il protocollo SSL ed il nuovo metodo di accesso URL https per connettersi con un server che usa SSL. Per utilizzare https si dovrà usare "https://" per gli URL http con SSL, mentre si continuerà ad usare "http://" per gli URL senza SSL. La porta di default per "https" è la numero 443, come stabilito dalla Internet Assigned Numbers Authority.
Nel browser Netscape Navigator di default appare una icona nell'angolo in basso a sinistra: se è visibile un lucchetto aperto su sfondo celeste, come quello illustrato di seguito, allora la connessione non è sicura

mentre se il lucchetto è chiuso su uno sfondo giallo allora la connessione è sicura.

Inoltre la voce "Strumenti -> Info Sicurezza " nel menù "Comunicator" mostra una dialog box che contiene informazioni sullo stato della connessione, il livello di crittografia usato e l'identità del server, ricavata dal suo certificato. A queste informazioni è possibile accedere direttamente dalla barra delle applicazioni mediante il tasto "Sicurezza" illustrato di seguito:

Indirizzi utili

Specifiche del protocollo SSL v3.0:

http://home.netscape.com/eng/ssl3/draft302.txt

http://developer.netscape.com/docs/manuals/security/sslin/contents.htm

Per un'accurata analisi del protocollo SSL è disponibile off line il file: ssl-revised.pdf

Specifiche del protocollo OpenSSL:

http://www.openssl.org/

Specifiche del protocollo TLS v1:

http://www.ietf.org/html.charters/tls-charter.html

Specifiche del protocollo SSLLeay:

Informazioni utili su SSLLeay

L'ultima versione disponibile di SSLLeay, la SSLeay-0.9.0, è disponibile insieme alle precedenti sul sito:

ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL .

Applicazioni basate su SSL:

SSLtelnet Secure telnet basato sul Secure Socket Layer protocol. Disponibile al: ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps.

SSLftp Secure ftp basato sul Secure Socket Layer protocol. Disponibile al: ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps.