Autenticazione e integrità in SSL/TLS

Nella lezione precedente abbiamo spiegato come il protocollo SSL possa stabilire un canale di comunicazione criptato tra due parti.

A conti fatti, però, la sola crittografia non è sufficiente per raggiungire un certo livello di sicurezza.

Questa affermazione è abbastanza condivisibile se si pensa che con la crittografia nessuna delle due parti può essere veramente sicura dell'identità dell'altra.

La ragione tipica per utilizzare la crittografia è in primo luogo quella di mantenere le informazioni segrete a una terza parte.

Ma se questa terza parte fosse in grado di mascherarsi come il destinatario delle informazioni, allora la crittografia non servirebbe a nulla.

I dati sarebbero criptati, ma l'attaccante avrebbe tutti i dati necessari per decifrarli.

Per evitare questo tipo di attacco, il protocollo SSL include alcuni meccanismi che permettono ad ogni parte di autenticare l'identità dell'altra.

Con questi meccanismi ogni parte può essere sicura che l'altra sia autentica e non un possibile impostore.

In questa sezione, vedremo come il protocollo SSL permette ad un server di autenticarsi.

Autenticazione di un server

Benchè il protocollo SSL definisca un meccanismo per l'autenticazione lato client è opportuno dire che questo viene maggiormente adoperato per l'autenticazione lato server.

Questo comportamento è facilmente comprensibile se pensiamo per esempio alla natura degli e-commerce: quando si vuole acquistare qualcosa usando Internet è infatti molto importante che il sito Web su cui si sta navigando sia autenticato, perchè nessuno vorrebbe inviare informazioni sensibili, come il numero della propria carta di credito, ad un impostore che si spaccia per un negozio online.

Anche il negozio online, tramite, SSL avrebbe gli strumenti per poter verificare l'autenticità di un client ma, riportandoci all'esempio precedente dell'e-commerce, una volta ricevuto il numero di carta di credito potrebbe convalidarlo senza bisogno di scomodare il protocollo SSL.

La figura sotto riportata riassume le azioni che ogni sistema intraprende per autenticare un server.

Tale processo non è molto diverso dal procedimento di crittografia introdotto nella scorsa lezione, le azioni infatti sono praticamente le stesse fatta eccezione per l'invio del messaggio certificate e di quello ClientKeyExchange.

1. Il client invia un messaggio ClientHello proponendo le opzioni SSL.
2. Il server risponde con il messaggio ServerHello selezionando le opzioni.
3. Il server invia il suo certificato di chiave pubblica nel messaggio Certificate.
4. Il server conclude la sua parte di negoziazione con il messaggio ServerHello-Done.
5. Il client invia le informazioni sulla chiave di sessione (criptate con la chiave pubblica del server) nel messaggio ClientKeyExchange.
6. Il client invia il messaggio ChangeCipherSpec per attivare le opzioni negoziate per tutti i futuri messaggi che invierà.
7. Il client invia il messaggio Finished per permettere al server di controllare le nuove opzioni attivate.
8. Il server invia il messaggio ChangeCipherSpec per attivare le opzioni per tutti i futuri messaggi che invierà.
9. Il server invia un messaggio Finished per permettere al client di controllare le nuove opzioni appena attivate.

Nei successivi paragrafi esamineremo nel dettaglio il punto 3 e 5.

Messaggio Certificate

Il server per autenticare la sua identità invia un messaggio Certificate invece del messaggio ServerKeyExchange descritto nella lezione precedente.

Questo messaggio Certificate contiene semplicemente una catena di certificati, dei quali il primo è quello della chiave pubblica del server e l'ultimo è quello relativo all'autorità di certificazione.

Al client viene demandata la responsabilità di assicurarsi che il certificato che riceve dal server sia autentico e appartenga al server con cui ha stabilito il canale di comunicazione.

Questa responsabilità include la verifica delle firme dei certificati, i tempi di validità e lo stato di revoca.

Il client deve anche assicurarsi che l'autorità di certificazione sia affidabile. In genere questa verifica avviene grazie al fatto che i client hanno una lista di chiavi pubbliche di autirità di certificazione precaricate dal loro browser.

Microsoft, per esempio, precarica i browser con le chiavi pubbliche di autorità di certificazione ben note. I server Web che vogliono farsi autenticare devono ottenere quindi i loro certificati (almeno indirettamente) da una di queste autorità di cetificazione.

Un ulteriore dettaglio nel processo di verifica dei certificati che può a volte sembrare superficiale, ma che è comunque cruciale per la sicurezza reale, non riguarda soltanto il verificare che il certificato sia rilasciato da un'autorità di certificazione nota, ma che questo identifichi in modo inequivocabile la parte con cui comunicare.

Consideriamo l'esempio di una società malintenzionata che riceve un certificato legittimo da un'autorità di certificazione nota sotto il proprio nome, ma che poi usa quel certificato illegittimamente per impersonare qualcun altro.

Il cliente è ignaro di comunicare con questa società malintenzionata, perchè comunque riceverà un certificato legittimo tramite il protocollo SSL. E' essenziale, quindi, che il client si occupi di verificare anche che il certificato appartenga all'individuo corrispondente.

Questa verifica viene normalmente effettuata controllando il nome del dominio del server. 

Le autorità di certificazione includono il nome del dominio Internet del server Web nei certificati che rilasciano e i browser controllando il nome di dominio possono appurare di essere collegati con il soggetto atteso o meno.

Per esempio, un browser che cerca di connettersi a www.banca.cloud e che riceve un certificato con il nome di dominio www.hacker.it rileva che qualcosa che non va come ci si aspetterebbe.

Messaggio ClientKeyExchange

Il messaggio ClientKeyExchange del client è diverso da quello adoperato per la crittografia.

Nel caso della crittografia il client cripta le informazioni nel ClientKeyExchange usando la chiave pubblica che il server gli fornisce nel suo messaggio ServerKeyExchange.

Nel caso dell'autenticazione il server per autenticarsi deve inviare il messaggio Certificate invece di quello ServerKeyExchange.

In questo modo il client cripta le sue informazioni usando la chiave pubblica contenuta nel certificato del messaggio Certificate del server.

Questo passo è importante perché permette al client di assicurarsi che la parte con cui sta comunicando possieda effettivamente la chiave privata del server.

Solo un sistema con l'effettiva chiave privata sarà in grado, infatti, di decifrare questo messaggio e continuare con successo la comunicazione.

Conclusioni

In questa lezione abbiamo visto come come un server può autenticarsi inviando un messaggio Certificate invece che di un messaggio ServerKeyExchange.

Una conseguenza di questo approccio è che la stessa chiave pubblica viene usata sia per verificare l'identità del server che per crittografare i dati del client.

Ciò non è sempre desiderabile e in alcuni casi questo comportamento viene effettivamente proibito dalla legge.

Non esiste una ragione tecnica ben precisa per tale comportamento ma la ratio comune, soprattutto dal punto di vista giuridico di alcuni Paesi, richiede comunque una netta separazione tra i processi di autenticazione e di crittografia.

Per questo motivo, il protocollo SSL è dotato anche della possibilità di separare i due processi mantenendo praticamente entrambi i messaggi, sia quello di ServerKeyExchange che di Certificate.