TLS (Transport Layer Security)

TLS (Transport Layer Security) è un pro­to­col­lo di crit­to­gra­fia che ga­ran­ti­sce tra­smis­sio­ni dati sicure su internet. È il suc­ces­so­re del vecchio SSL e oggi viene uti­liz­za­to quasi esclu­si­va­men­te nella versione TLS 1.3.

Cos’è il pro­to­col­lo TLS?

All’inizio dell’era digitale la sicurezza dei dati ricopriva un ruolo minore rispetto a oggi. Tutte le co­mu­ni­ca­zio­ni erano trasmesse da un computer all’altro in maniera aperta e non crit­to­gra­fa­ta. Im­ma­gi­nia­mo questo processo come se si trattasse di una cartolina: qualsiasi postino o postina potrebbe leggerla.

Il pro­to­col­lo TLS, chiamato anche SSL/TLS, ha in­tro­dot­to la crit­to­gra­fia dei contenuti trasmessi. Per uti­liz­za­re lo stesso paragone di prima, questa crit­to­gra­fia è come una busta da lettera chiusa con un sigillo, che può essere aperta soltanto dal legittimo de­sti­na­ta­rio o dalla legittima de­sti­na­ta­ria.

L’ab­bre­via­zio­ne TLS sta per Transport Layer Security, che tradotto significa “sicurezza del livello di trasporto”. Questa de­no­mi­na­zio­ne si riferisce al “livello di trasporto” del modello TCP/IP. TLS è il processo per crit­to­gra­fa­re il flusso di dati sulla rete, affinché questi siano letti soltanto dai legittimi de­sti­na­ta­ri o dalle legittime de­sti­na­ta­rie.

Come funziona il pro­to­col­lo TLS?

TLS codifica tutto il traffico dati svi­lup­pa­to at­tra­ver­so il pro­to­col­lo TCP mediante un processo di crit­to­gra­fia sim­me­tri­co.

Quello che in teoria sembra facile, in realtà è più complesso. Il problema prin­ci­pa­le è che il server deve co­mu­ni­ca­re la chiave al client, e questo prima di pro­teg­ge­re la co­mu­ni­ca­zio­ne con TLS. Chi invia allegati in forma crit­to­gra­fa­ta conosce questo problema: si codifica un dato e bisogna co­mu­ni­ca­re la chiave segreta al de­sti­na­ta­rio o alla de­sti­na­ta­ria, ad esempio per telefono.

Il pro­to­col­lo TLS, il cui standard attuale è la versione 1.3 dal 2018, applica il seguente pro­ce­di­men­to per risolvere questo problema:

1. Clien­tHel­lo: il client (ad esempio un browser) invia al server un primo messaggio con in­for­ma­zio­ni sulle crit­to­gra­fie sup­por­ta­te. Tra queste ci sono le suite di cifratura, le versioni del pro­to­col­lo, un valore casuale e un proprio valore di scambio chiavi Diffie-Hellman (valore ECDHE). È possibile inviare già fa­col­ta­ti­va­men­te il primo blocco di dati crit­to­gra­fa­to.
2. Ser­ve­rHel­lo: il server sceglie i parametri adeguati e invia la sua risposta, inclusi il suo valore ECDHE e il suo cer­ti­fi­ca­to digitale. Questo cer­ti­fi­ca­to SSL dimostra che il server è autentico e non sta simulando una falsa identità. Con­tem­po­ra­nea­men­te, inizia il calcolo della chiave di sessione.
3. Calcolo della chiave: entrambe le parti calcolano ora in maniera in­di­pen­den­te la stessa chiave di sessione (Session Key) basandosi sulla chiave con­cor­da­ta in comune.
4. Il server completa l’handshake e inizia la co­mu­ni­ca­zio­ne crit­to­gra­fa­ta. Anche il client fa lo stesso; la con­nes­sio­ne è ora com­ple­ta­men­te sicura.

Il motivo per cui la crit­to­gra­fia asim­me­tri­ca Diffie-Hellman viene uti­liz­za­ta soltanto per la tra­smis­sio­ne di una chiave di sessione (ma non per la crit­to­gra­fia dello stesso flusso di dati) è un vantaggio in termini di velocità: la crit­to­gra­fia asim­me­tri­ca è infatti un processo re­la­ti­va­men­te lento e ri­tar­de­reb­be la co­mu­ni­ca­zio­ne.

Vantaggi e svantaggi di TLS

Il pro­to­col­lo TLS è una soluzione elegante per or­ga­niz­za­re in sicurezza il traffico dati sul web. Il motivo è che non richiede a entrambe le parti di crit­to­gra­fa­re au­to­no­ma­men­te i contenuti, per esempio i dati di un for­mu­la­rio. Basta che il traffico venga gestito tramite il pro­to­col­lo TLS, in­di­pen­den­te­men­te dal sistema operativo e dalle ap­pli­ca­zio­ni software uti­liz­za­ti dalle parti coinvolte. Tutto il flusso di dati viene crit­to­gra­fa­to au­to­no­ma­men­te durante la tra­smis­sio­ne.

Il prezzo da pagare per la sicurezza è un col­le­ga­men­to un po’ più lento, poiché i processi sopra descritti (cer­ti­fi­ca­to, cifra casuale, scambio di chiavi) ri­chie­do­no ope­ra­zio­ni intense di calcolo.

Campi di ap­pli­ca­zio­ne di TLS

Come già men­zio­na­to, il pro­to­col­lo TLS può essere uti­liz­za­to uni­ver­sal­men­te perché funziona in­di­pen­den­te­men­te dalle ap­pli­ca­zio­ni e dai sistemi operativi. Di con­se­guen­za, per numerosi pro­to­col­li ap­pli­ca­ti­vi esiste una versione sicura con pro­to­col­lo TLS. Nella maggior parte de casi, lo schema di no­men­cla­tu­ra è molto semplice: dietro il nome del pro­to­col­lo viene inserita la lettera “S”, se il pro­to­col­lo comunica mediante TLS.

Il campo di ap­pli­ca­zio­ne più im­por­tan­te di TLS è il web, o per essere più precisi il pro­to­col­lo HTTP. La sua variante crit­to­gra­fa­ta si chiama HTTPS.

Inoltre, vale la pena di men­zio­na­re alcuni casi d’uso frequenti:

• POP3S: per scaricare e-mail dal server con il pro­to­col­lo POP3
• IMAPS: per sin­cro­niz­za­re la posta in arrivo con il server mediante il pro­to­col­lo IMAP
• SMTPS: per inviare e-mail
• FTPS: per tra­sfe­ri­re file con un pro­to­col­lo FTP
• SIPS: telefonia Voice-over-IP con il pro­to­col­lo SIP
• IRCS: chat crit­to­gra­fa­te
• QUIC: il pro­to­col­lo di trasporto di Google che integra di­ret­ta­men­te TLS 1.3; un’al­ter­na­ti­va a TCP per con­nes­sio­ni web più veloci e sicure (ad esempio con HTTP/3)

Anche OpenVPN, un software open source per creare una rete virtuale privata (VPN) sfrutta il pro­to­col­lo TLS.

Im­ple­men­ta­zio­ni di TLS

Le più im­por­tan­ti im­ple­men­ta­zio­ni di TLS sono:

• OpenSSL - l’im­ple­men­ta­zio­ne più frequente, uti­liz­za­ta per la maggior parte dei siti HTTPS
• GnuTLS (Free Software Foun­da­tion)
• LibreSSL (OpenBSD)
• NSS (Network Security Services)
• BoringSSL (Google)
• Rustls (Joe Birr-Pixton, Dirkjan Ochtman, Daniel McCarney, Josh Aas e la community Open Source)
• Botan (Licenza BSD, Jack Lloyd)
• JSSE (Java Secure Socket Extension, Oracle)
• S2n (Amazon)

Questa lista non è completa. Ulteriori in­for­ma­zio­ni sulle im­ple­men­ta­zio­ni di TLS sono di­spo­ni­bi­li su Wikipedia in inglese.

Attacchi noti a TLS

Neanche TLS è to­tal­men­te sicuro contro gli attacchi e le perdite. Sono co­no­sciu­ti i seguenti punti di attacco:

• Errori di pro­gram­ma­zio­ne: è diventato famoso l’Heart­bleed Bug, un serio errore di pro­gram­ma­zio­ne delle prime versioni di OpenSSL. È stato corretto nel 2014.
• Crit­to­gra­fie deboli: come con­se­guen­za delle re­stri­zio­ni all’espor­ta­zio­ne della crit­to­gra­fia negli USA, sono state svi­lup­pa­te versioni “espor­ta­bi­li”, più facili da violare rispetto alle originali.
• Attacchi di com­pres­sio­ne: quando si utilizza la com­pres­sio­ne HTTP invece di quella TLS, gli hacker riescono a in­do­vi­na­re i contenuti crit­to­gra­fa­ti TLS seguendo processi precisi.
• L’attacco BEAST riguarda la versione 1.0 di TLS ed è stato risolto già nel 2014. Le versioni attuali di TLS sono protette.
• L’attacco Padding Oracle è stato scoperto nel 2002 ed è stato possibile fino alla versione 3.0 di SSL. La versione attuale 1.3 di TLS è al sicuro da questo attacco.
• L’attacco ALPACA del 2021 mostra come i cer­ti­fi­ca­ti TLS su server con­fi­gu­ra­ti in modo errato possano essere sfruttati per rein­di­riz­za­re utenti verso altri servizi, in­ter­cet­tan­do o ma­ni­po­lan­do i dati.

Inoltre, ci sono stati vari tentativi di impedire una crit­to­gra­fia com­ple­ta­men­te sicura di TLS affinché le autorità potessero venire a co­no­scen­za dei contenuti delle co­mu­ni­ca­zio­ni, per esempio in relazione a tran­sa­zio­ni fi­nan­zia­rie e attività criminali. Una delle or­ga­niz­za­zio­ni che ha tentato di provocare tali “crepe” di TLS è stata l’ETSI (Istituto Europeo per gli Standard nelle Te­le­co­mu­ni­ca­zio­ni).