Copyrigtht © 1986 Universita' di Firenze. All rights reserved.
Free license available.
Indice:
3.0 Introduzione.
3.1 Utilizzazione di SSL.
3.2 Obiettivi.
3.3 Il protocollo SSL: soluzioni tecniche
3.4 Crittografia. 3.5 Considerazioni finali e debolezze di SSL. Links alle fonti d'informazioni su SSL.Questo documento illustra le specifiche della versione 3.0 del Secure Socket Layer protocol (SSL-v3.0) di Netscape Communication Corporation, (http://www.netscape.com) un protocollo che garantisce la privacy delle comunicazioni su Internet; esso permette infatti alle applicazioni client/server di comunicare in modo da prevenire le intrusioni, le manomissioni e le falsificazioni dei messaggi.
Il protocollo SSL provvede alla sicurezza del collegamento garantendo tre funzionalità fondamentali:
Nota: Per una descrizione degli algoritmi di crittografia citati vedere l' appendice.
SSL è un protocollo aperto e non proprietario; è stato proposto da Netscape Communications al W3 Consortium come un possibile futuro approccio standard alla sicurezza per i browsers WWW e per i servers.
Lo scopo primario del SSL Protocol è fornire riserbo ed affidabilità alle comunicazioni. Il protocollo è composto da due strati (vedi figura 5): a livello più basso, interfacciato su di un protocollo di trasporto affidabile come il TCP, c'è il protocollo SSL Record. Questo è usato per l'incapsulamento dei vari protocolli di livello superiore. Sul protocollo SSL Record si interfaccia l'SSL Handshake Protocol che 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 applicazione trasmetta o riceva il suo primo byte. Un vantaggio del SSL è la sua indipendenza dal protocollo di applicazione: un protocollo di livello più alto può interfacciarsi sul protocollo SSL in modo trasparente.
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 C., disponibile al sito http://home.netscape.com/newsref/std/sslref.html , è mulipiattaforma anche se sono differenziate le versioni per Windows 95/NT e per Solaris, in forma di pre-build file. Le versioni destinate alla vendita negli USA prevedono un più alto livello di sicurezza, mentre, a causa della legislazione USA in materia di export di algoritmi di crittografia, le versioni internazionali sono ristrette all'uso dell'algoritmo RC4 con chiavi di 40 bits (vedi appendice sugli algoritmi di crittografia), come implementato in Netscape Navigator. Da ricerche in Internet dell'ultimo minuto risulta che il server Netscape Commerce Server supporta SSLv2.0, mentre il nuovo Netscape Enterprise integra SSLv3.0; la politica di diffusione voluta dalla stessa Netscape Communication Inc. rende disponibili questi e tutti gli altri prodotti software a studenti, universit€ ed altre istituzioni non commerciali in modo free al sito http://test-drive.netscape.com/edu_drive/index.html. Anche il client deve supportare SSL per poter stabilire una connessione sicura con un server SSL: Netscape Navigator lo supporta dalla versione 0.93.
Per Unix e Windows 3.1/95/NT esiste la versione SSLLeay 0.6.0 che implementa SSLv2.0, free sia per uso privato che commerciale, disponibile in forma di pre-built DLL e di codice sorgente VisualC++ : include una implementazione di DES tra le più veloci, oltre agli algoritmi di crittografia più comuni, IDEA, RC4, RSA, e MD5 (vedi appendice).
Inoltre è disponibile Secure HTTP e SSL Toolkit commercializzato da Terisa: "http://www.terisa.com/prod/prod.html" .
Web server sicuri di IBM sono distribuiti per le maggiori piattaforme al sito: http://www.ics.raleigh.ibm.com/.
Con questi mezzi è possibile usare, per esempio, https, cioè http con SSL, e scambiare informazioni con un client per mezzo di https. Poichè http+SSL e http sono differenti protocolli ed usano porte diverse, lo stesso sistema server può far girare contemporaneamente sia il server http+SSL che quello http. Ciò significa che un server può offrire alcune informazioni a tutti gli utenti senza sicurezza, ed altre solo in modo sicuro: ad esempio un catalogo può essere "non sicuro" mentre gli ordini ed i pagamenti devono essere protetti.
Riferendoci sempre a Netscape Navigator, illustriamo le modalità
con cui è possibile usare SSL, riportando come esempio l'esperienza
del collegamento alla pagina http://www.cyberpi.com/
dove esiste un link ad una pagina di ordinazione dei servers prodotti da Cyber Presence, protetta
da SSL.
Ribadiamo a tal fine che il browser puø essere qualunque, purch‰ supporti il protocollo SSL
e, quindi, il nuovo metodo di accesso URL https
per connessioni con un server che usa SSL. Https è
il protocollo che si ottiene interfacciando http su SSL: 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.
Per default una "security colorbar"
appare in alto a destra in ogni finestra di Netscape Navigator:
se la barra è grigia allora il documento che stiamo ricevendo
non è "sicuro", mentre se la barra è blu,
il documento corrente è sicuro, cioè trasferito
in modo protetto dalla crittografia. Una icona all'angolo in basso
a sinistra mostra la stessa situazione: se è visibile una
chiave rotta su sfondo grigio allora la connessione non è
sicura, mentre se la chiave è intera su sfondo blu la connessione
è sicura. Inoltre la voce "Document Information"
nel menù "File" mostra una dialog box che contiene
informazioni sullo stato della connessione: il livello di crittografia
usato, che per adesso, in accordo alle leggi sull' export degli
USA, è ristretto all'uso di chiavi di soli 40 bit con algoritmo
RC4; l'identità del server, ricavata dal suo certificato.
Gli scopi del Protocollo SSL v3.0, in ordine di priorità, sono:
3.3 Il protocollo SSL: soluzioni tecniche.
Il protocollo SSL è un protocollo a livelli; ad ogni livello i messaggi possono includere campi per la lunghezza, la descrizione ed il contenuto. SSL procede sui messaggi da trasmettere nel modo seguente: li frammenta in blocchi adeguati, eventualmente comprime i dati, applica un MAC, crittografa e infine trasmette il risultato. I dati ricevuti, viceversa, sono messi in chiaro, verificati, scompattati e riassemblati e, quindi, consegnati ai client di livello superiore.
In particolare SSL prevede un handshake di "sicurezza"
usato per iniziare la connessione TCP/IP: il risultato
di tale handshake è 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
alla cifratura (e/o alla messa in chiaro) della sequenza
di bytes del protocollo applicazione usato, ad esempio HTTP, SHTTP,
NNTP o Telnet. Ciò significa che tutte le informazioni
sia nell'HTTP request che nell'HTTP response sono completamente
crittografate, incluso l'URL richiesto dal client, qualsiasi contenuto
di forms compilati (quindi anche eventuali numeri di carte
di credito...), ogni informazione sulle autorizzazioni all'accesso
come usernames e passwords, e tutti i dati risposti dal server
al client.
3.3.1 Stato della sessione e della connessione.
E' responsabilità dell'SSL Handshake protocol coordinare gli stati del client e del server, permettendo così ai sistemi operativi di ognuno di operare in modo consistente, nonostante lo stato non sia esattamente parallelo. Logicamente lo stato è rappresentato in modo doppio: una volta come lo stato operativo corrente, e, durante la fase di handshake, come lo stato in attesa; inoltre sono mantenuti separati gli stati di lettura da quelli di scrittura. Quando il client o il server riceve un messaggio di change cipher spec, (vedi paragrafo 3.3.3) esso copia lo stato di lettura in attesa nello stato di lettura corrente. Quando il client o il server spedisce un messaggio di change cipher spec, copia lo stato in attesa di scrittura nello stato corrente di scrittura. Quando la negoziazione iniziale (handshake) è completa il client ed il server si scambiano il messaggio di change cipher spec ed iniziano a comunicare usando la nuova cipher spec stabilita nel modo illustrato sopra. Una sessione SSL può includere più di una connessione sicura; inoltre le applicazioni possono avere più sessioni simultanee.
Lo stato della sessione include i seguenti elementi:
Lo stato della connessione include i seguenti elementi:
Il Record layer del protocollo SSL riceve i dati dai livelli superiori senza interpretarli, in forma di blocchi non vuoti di dimensione arbitratria.
3.3.2.1 Frammentazione.
Il Record layer frammenta i blocchi di informazioni in SSLPlaintext records, di dimensione massima di 214 bytes, la cui struttura è illustrata di seguito. Le divisioni del messaggio del client possono non essere rispettate nel record layer: per esempio messaggi multipli del client dello stesso ContentType possono essere fusi in un unico SSLPlaintext record.
Per descrivere le strutture dati useremo una pseudo-codifica molto simile al linguaggio 'C' con l'aggiunta di note esplicative laddove ci allontaneremo dallo standard del 'C'.
Il SSLPlaintext record ha la struttura seguente:
struct {
uint8 major, minor; /* uint8
indica un unsigned int di 8 bit
} ProtocolVersion;
enum {
change_cipher_spec(20), alert(21),
handshake(22), application_data(23), (255)
} ContentType;
/* N.B. 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. Nel caso in esame la presenza
di (255) 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 */
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[SSLPlaintext.length];
} SSLPlaintext;
/* N.B. 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 dal SSL. */
I campi della struttura SSLPlaintext hanno il seguente significato:
Da notare che dati di differenti ContentTypes possono essere alternati.
I dati dell'applicazione hanno in genere la più bassa priorità
di trasmissione rispetto agli altri ContentTypes.
3.3.2.2 Compressione e Decompressione del Record.
Tutti i records sono compressi tramite un algoritmo definito nello stato corrente della sessione. C'è sempre un algoritmo di compressione attivo anche se all'inizio è definito come CompressionMethod.null. L'algoritmo di compressione trasforma una struttura SSLPlaintext in una SSLCompressed structure. Le funzioni di compressione cancellano le loro informazioni di stato quando la CipherSpec è rimpiazzata.
Nota: la CipherSpec è parte dello stato della sessione descritto nel paragrafo 3.3.1.
La compressione deve essere senza perdita e non può aumentare
la lunghezza del contenuto più di 1024 bytes. Se la decompressione
incontra un SSLCompressed.fragment che scompattato fosse
lungo più di 214 bytes, deve segnalare un fatale
decompression_failure alert (paragrafo 3.3.4.2).
La struttura corrispondente è la seguente:
struct {
ContentType type; /* come SSLPlaintext.type */
ProtocolVersion version; /* come SSLPlaintext.version*/
uint16 length;
opaque fragment[SSLCompressed.length];
} SSLCompressed;
Significato dei campi:
Note: l'operazione CompressionMethod.null è
un'operazione d'identità che non altera alcun campo. La
funzione di decompressione è responsabile del controllo
di eventuali buffer overflows interni.
3.3.2.3 Protezione utile del Record e CipherSpec.
Tutti i records sono protetti usando gli algoritmi di crittografia e MAC definiti nel corrente CipherSpec. C'è sempre un CipherSpec attivo, anche se inizialmente è posto uguale a SSL_NULL_WITH_NULL_NULL che non fornirebbe alcuna sicurezza.
Quando l'handshake è completato, le due parti hanno condiviso le stringhe segrete che sono usate per cifrare i records e computare i codici di autenticazione con chiave dei messaggi , (MACs) sulla base dei loro contenuti. Le tecniche usate per le operazioni di crittografia e di MAC sono stabilite nel CipherSpec.cipher_type; tali tecniche 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:
3.3.2.3.1 Cifratura standard con algoritmi che lavorano sull'intero
stream.
Gli algoritmi stream ciphers, incluso il BulkCipherAlgorithm.null, convertono le strutture SSLCompressed.fragment in stream SSLCiphertext.fragment e viceversa, usando la struttura:
stream-ciphered struct {
opaque content[SSLCompressed.length];
opaque MAC[CipherSpec.hash_size];
} GenericStreamCipher;
N.B. Le operazioni di crittografia da compiere sulle strutture sono designate tramite uno
dei seguenti prefissi: digitally-signed, stream-ciphered, block-ciphered, e
public-key-encrypted. Tali prefissi sono posti prima della descrizione del tipo
della struttura; nel caso della struttura GenericStreamCipher sopra definita, abbiamo
preposto "stream-ciphered", indicando cosŒ che essa verr€ cifrata con un algoritmo che processa
l'intero flusso dei dati. Analogamente per la struttura GenericBlockCipher useremo
il prefisso "block-ciphered".
hash (MAC_write_secret + pad_2 + hash (MAC_write_secret + pad_1 + seq_num +length + content));
ove:
Da notare che il MAC è calcolato prima della cifratura:
la stream cipher crittografa l'intero blocco incluso il MAC. Se
il campo CipherSuite, che definiremo più avanti è
SSL_NULL_WITH_NULL_NULL, la cifratura lascia inalterata
la struttura: i dati non sono cifrati ed il MAC vale zero, ovvero
non è usato MAC. Infine la SSLCiphertext.lenght = SSLCompressed.lenght
+ CipherSpec.hash_size.
Gli algoritmi block ciphers, come RC2 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_lenght;
} GenericBlockCipher;
dove:
Nota: la lunghezza dei dati cifrati è complessivamente
la somma della SSLCompressed.lenght, CipherSpec.hash_size,
padding_lenght più uno.
3.3.3 Il protocollo Change cipher spec.
Questo protocollo è finalizzato a segnalare le transizioni nelle strategie di crittografia. Il protocollo consiste di un singolo messaggio, che è cifrato e compresso secondo il Current (e non il pending) CipherSpec. Il messaggio consiste di un singolo byte di valore uno (ciò spiega la lunghezza dei dati cifrati!).
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
Il messaggio di change cipher spec è mandato sia
dal client che dal server per notificare all'altro che da quel
momento in poi i records saranno protetti usando le nuove, appena
negoziate CipherSpec e chiavi. La ricezione di questi messaggi
causa al ricevente la copia del pending read state nel
current read state: infatti sia il server che il client
mantengono separato questo doppio stato. Quando il client o il
server manda un messaggio di change cipher spec, esso copia
il pending write state nel current write state.
Il client manda allora un messaggio di change cipher spec seguente
i messaggi di handshake key exchange and certificate
verify, ed il server ne manda uno dopo aver processato con
successo il messaggio di key exchange ricevuto dal client.
Quando l'handshake è completato il client ed il server
si scambiano i messaggi di change cipher spec visti sopra
ed iniziano a comunicare usando le nuove proprietà
appena concordate. Un messaggio di change cipher spec inaspettato
provoca un unexpected_message alert (vedi sezione 3.3.4.2).
Quando si riesuma una sessione, il messaggio di change
cipher spec è spedito subito dopo il messaggio di hello.
Uno dei tipi di contenuto supportato dal livello SSL Record è l' alert. I messaggi di alert comunicano la severità del messaggio e una descrizione dell'allerta: un messaggio con livello fatal si risolve con la immediata terminazione della connessione. In questo caso le altre connessioni nella stessa sessione possono essere continuate, ma l'identificativo della sessione deve essere invalidato in modo che non siano stabilite nuove connessioni. Come gli altri messaggi anche quelli di alert sono cifrati e compressi come specificato nello stato corrente della connessione.
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;
Il client e il server devono comunicarsi che la connessione sta
terminando per evitare un attacco. Entrambi possono iniziare lo
scambio dei messaggi di chiusura. In particolare il messaggio
close_notify che notifica al ricevente che il mittente
non trasmetterà più su quella connessione. La sessione
diviene non riesumabile se qualche connessione è terminata
senza il dovuto messaggio close_notify con livello warning.
Il trattamento degli errori nell'SSL Handshake protocol è molto semplice. Quando un errore è rivelato, la parte che lo ha rivelato manda un messaggio all'altra; dopo la trasmissione/ricezione di un messaggio di fatal alert, entrambe le parti immediatamente chiudono la connessione. Sia il server che il client sono obbligati a cancellare ogni identificatore di sessione, chiave, e altri segreti associati con la connessione fallita.
Sono definiti i seguenti messaggi di allerta per errore:
3.3.5 Handshake protocol overview.
I parametri per la crittografia che compongono lo stato della sessione sono prodotti dal SSL Handshake Protocol, che opera interfacciandosi in basso con il SSL Record Layer. Quando un client ed un server SSL iniziano a comunicare, concordano sulla versione del protocollo, scelgono gli algoritmi di crittografia, opzionalmente si autenticano l'un l'altro, e usano la crittografia a chiave pubblica per generare dati segreti condivisi. Questi processi sono eseguiti nel handshake protocol, che può essere descritto cosi:
il client spedisce un messaggio di client hello al quale il server deve rispondere con un messaggio di server hello, altrimenti un errore fatale si verifica e la connessione fallisce. I messaggi client hello e server hello sono usati per stabilire le prestazioni di sicurezza ottenibili fra client e server; questi messaggi stabiliscono i seguenti attributi: protocol version, session ID, cipher suite e compression method. Inoltre, due valori casuali sono generati e scambiati: ClientHello.random e ServerHello.random.
Di seguito al messaggio di hello il server spedisce il suo certificato se questo deve essere autenticato; inoltre un messaggio di server key exchange può essere spedito, se è richiesto, ad esempio se il server non ha certificato, o se il suo certificato è solo per la firma. Se il server è autenticato, può richiedere un certificato dal client se ciò è in accordo con la cipher suite scelta.
Adesso il server manderà il messaggio di server hello done, indicando che la fase hello-message dell' handshake è completa, ed attenderà una risposta dal client.
Se il server ha mandato un messaggio di certificate request,
il client deve spedire o un certificate message o una no
certificate alert. Il messaggio di client key exchange
viene mandato adesso, il cui contenuto dipende dall'algoritmo
a chiave pubblica selezionato con il client hello ed il server
hello. Se il client ha spedito un certificato con abilitazione
alla firma, allora un messaggio di certificate verify è
spedito per verificare esplicitamente il certificato.
A questo punto un messaggio di change cipher spec è mandato dal client, che copia il pending Cipher Spec nel current Cipher Spec. Il client manda immediatamente il messaggio finished usando i nuovi algoritmi, chiavi e stringhe segrete concordate . Il server risponde con un messaggio di change cipher spec, copia il pending Cipher Spec nel current Cipher Spec, e spedisce il suo messaggio finished in accordo con la nuova Cipher Spec. Adesso la fase di handshake è completata ed il client ed il server possono cominciare a scambiare dati del livello applicazione.
Se il client ed il server decidono di riabilitare una precedente sessione o di duplicarne una esistente invece di negoziare di nuovo i parametri di sicurezza, il flusso dei messaggi è il seguente:
Il client manda un client hello usando il Session ID della sessione da riesumare; 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. Adesso sia il client che il server devono mandare un messaggio di change cipher spec e procedere direttamente fino al messaggio di finished. Una volta che il ripristino è completo, il client ed il server possono iniziare a scambiare dati di livello applicazione. Se il server non trova una corrispondenza di Session ID nella propria session cache, allora il server genera un nuovo Session ID, e verrà eseguito un handshake completo.
Il significato dei messaggi sopra citati è brevemente esposto
nel paragrafo successivo.
Il protocollo SSL Handshake è usato per negoziare gli attributi
per la sicurezza di una sessione; i messaggi di handshake sono
forniti al SSL Record Layer, in cui sono incapsulati dentro una
o più strutture SSLPlaintext, a loro volta processate e
trasmesse secondo quanto stabilito nello stato corrente della
sessione attiva. Presentiamo i messaggi di handshake nell'ordine
in cui devono essere spediti; mandare tali messaggi in ordine
diverso provoca sempre un errore fatale.
3.3.6.1 Hello request.
Il messaggio di hello request può essere mandato
dal server in ogni momento ma sarà ignorato dal client
se l'handshake è già stato completato. Esso è
una semplice notifica che il client dovrebbe iniziare il processo
di negoziazione di nuovo spedendo un messaggio di client hello.
Dopo aver mandato un hello request il server non deve
ripeterlo finché la fase di handshake non sarà terminata.
3.3.6.1.1 Client hello.
Quando il client si connette per la prima volta ad un server,
deve spedire un messaggio di client hello per prima cosa.
Il client può anche spedirlo in risposta ad un hello
request, o per propria iniziativa per rinegoziare i parametri
di sicurezza di una connessione esistente. Questo messaggio include
una struttura random usata successivamente dal protocollo:
struct {
uint32 gmt_unix_time;
opaque random_bytes[28];
} Random;
ove gmt_unix_time è la data e tempo corrente nel format standard UNIX a 32-bit, e random_bytes sono 28 bytes generati da un algoritmo che fornisce numeri casuali.
Il messaggio di client hello include anche un identificatore di sessione a lunghezza variabile che, se non vuoto indica una sessione fra il client ed il server i cui parametri di sicurezza sono riusabili dal client; l'identificatore di sessione può provenire da una connessione precedente, dalla connessione attuale o da un'altra correntemente attiva. La struttura usata è la seguente:
opaque SessionID<0..32>;
La lista CipherSuite è anch'essa contenuta in questo messaggio:
uint8 CipherSuite[2]; /* selettore di Cryptographic suite */
Essa contiene le combinazioni di algoritmi di crittografia supportati dal client, in ordine di preferenza del client stesso. Ogni CipherSuite definisce un algoritmo per lo scambio di chiavi e un CipherSpec. Il server sceglierà una cipher suite oppure, se non c'è una scelta accettabile ritornerà un handshake failure chiudendo la connessione.
Infine il messaggio client hello contiene una lista di algoritmi di compressione supportati dal client, in ordine di preferenza del client: se il server non supporta nessuno di quelli specificati dal client, la sessione deve fallire.
enum { null(0), (255) } CompressionMethod;
La strutura complessiva del messaggio di client hello è quindi la seguente:
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..215>;
CompressionMethod compression_methods<1..27>;
} ClientHello;
N.B. /* Con le parentesi acute <,> si indica il numero
di elementi che un vettore deve obbligatoriamente contenere: ad
esempio nel caso del messaggio ClientHello, il vettore cipher_suites
può contenere da 2 a 215 elementi del tipo CipherSuite
precedentemente definito, ed in ogni caso non può essere
vuoto. */
Dopo aver mandato un client hello, il client aspetta un messaggio di server hello, che analizziamo di seguito. Qualsiasi altro messaggio di handshake provocherebbe un errore fatale, tranne un hello request che sarebbe ignorato.
Nota implementativa: i dati dell'applicazione non possono
essere spediti finché non è spedito un messaggio
di finished, altrimenti tali dati sarebbero insicuri.
Il server processa il messaggio di client hello e risponde con un server hello o con un alert per il fallimento dell'handshake. La struttura di questo messaggio è simile a quella del client hello:
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
} ServerHello;
ove:
Se il server deve essere autenticato, come in genere accade, esso
manda il suo certificato immediatamente di seguito al server
hello, con il messaggio server certificate. Il tipo
di certificato deve essere adeguato all'algoritmo di scambio di
chiavi scelto nella cipher suite, ed è generalmente un
X.509.v3. Lo stesso tipo di messaggio è usato per la risposta
del client ad un messaggio di server certificate request.
3.3.6.3 Messaggio di server key exchange.
Questo messaggio è spedito dal server se esso non ha un
certificato, o ha un certificato usato solo per la firma, o se
è usato l'algoritmo fortezza/DMS di scambio chiavi.
3.3.6.4 Certificate request.
Un server non anonimo può opzionalmente richiedere un certificato
dal client, se ciò è in accordo con la cipher suite
concordata.
Questo messaggio è mandato dal server per indicare la fine
del server hello e dei messaggi associati; dopo aver spedito tale
messaggio il server aspetta una risposta dal client. Il quale
avendo ricevuto il server hello done verifica che il server
abbia una valida certificazione, se richiesta, e controlla che
i parametri del server hello siano accettabili.
3.3.6.6 Client certificate.
Questo è il primo messaggio che il client può mandare
dopo aver ricevuto un server hello done, se un certificato
era richiesto dal server. Se un certificato valido non è
disponibile il client può rispondere con un no certificate
alert, provocando un warning.
3.3.6.7 Messaggio di client key exchange.
La scelta del messaggio di client key exchange è fatta
in base a quale algoritmo a chiave pubblica è stato scelto.
L'informazione per scegliere la corretta struttura del messaggio
è contenuta nel pending session state.
3.3.6.8 Messaggio premaster secret cifrato con RSA
Se RSA è scelto per lo scambio delle chiavi e l'autenticazione,
il client genera un pre-master secret composto da 48 bytes, lo
crittografa usando la chiave pubblica del server e spedisce il
risultato in un messaggio di encrypted premaster secret
avente la seguente struttura:
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
ove :
struct {
public-key-encrypted PreMasterSecret pre_master_secret;
} EncryptedPreMasterSecret;
in cui :
3.3.6.9 Fortezza key exchange message.
Con il Fortezza DMS, il client deriva una 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 suoi parametri privati. Il client genera le chiavi della sessione, le protegge usando il TEK e le spedisce al server, insieme all'IV della sessione; quindi genera un premaster secret di 48 bytes, lo cifra usando il TEK e lo spedisce.
Altri messaggi sono quelli che riguardano la crittografia
in modo diretto: client Diffie-Hellman public value, analogo
al precedente; certificate verify message usato per verificare
esplicitamente il certificato del client. In particolare
il messaggio finished che è sempre mandato immediatamente
dopo un messaggio di change cipher spec per verificare
che lo scambio e la autenticazione delle chiavi siano andati a
buon fine. Questo messaggio di finished è il primo ad essere
protetto con le misure di sicurezza appena negoziate; dopodiché
le parti possono cominciare a scambiarsi dati confidenziali che
saranno così protetti.
Le modalità per lo scambio delle chiavi, l'autenticazione,
la cifratura e gli algoritmi MAC sono determinati dalla cipher_suite
scelta dal server e rivelata al client nel server hello message.
3.4.1 Crittografia asimmetrica o a chiave pubblica.
Gli algoritmi a chiave pubblica sono usati nella fase di handshake per autenticare le parti e generare le chiavi condivise e le altre stringhe casuali.
Per gli algoritmi Diffie-Hellman, RSA, e Fortezza, è usato lo stesso procedimento per convertire la stringa pre_master_secret in master_secret e cancellare la prima dalla memoria:
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));
Se si usa RSA per l'autenticazione del server e lo scambio delle
chiavi, un pre_master_secret di 48 bytes è generato dal
client, cifrato con la chiave pubblica del server e spedito. Il
server usa la sua chiave privata per metterlo in chiaro, ed entrambi
convertono il pre_master_secret in master_secret come
specificato sopra.
3.4.1.2 Diffie-Hellman
E' usato un convenzionale algoritmo Diffie-Hellman; la chiave negoziata è usata come pre_master_secret e convertita in master_secret nel modo illustrato sopra.
3.4.1.3 Fortezza.
Un pre_master_secret di 48 bytes è spedito già cifrato con il TEK. Il server mette in chiaro il pre_master_secret e lo converte in master_secret; in questo caso verrà usato solo per i calcoli del MAC.
3.4.2 Calcoli con la Crittografia Simmetrica e CipherSpec.
La tecnica usata per cifrare e verificare l'integrità
dei record SSL è specificata dalla Cipher Spec correntemente
attiva. Un esempio tipico può essere quello di cifrare
i dati usando DES e generare i codici di autenticazione
usando MD5. Per default gli algoritmi di crittografia ed
il MAC sono posti a NULL all'inizio: l'Handshake protocol serve
appunto per stabilire una Cipher Spec sicura e a generare le chiavi.
Prima che la cifratura sicura o la verifica dell'integrità possano essere attuate sui records, il client ed il server devono generare dei segreti condivisi noti solo ad essi stessi: questa sequenza di 48 bytes è quella che abbiamo chiamato master_secret. Il master_secret è usato per generare le chiavi ed altre stringhe per la crittografia e per i calcoli del MAC.
Le CipherSpecs richiedono un client write MAC secret, un server
write MAC secret, come abbiamo visto nel calcolo del MAC, ed anche
un client write key, un server write key,
un client write IV, ed un server write IV, che sono generate
a partire dal master_secret e dalle sequenze di bytes specificate
in ClientHello.random e ServerHello.random che agiscono
come entropia nel processo di generazione. Questo avviene
applicando, come mostrato in precedenza, MD5 sul master_secret
e sull'SHA, calcolato a sua volta sul master_secret
e sulle due sequenze random, concatenando il risultato
finché non è raggiunta la dimensione necessaria;
a questo punto la sequenza ottenuta è divisa in sottosequenze
di dimensione opportuna, che rappresentano i client write MAC
secret, server write MAC secret, client write key, server write
key, client write IV, ed il server write IV, da utilizzare nelle successive operazioni
di controllo, autenticazione e cifratura.
3.5 Considerazioni finali e debolezze di SSL.
SSL esamina esplicitamente un numero di attacchi, incluso l'attacco forza bruta, crittoanalisi, replay e l'uomo in mezzo. SSL è progettato per agire a livello di rete: ciò significa che non protegge da attacchi agli host, per i quali sarebbe consigliabile proteggersi con un package del tipo Tripwire. I Tripwire usano funzioni hash sicure per assicurare che i documenti non siano cambiati rispetto ad una versione di riferimento protetta in scrittura.
L'uso dell'algoritmo RC4 con chiavi di 40 bits può portare problemi: sembra che un paio di gruppi indipendenti siano già riusciti a forzarlo in circa 8 giorni; sicuramente può quindi essere reso vano da organizzazioni governative o criminali in modo relativamente semplice. Tuttavia la scelta di RC4 è obbligata dalla legge USA sull'esportazione degli algoritmi di crittografia.
Ci sono diversi punti di SSL che, pur non essendo critici, potrebbero
offrire ulteriore sicurezza. Ad esempio nel protocollo SSL
Handshake alcuni dati spediti con il messaggio CLIENT HELLO
potrebbero essere spediti in un secondo momento, crittografati.
Nel protocollo SSL Record, un errato MAC non dovrebbe
far terminare la connessione ma causare una richiesta di ripetizione
del messaggio: infatti ci sono pochi attacchi che possono trarre
vantaggio dalla duplice spedizione di dati, mentre terminando
la connessione si apre la strada agli attacchi basati sul servizio
negato; inoltre i numeri di sequenza dovrebbero essere generati
in modo casuale invece che ordinatamente.
E' importante notare tuttavia che questo approccio alla problematica della sicurezza
sembra concepito in modo da permettere facili aggiornamenti ed il supporto a nuovi algortimi di
crittografia, senza stravolgere la struttura di SSL.
- Specifiche del protocollo SSLv3.0 in questo Internet Draft : ftp://ietf.cnri.reston.va.us/internet-drafts/draft-freier-ssl-version3-01.txt
- Informazioni da Netscape Communication su:
Secure Sockets Layer (SSL) Protocol: http://www.netscape.com/info/SSL.html
SSL specification(June 1995): http://home.netscape.com/newsref/std/SSL.html
- Informazioni sulla sicurezza:
http://home.netscape.com/newsref/std/index.html ;
http://home.netscape.com/newsref/ref/internet-security.html
Implementazioni di SSL disponibili in rete:
- Implementazione di Netscape Communication di SSLv2.0, SSLref http://home.netscape.com/info/sslref.html
-Implementazione di SSLv3.01b http://home.netscape.com/newsref/std/sslref.html .
- Versione SSLLeay 0.6.0 che implementa SSLv2.0, per Unix e Windows 3.1/95/NT, Solaris, free sia per uso privato che commerciale, disponibile al: ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL .
- Implementazione di SSLv2.0 di CyberPresence alla pagina http://www.cyberpi.com/, per Windows 3.x/95/NT.
- Secure HTTP e SSL Toolkit commercializzato da Terisa: "http://www.terisa.com/prod/prod.html"
- Versioni dei Web server sicuri di IBM per le maggiori piattaforme: http://www.ics.raleigh.ibm.com/
- Applicazioni basate su SSL:
Indirizzi utili:
- W3C, World Wide Web Consortium: http://www.w3.org/hypertext/WWW/Consortium/Prospectus/Overview.html
- Netscape Communications Corp.: http://home.netscape.com
- Per questioni tecniche su SSL e SSLref mandare un email a: ssl-talk@netscape.com .
- EIT; http://www.eit.com ( Enterprise Integrated Technologic Inc.).
- IETF; http://www.ietf.org/ .
- Un "secure server " della RSA: https://www.rsa.com/netscape/
- Using RSA Public Key Cryptography : http://www.rsa.com
- SSL - Utili Links: http://www.cs.bris.ac.uk/~bradley/Documents/SSL/links.html
- Utili Links sulla crittografia: ftp.hacktic.nl:/pub/replay/pub/crypto, ftp.funet.fi:/pub/crypt
- Informazioni della Spry C. su Internet Security: http://server.spry.com/secure.htm
- Frequently Asked Question su WWW security: http://www-genome.wi.mit.edu/WWW/faqs/www-security-faq.html
- http://www.psy.uq.oz.au/~ftp/Crypto .
- ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL .
- Damien Doligez's SSL cracking page
- implementazioni e applicazioni SSL :ftp://ftp.psy.uq.oz.au/pub/Crypto/SSLapps .
- http://developer.netscape.com/conference/index.html .
- Hotlist su sicurezza e telematica, diritto e privacy: http://www.cs.purdue.edu/homes/spaf/hotlists/csec.html
- http://home.netscape.com/eng/mozilla/2.0/handbook/docs/atoz.html#S .