SSL e il suo successore TLS, sono protocolli che crittografano il traffico Internet, rendendo possibile la comunicazione Internet sicura e l’e-commerce. La storia decennale di questi protocolli è stata segnata da continui aggiornamenti per tenere il passo con aggressori sempre più sofisticati ed esperti. La prossima versione principale del protocollo, TLS 1.3, sarà presto finalizzata e, per evidenti ragioni di sicurezza, la maggior parte di coloro che gestiscono un sito Web è pronta a eseguire l’aggiornamento.

Secure Sockets Layer, o SSL, era il nome originale del protocollo quando è stato sviluppato a metà degli anni ’90 da Netscape, l’azienda che ha realizzato il browser Web più popolare dell’epoca. SSL 1.0 non è mai stato rilasciato al pubblico e SSL 2.0 presentava gravi bug. SSL 3.0, rilasciato nel 1996, è stato completamente rinnovato e ha posto le basi per ciò che è seguito.

TLS vs SSL

Quando la versione successiva del protocollo è stata rilasciata nel 1999, è stata standardizzata dall’Internet Engineering Task Force (IETF) e gli è stato assegnato un nuovo nome: Transport Layer Security o TLS. Come osserva la specifica TLS, “le differenze tra questo protocollo e SSL 3.0 non sono molto significative”. Pertanto, non è davvero una questione di TLS e SSL; piuttosto, i due formano una serie di protocolli continuamente aggiornati e sono spesso raggruppati insieme come SSL/TLS.

Il protocollo TLS crittografa il traffico Internet di tutti i tipi. Il più comune è il traffico web; vi accorgete che il vostro browser è connesso tramite TLS se l’URL nel tuo indirizzo inizia con “https” e c’è un indicatore con un lucchetto per far capire che la connessione è sicura. Ma TLS può essere utilizzato anche da altre applicazioni, incluse e-mail e usenet.

Come funziona SSL

La crittografia è necessaria per comunicare in sicurezza su Internet: se i vostri dati non sono crittografati, chiunque può esaminare i vostri pacchetti e leggere informazioni riservate. Il metodo di crittografia più sicuro è chiamato crittografia asimmetrica; ciò richiede due chiavi crittografiche (informazioni, di solito numeri molto grandi) per funzionare correttamente, una pubblica e una privata. Il discorso qui si fa piuttosto complesso, ma in sostanza è possibile utilizzare la chiave pubblica per crittografare i dati, mentre è necessaria la chiave privata per decriptarli.

Le due chiavi sono collegate tra loro da una formula matematica complessa che è difficile da decodificare con un attacco brute force. Pensate alla chiave pubblica come a informazioni sulla posizione di una cassetta postale bloccata e alla chiave privata come alla chiave che sblocca la cassetta postale. Chiunque sappia dove si trova la casella di posta può inserirvi un messaggio; ma affinché chiunque altro possa leggerlo, ha bisogno della chiave privata.

Poiché la crittografia asimmetrica comporta questi difficili problemi matematici, richiede molte risorse informatiche, tanto che se la si utilizzasse per crittografare tutte le informazioni in una sessione di comunicazione, il vostro computer e la vostra connessione si bloccherebbero.

TLS risolve questo problema utilizzando solo la crittografia asimmetrica all’inizio di una sessione di comunicazione per crittografare la conversazione; il server e il client devono concordare su un’unica chiave di sessione che utilizzeranno entrambi per crittografare i propri pacchetti da quel momento in poi. La crittografia che utilizza una chiave condivisa è chiamata crittografia simmetrica ed è molto meno intensiva dal punto di vista computazionale rispetto alla crittografia asimmetrica. Il processo attraverso il quale viene concordata la chiave di sessione è chiamato handshake, poiché è il momento in cui i due computer comunicanti si presentano l’uno all’altro ed è il cuore del protocollo TLS.

Processo di handshake SSL

Il processo di handshake è piuttosto complesso e ci sono una serie di variazioni consentite dal protocollo. I passaggi seguenti forniscono uno schema generale che dovrebbe darvi un’idea di come funziona.

  1. Il client contatta il server e richiede una connessione sicura. Il server risponde con l’elenco delle suite di crittografia (kit di strumenti algoritmici per la creazione di connessioni crittografate) che sa come utilizzare. Il client lo confronta con il proprio elenco di suite di crittografia supportate, ne seleziona una e informa il server che la utilizzeranno entrambi.
  2. Il server fornisce quindi il proprio certificato digitale, un documento elettronico emesso da un’autorità terza che conferma l’identità del server. Parleremo più in dettaglio dei certificati digitali tra un momento, ma per ora la cosa più importante che dovete sapere su di essi è che contengono la chiave crittografica pubblica del server. Una volta che il client riceve il certificato, ne conferma l’autenticità.
  3. Utilizzando la chiave pubblica del server, il client e il server stabiliscono una chiave di sessione che entrambi utilizzeranno per il resto della sessione per crittografare la comunicazione. Ci sono diverse tecniche per farlo. Il client può utilizzare la chiave pubblica per crittografare un numero casuale che viene quindi inviato al server per la decriptazione, ed entrambe le parti utilizzano quindi quel numero per stabilire la chiave di sessione. In alternativa, le due parti possono utilizzare quello che viene chiamato uno scambio di chiavi Diffie-Hellman per stabilire la chiave di sessione.

Come suggerisce il nome, la chiave di sessione è valida solo per il corso di una singola sessione di comunicazioni ininterrotta. Se per qualche motivo le comunicazioni tra client e server vengono interrotte, ad esempio a causa di un problema di rete o perché il client è inattivo per troppo tempo, sarà necessario un nuovo handshake per stabilire una nuova chiave di sessione quando la comunicazione viene ristabilita.

(Credit immagine: Depositphotos)

(Credit immagine: Depositphotos)

Che cos’è un certificato SSL?

Un certificato SSL è un documento elettronico che conferma l’identità di un server e consente la comunicazione crittografata. Come chiarito dalla descrizione nella sezione precedente, questi certificati sono il cuore del protocollo SSL/TLS: forniscono al client la chiave crittografica pubblica necessaria per avviare connessioni sicure. Ma il loro scopo va oltre la semplice fornitura della chiave stessa; si accertano anche che la chiave sia effettivamente associata all’organizzazione che la offre al cliente.

Come funziona? I certificati sono emessi dalle autorità di certificazione (CA), che fungono da equivalente di un ufficio passaporti quando si tratta di confermare le identità. Le organizzazioni che desiderano offrire servizi crittografati da TLS devono acquistare certificati dalle CA, che a loro volta verificano che le organizzazioni siano chi affermano di essere. Ad esempio, se volete acquistare un certificato per proteggere un sito Web su example.com, dovreste eseguire alcuni passaggi per dimostrare alla CA che controllate effettivamente il dominio exemple.com. In questo modo, se qualcuno si connette a example.com e ottiene un certificato SSL valido emesso da una CA affidabile, può essere sicuro di comunicare con il legittimo proprietario di example.com. Questo può prevenire gli attacchi di tipo man in the middle.

SSL checkers

Quasi tutto lo scambio e la conferma delle informazioni sopra descritte avviene dietro le quinte mentre comunicate con i server che offrono connessioni crittografate con TLS. Se volete ottenere un po’ più di trasparenza, potete inserire l’URL di un sito crittografato SSL/TLS in un sito Web SSL checker. Il controllo (check) restituirà una serie di informazioni sul certificato del sito testato, incluso il tipo di server, quali browser Web riterranno attendibili e non riterranno attendibili il certificato, l’emittente, il numero di serie e la data di scadenza.

La maggior parte dei controlli SSL sono servizi gratuiti offerti dalle CA come strumenti di marketing per i loro prodotti; molti, ad esempio, vi permetteranno di impostare un avviso per quando scadrà un certificato ispezionato. Se però state cercando un’alternativa un po’ meno commerciale, dai un’occhiata al SSL checker di Qualys SSL Labs, che fornisce una raccolta particolarmente solida di informazioni sui siti Web ispezionati.

Vulnerabilità di TLS 1.2

TLS 1.2 è la versione definita più recente del protocollo e lo è da diversi anni. Ha stabilito una serie di nuove opzioni crittografiche per la comunicazione. Tuttavia, come alcune versioni precedenti del protocollo, consentiva anche l’utilizzo di tecniche crittografiche precedenti per supportare i computer meno recenti. Sfortunatamente, ciò ha aperto alle vulnerabilità, poiché quelle tecniche più vecchie sono diventate più vulnerabili con il passare del tempo e la potenza di calcolo è diventata più economica.

In particolare, la versione 1.2 è diventata sempre più vulnerabile agli attacchi man-in-the-middle, in cui un hacker intercetta i pacchetti durante la comunicazione e li invia dopo averli letti o alterati. Questa versione è risultata vulnerabile anche agli attacchi POODLE, SLOTH e DROWN e molti di questi problemi sono sorti negli ultimi due anni, aumentando il senso di urgenza per l’aggiornamento del protocollo.

TLS 1.3

Fortunatamente, la versione 1.3 del protocollo TLS, attualmente in forma di bozza ma presto finalizzata, colma molte di queste lacune eliminando il supporto per i sistemi di crittografia legacy. Esistono ancora server che utilizzano versioni di TLS anche precedenti alla 1.2, con alcuni che utilizzano ancora il protocollo SSL originale. Se il vostro server è uno di quelli, dovreste eseguire l’aggiornamento ora.