Protocollo TLS: dietro le quinte della sicurezza web

TLS, acronimo di Transport Layer Security, è un protocollo fondamentale per garantire la sicurezza delle comunicazioni online. Protegge i dati scambiati tra applicazioni utilizzando avanzate tecniche di crittografia simmetrica e asimmetrica. Questo protocollo assicura non solo la riservatezza delle informazioni, ma anche l’integrità e l’autenticità dei messaggi ed è quindi indispensabile per la protezione delle comunicazioni sensibili su Internet.

Per questo, TLS si posiziona come il “guardiano” delle connessioni sicure. Ne approfondiamo il funzionamento e l’importanza nell’attuale contesto digitale.

Cos’è il protocollo TLS

L’acronimo TLS si espande in Transport Layered Security, il che potrebbe portare a pensare che questo protocollo lavori a livello 4 (appunto livello di trasporto) della pila ISO/OSI. Contrariamente, questo protocollo è costruito per lavorare a livello 5 della pila ISO/OSI, ovvero a livello di presentazione. Lavora quindi ad un livello superiore ad i protocolli di trasporto come TCP o UDP e si interpone tra questi ultimi e il livello applicativo.

Questo permette a qualsiasi software di livello applicativo di fare utilizzo del protocollo TLS per sfruttarne i servizi di sicurezza.

Lo scopo principale del protocollo TLS è quello di fornire una comunicazione privata e sicura tra due peer che intendono scambiarsi delle informazioni. Per ottenere questo obbiettivo, il protocollo fornisce:

• Una comunicazione sicura tramite l’utilizzo della crittografia a chiave simmetrica per garantire la segretezza delle informazioni scambiate tra i due comunicanti.
• Garanzia di integrità dei messaggi scambiati tramite l’utilizzo di algoritmi di hash all’interno di Message Authentication Codes come HMAC.
• Garanzia dell’identità di uno o di entrambi i comunicanti tramite l’utilizzo di crittografia a chiave asimmetrica e certificati.
• Scambio sicuro degli shared secrets necessari per utilizzare gli algoritmi di crittografia a chiave simmetrica.

Come funziona il TLS: una panoramica tecnica

Il protocollo TLS è suddiviso in due protocolli interni: il TLS Record Protocol e il TLS Handshake Protocol.

Il TLS Record Protocol lavora direttamente sopra ai protocolli di trasporto come UDP o TCP e si occupa di garantire la segretezza della comunicazione tramite l’utilizzo di algoritmi di crittografia a chiave simmetrica come AES o RC4. Questi algoritmi utilizzano uno shared secret che è stato stabilito in precedenza tra le due parti tramite un altro protocollo di handshake (come ad esempio il TLS Handshake Protocol). Inoltre, il TLS Record Protocol si occupa anche di garantire l’integrità dei messaggi scambiati calcolandone digest e Message Authentication Codes tramite l’utilizzo di algoritmi crittografici come SHA e HMAC.

Il TLS Record Protocol incapsula le informazioni del TLS Handshake Protocol che lavora ad un livello superiore. Lo scopo principale di quest’ultimo è quello di garantire l’autenticazione delle parti che stanno comunicando e di fornire la possibilità di scambiarsi in modo sicuro e affidabile uno o più shared secrets che il TSL Record Protocol può utilizzare come basi per i suoi algoritmi simmetrici. Il TLS Handshake Protocol fa quindi utilizzo di crittografia a chiave asimmetrica e certificati che gli permettono di raggiungere i propri obiettivi.

È importante anche sottolineare come tutti i messaggi scambiati tra client e server durante un TLS Handshake non siano crittografati dal TLS Record Protocol, inquanto volti a stabilire gli algoritmi crittografici e i segreti della connessione tra client e server.

Vediamo ora nel dettaglio come sono implementati questi due protocolli.

TLS Handshake Protocol

Il TLS Handshake Protocol si occupa principalmente di stabilire i parametri di connessione tra i due comunicanti. Essi infatti, tramite questo protocollo: scelgono la versione del TLS, concordano gli algoritmi crittografici da utilizzare, si autenticano l’un l’altro se lo desiderano e fanno utilizzo della crittografia a chiave asimmetrica per stabilire i segreti condivisi alla base della sicurezza delle loro future comunicazioni.

Gli step che compongono la fase iniziale di una comunicazione TLS sono infatti:

1. Il client invia al server un messaggio di ClientHello nel quale comunica al server le seguenti informazioni:
   1. La versione del protocollo TLS che desidera utilizzare
   2. Le suite di protocolli crittografici che è in grado di supportare in ordine di preferenza del client stesso. Ogni suite comprende:
      1. Un algoritmo di key exchange
      2. Un algoritmo a chiave simmetrica
      3. Un algoritmo di MAC
      4. Un algoritmo di tipo PRF (Pseudo-Random Function)
   3. Un elenco di metodi di compressione supportati dal client in ordine di preferenza del client stesso
   4. Un ClientRandom, ovvero una stringa di bit generati randomicamente del client tramite l’utilizzo di un secure RNG
2. Il server risponde a questo messaggio con un ServerHello, tramite il quale va a selezionare una cipher suite tra quelle suggerite dal client da utilizzare per la connessione e un algoritmo di compressione, sempre tra quelli suggeriti dal client. Se il server non riesce a selezionare una cipher suite e un algoritmo di compressione appropriati in base alle capacità del client, l’handshake viene terminato immediatamente dal server. Allo stesso tempo, in questo stesso messaggio, il server invia al client un ServerRandom, ovvero una stringa di bit randomici generati dal server tramite un secure RNG e indipendenti dal ClientRandom ricevuto dal client in precedenza.
3. (OPZIONALE) Sebbene il protocollo TLS possa funzionare anche in modalità anonima, quindi senza verifica dell’identità né del client né del server, in un tipico handshake almeno l’identità del server viene sempre verificata. Al messaggio di ServerHello, seguirà quindi un messaggio di ServerCertificate da parte del server, nel quale il server invia il certificato che attesta la propria identità al client.
4. (OPZIONALE) Il server può eventualmente richiedere anche l’autenticazione del client stesso, in caso la suite di protocolli selezionata in precedenza lo permetta. In questo caso, invierà un messaggio di CertificateRequest al client.
5. (OPZIONALE) Dopo lo scambio di certificati oppure subito dopo i due messaggi di Hello (se nessun certificate message è stato inviato), se il protocollo di key exchange scelto lo richiede, il server invia al client un messaggio di Server Key Exchange volto a condividere informazioni aggiuntive necessarie alla computazione del TLS premaster secret.
6. Il server invia un messaggio di Server Hello Done al client, notificando l’invio di tutte le informazioni necessarie da parte del server per l’handshake.
7. (Opzionale) Se ha ricevuto una Certificate Request, il client invierà al server un messaggio di Client Certificate condividendo il proprio certificato con quest’ultimo.
8. Dopo il messaggio di Client Certificate oppure dopo il messaggio di Server Hello Done, il client invia sempre un messaggio di Client Key Exchange, volto a stabilire il TLS premaster secret. Questo premaster secret può essere direttamente generato dal Client e inviato al server crittografato tramite la chiave pubblica del server stesso. Oppure, può essere derivato indipendentemente dalle due parti tramite le informazioni scambiate nei messaggi inviati fino a questo momento e l’utilizzo di specifici key exchange protocols (basati per esempio su Diffie-Hellman).
9. (OPZIONALE) Se il client ha inviato un Client Certificate, il server deve rispondere immediatamente con un messaggio di Certificate Verify per notificare al client se la verifica del certificato è andata a buon fine.
10. Una volta che il TLS premaster secret è stato condiviso tra le due parti, entrambe manderanno un messaggio di Finished notificando la fine del TLS handshake.

Da questo momento in poi, i parametri di sicurezza della connessione sono stati tutti stabiliti e le due parti posso iniziare in modo sicuro ad inviare application data che sono incapsulati tramite il TLS Record Protocol.

TLS Record Protocol

Una volta stabiliti i parametri di connessione e il TLS premaster secret tramite i messaggi di handshake, le due parti utilizzeranno la PRF concordata per generare il TLS master secret come segue:

Questo master secret sarà poi utilizzato, tramite la stessa PRF, per espandere il key material che verrà usato per costruire i segreti utilizzati per cifrare i dati della connessione:

Da questo key material sono costruiti i seguenti segreti della connessione:

• Client write key
• Server write key
• Client MAC key
• Server MAC key
• Client write IV
• Server write IV

I client write parameters sono utilizzati dal server quando riceve i messaggi dal client per decifrare e verificare i dati ricevuti. Viceversa, i server write parameters sono utilizzati dal client quando riceve messaggi dal server per decifrare e verificare i dati ricevuti.

Lo scopo del record layer è quello di ricevere ed incapsulare i dati dei protocolli di livello superiore e applicare a questi le seguenti trasformazioni:

• Fragmentation: i dati vengono frammentati in frazioni di lunghezza predefinita
• Compression: i dati vengono compressi tramite il compression algorithm stabilito durante l’handshake tra le due parti. Questo compression algorithm dovrà essere necessariamente di tipo lossless, ovvero senza perdita di dati tra i processi di compressione e decompressione degli stessi. Durante l’handshake, è anche possibile che le due parti concordino di non usare un compression algorithm per la connessione. In questo caso, i dati saranno frammentati ma non compressi dal record protocol.
• Record payload protection: i dati vengono cifrati tramite l’algoritmo di cifratura simmetrica stabilito durante l’handshake tra le due parti. Inoltre, il record protocol utilizza il MAC protocol stabilito per calcolare un valore di integrity check dei dati contenuti nel payload. In questa fase, i server / client write parameters vengono utilizzati per cifrare i dati e calcolarne il MAC.

Una volta effettuate tutte queste trasformazioni ai dati ricevuti, essi vengono inviati alla controparte che effettuerà tutte le operazioni inverse per recuperare le informazioni originarie e verificare che queste siano autentiche e integre.

Differenze tra TLS e SSL

Al giorno d’oggi, spesso si fa erroneamente uso del termine SSL (oppure SSL/TLS) per indicare l’utilizzo di TLS all’interno di una comunicazione. Storicamente il protocollo SSL (o Secure Socket Layer) è stato pubblicato prima del protocollo TLS, nel 1995. Essendo agli albori delle comunicazioni su rete, le necessità di protezione dei dati erano molto inferiori a quelle dei giorni d’oggi. Lo stesso protocollo SSL è stato negli anni aggiornato per far fronte alla scoperta di attacchi efficaci contro di esso passando dalla versione 1.0 alle versioni 2.0 e successivamente 3.0.

Tuttavia, le capacità del protocollo SSL anche alla versione 3.0 non sono sufficientemente sicure ed efficienti per poter essere utilizzate nelle odierne comunicazioni. Per questo motivo, questo venne sostituito appunto dal protocollo TLS, il quale ne snelliva le procedure di handshake e ne aumentava le capacità crittografiche (a livello di algoritmi supportati) per far fronte alle necessità sempre crescenti di efficienza e sicurezza.

Curiosamente infatti, leggendo lo standard TLS versione 1.2 vediamo come il “version” field scambiato da Client e Server per stabilire l’utilizzo di TLS v1.2 sia invece indicato come versione “3.3”. Nell’appendice E dello standard RFC 5246 spiega infatti come il campo “version” permetta di mantenere la backward compatibility del protocollo TLS 1.2 con versioni precedenti come TLS 1.0 / 1.1 oppure SSL 2.0 / 3.0.

Differenze tra TLS e HTTPS

La differenza tra protocollo TLS e HTTPS nasce proprio dal livello della pila ISO/OSI in cui questi due protocolli lavorano.

Abbiamo già specificato come il protocollo TLS lavori a livello di presentazione della pila ISO/OSI, fornendo servizi di sicurezza sui dati incaspulati. In particolare, esso incapsula e garantisce la sicurezza dei dati rivevuti dai livelli superiori (quindi dal livello applicativo). I dati del TLS sono poi a loro volta incapsulati e gestiti dai livelli inferiori per essere trasmessi sulla rete.

Dall’altra parte, il protocollo HTTP (o Hypertext Transfer Protocol) lavora a livello applicativo quindi al livello più alto della pila ISO/OSI e si occupa semplicemente della struttura dei dati delle pagine web e della loro trasmissione. Questo lavora quindi al di sopra del protocollo TLS e può farne utilizzo per proteggere i dati trasmessi sulla rete.

Quando il protocollo HTTP fa utilizzo di TLS per proteggere i dati delle proprie pagine web, si parla allora di HTTPS (o HTTP Secure). Solitamente, quando una connessione HTTP fa utilizzo di TLS notiamo subito che il link al sito web inizia con https:// invece che con http://. Così come il nostro browser ci mostra il simbolo del lucchetto in alto a destra. Questo sta semplicemente ad indicare che tutti i dati che scambiamo con quel server sono crittografati e autenticati tramite i servizi del protocollo TLS.

Perché il TLS è fondamentale per la sicurezza online

Dalla descrizione del protocollo TLS si capisce come questo comporti un overhead di dati e messaggi necessari per gestire una comunicazione tra due parti. Questo sicuramente ha un impatto importante sull’efficienza della comunicazione stessa.

Tuttavia, per applicazioni che trattano dati potenzialmente sensibili per il server web o per i propri utenti, ad oggi l’utilizzo di protocolli come TLS è praticamente indispensabile.

In rete, i dati condivisi e inviati sono potenzialmente a disposizione di chiunque possa mettersi in mezzo alla comunicazione tra server e client. Il server inoltre ha un ulteriore necessità di sicurezza ed è maggiormente esposto ad attacchi visto il grande numero di comunicazione che dovrà gestire.

Protezione dei dati in transito

Come prima cosa, i dati in transito tra server e client posso essere intercettati e letti o, peggio ancora, modificati per scopi terzi.

Il protocollo TLS è disegnato proprio per evitare che questo accada. La crittografia simmetrica permette ai due peer di cifrare in maniera sicura i dati che condividono in modo che questi siano illeggibili ad un potenziale attaccante.

Inoltre, i dati sono autenticati tramite algoritmi di tipo MAC che ne garantiscono l’integrità. La verifica del MAC code di un messaggio da parte del client o del server da garanzia a quest’ultimo che il messaggio non sia stato modificato in transito sulla rete.

Autenticazione dei siti web

L’autenticazione è un altro fattore molto importante nelle comunicazioni web. Per alcune applicazioni e utilizzi autenticare la controparte con cui si sta comunicando in maniera sicura è di fondamentale importanza.

Il TLS permette di fornire l’autenticazione sia del server che, potenzialmente, del client della comunicazione. Tale garanzia è fornita tramite lo scambio di certificati la cui originalità può essere verificata tramite la certificate chain di tutte le authorities che garantiscono per quel certificato. Fino a risalire alle root Certificate Authorities che sono ben conosciute nel mondo delle comunicazioni di rete.

Applicazioni pratiche del TLS

Interponendosi tra i livelli di trasporto e di applicazione, i servizi del protocollo TLS possono potenzialmente essere utilizzati da qualsiasi protocollo applicativo che desideri tramettere dei dati in modo sicuro.

HTTPS e la crittografia delle comunicazioni web

Il primo dei protocolli applicativi che utilizza TLS e il più diffuso è proprio il protocollo HTTP per la trasmissione di pagine Web.

Tramite il protocollo TLS, l’HTTPS può dare garanzia dell’identità del server e potenzialmente dei client tramite l’utilizzo dei certificati. Allo stesso tempo, questo può garantire la segretezza dei contenuti HTTP scambiati tra client e server quando questi sono in transito da un peer all’altro.

Infine, TLS permette al protocollo HTTP di dare garanzia alle due parti dell’integrità delle pagine web che sono visualizzate.

TLS in altri protocolli (SMTP, IMAP, ecc.)

Oltre al protocollo HTTP anche altri protocolli di rete utilizzano il TLS per garantire la sicurezza delle connessioni.

I protocolli di scambio di email come IMAP e POP3 sono un altro esempio di protocolli che fanno utilizzo di TLS. Lo scopo naturalmente è quello di garantire la sicurezza e l’integrità delle email, nonché l’autenticazione dei mail server nei confronti dei client (e opzionalmente dei client nei confronti del server).

TLS nei dispositivi IoT

Anche nel campo dei dispositivi IoT la sicurezza delle comunicazioni svolge un ruolo fondamentale nel garantire un accesso controllato e sicuro a dispositivi ben conosciuti. In questo caso, anche l’autenticazione di chi prova a connettersi ad un dispositivo IoT può essere di fondamentale importanza.

Per tali scopi, il TLS può essere molto utile garantendo l’autenticazione del dispositivo e di chi vi si connette e la segretezza e integrità delle informazioni che questo comunica e riceve.

Nel campo dell’IoT, tuttavia, la principale preoccupazione ricade nel consumo energetico e di memoria aggiuntivo che l’utilizzo del TLS comporterebbe in un dispositivo IoT. Esso sarà infatti costretto ad inviare messaggi aggiuntivi per effettuare un TLS handshake e informazioni aggiuntive per raggiungere tutti gli obiettivi di sicurezza necessari.

Alcuni studi mostrano come l’overhead energetico introdotto dal TLS sia comunque poco significante in confronto all’energia necessaria nell’effettiva trasmissione di dati. Specialmente quando i dati da trasmettere diventano numerosi, l’overhead introdotto dal TLS diventa sempre più insignificante.

Per quanto riguarda il consumo di memoria, esistono delle implementazioni dedicate del protocollo TLS sono state sviluppate per essere utilizzate proprio in questo campo. Un esempio di questi software è wolfSSL.

Le principali vulnerabilità del TLS

Le principali vulnerabilità del protocollo TLS derivano da tre fattori principali:

• La retrocompatibilità con protocolli di vecchia generazione e obsoleti (TLS v 1.0/1.1 e SSL)
• La cattiva configurazione dei servizi che fanno uso del TLS o delle librerie che lo implementano
• L’uso di cifrari obsoleti e/o vulnerabili ad attacchi noti all’interno dalla suite TLS negoziata durante un handshake

Attacchi man-in-the-middle

Visto che il protocollo TLS è volto a garantire una connessione sicura tra due end point, un classico attacco in questo tipo di scenario è proprio il man-in-the-middle. In poche parole, un attore terzo (l’attaccante) che si introduce nel mezzo della comunicazione tra client e server allo scopo di carpirne le informazioni o effettuare altro tipo di azioni malevole verso il client e/o il server.

Un esempio di possibile attacco man-in-the-middle è il cosiddetto CRIME Attack (dove CRIME sta per “Compression Ratio Info-leak Made Easy”). Questo attacco sfrutta l’utilizzo nella connessione TLS della compressione e, parallelamente, tecniche di social engineering per permettere all’attaccante di risalire al valore del cookie di sessione di una connessione HTTP. Sfruttando l’utilizzo della compressione, l’attaccante è in grado di risalire al valore del cookie e quindi impersonare il client nella connessione con il server.

Un modo semplice per ovviare a questo tipo di attacco è fare in modo che un server TLS non faccia mai uso di compressione nelle sue comunicazioni.

Vulnerabilità dei cifrari

La sicurezza del TLS dipende anche dai cifrari che sono scelti all’interno della cipher suite utilizzata per una connessione.

Fino a qualche anno fa, nelle versioni 1.0 e 1.1 del TLS era ancora considerato sicuro l’utilizzo dell’algoritmo RC4 come algoritmo di cifratura a chiave simmetrica. Successivamente, sono state evidenziate numerose vulnerabilità di questo algoritmo che nascono dal design intrinseco dello stesso.

Per tali ragioni, adesso l’algoritmo RC4 è considerato obsoleto ed insicuro ed è stato soppiantato da altri algoritmi molto più sicuri come AES.

Tuttavia, una potenziale implementazione di TLS potrebbe ancora consentire l’utilizzo di RC4 all’interno delle proprie cipher suite. Sta quindi nelle mani di chi ne fa utilizzo la responsabilità di evitare che un server TLS accetti di portare a termine un handshake dove viene richiesto l’utilizzo di versioni del protocollo obsolete o di algoritmi crittografici insicuri.

Implementazioni insicure

Le vulnerabilità del protocollo TLS nascono anche delle librerie che lo implementano. Se infatti una libreria che implementa il TLS è soggetta ad una vulnerabilità implementativa, questa può molto facilmente riflettersi sull’implementazione del TLS stesso all’interno di questa libreria.

Un esempio famoso di questo tipo di vulnerabilità è Heartbleed. Questa è una vulnerabilità specifica della libreria OpenSSL causata da un buffer over-read nel codice della libreria stessa.

Questa vulnerabilità permetteva ad un potenziale attaccante di risalire alle chiavi segrete che dovevano in teoria essere protette dalle versioni vulnerabili della libreria OpenSSL. È quindi facile capire come questo diventasse un enorme problema di sicurezza anche per quelle applicazioni che facevano utilizzo del protocollo TLS tramite la libreria OpenSSL.

In questo caso, un semplice update della libreria vulnerabile ad una versione più recente o una sostituzione di tale libreria con una non vulnerabile, risolve il problema alla radice.

Best practices per una configurazione sicura

Il design del protocollo TLS è molto utile e ormai indispensabile al giorno d’oggi per le connessioni tra end point in rete. Tuttavia, il solo design del protocollo non è garanzia sufficiente di sicurezza assoluta delle informazioni protette dal TLS.

Per fare un utilizzo corretto e sicuro delle funzionalità che il TLS offre bisogna seguire alcune accortezze che passano da:

• Mantenersi sempre aggiornati sul panorama crittografico e sull’evoluzione degli algoritmi stessi. Il modo della crittografia è infatti sempre in continua evoluzione e algoritmi che oggi sono considerati sicuri tra qualche tempo possono diventare insicuri a causa di attacchi noti o dell’evoluzione tecnologica.
• Fare in modo che un server TLS accetti connessioni solo con versioni aggiornate e sicure del protocollo stesso. Al giorno d’oggi, le versioni più sicure sono TLS 1.2 e TLS 1.3. Tutte le versioni più basse del protocollo, compreso il protocollo SSL, sono affette da vulnerabilità note o fanno uso solo di cifrari ormai obsoleti o poco sicuri.
• Mantenersi aggiornati sulla scoperta di nuove potenziali vulnerabilità del protocollo TLS e/o delle librerie che lo implementano. Allo stesso tempo, indagare se la versione del protocollo in uso ha vulnerabilità note e, in tal caso, se la configurazione del server è in grado di mitigare tali vulnerabilità.
• Fare in modo che un server accetti solo cipher suite composte da algoritmi crittografici sicuri.