2. Introduzione SSL

SSL (Secure Socket Layer protocol) è un protocollo aperto e non proprietario. 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:

• Sicurezza 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.

Il protocollo SSL è composto da (vedi figura seguente):

• 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.

 

 

2.1 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.

2.1.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:

1.  Al server di autenticarsi al client usando una tecnica a chiave pubblica,

2. 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.

3.  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.

1.  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.

2.  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, 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:

I messaggi contrassegnati con ”*” non sono obbligatori ed il messaggio change CipherSpec non fa parte del protocollo handshake ma viene inviato in quella posizione.

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:

Le fasi della riesumazione sono:

1. Il client manda un client hello usando il Session ID della sessione da riesumare;

2. Il server allora controlla la sua session cache per trovare una corrispondenza: se questa è trovata il server manda un server hello con lo stesso Session ID;

3. Adesso sia il client che il server devono mandare un messaggio di change CipherSpec e procedere direttamente fino al messaggio di finished;

4. Una volta che il ripristino è completo, il client ed il server possono iniziare. Se il server non trova una corrispondenza di Session ID nella propria session cache, allora genererà un nuovo Session ID, e verrà eseguito un handshake completo.

 

---

2.2 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: