Che cos’è TLS e come funziona?

Transport Layer Security (TLS) è uno dei protocolli di sicurezza più importanti e ampiamente utilizzati. Protegge una parte significativa dei dati che vengono trasmessi online. È molto importante utilizzato per proteggere i dati che viaggiano tra un browser Web e un sito Web tramite HTTPS, ma può anche essere utilizzato per proteggere la posta elettronica e una serie di altri protocolli.

TLS è prezioso perché garantisce che l’altra parte in una connessione sia chi dice di essere, mostra se i dati mantengono la loro integrità iniziale e fornisce riservatezza attraverso la crittografia.

TLS utilizza una gamma di algoritmi e schemi diversi per raggiungere questi scopi. Può sembrare complicato, ma questo articolo tratterà un aspetto alla volta per darti uno sguardo approfondito su come TLS funziona per proteggere le connessioni.

Cosa fa TLS?

Quando inviamo informazioni online, riscontriamo tre problemi di sicurezza principali:

• Come possiamo sapere se la persona con cui stiamo comunicando è davvero chi dicono di essere?
• Come possiamo sapere che i dati non sono stati manomessi da quando li hanno inviati?
• Come possiamo impedire ad altre persone di vedere e accedere ai dati?

Questi problemi sono cruciali, specialmente quando inviamo informazioni sensibili o preziose. TLS utilizza una serie di tecniche crittografiche per affrontare ciascuno di questi tre problemi. Insieme, consentono al protocollo di autenticare l’altra parte in una connessione, verificare l’integrità dei dati e fornire una protezione crittografata.

Semplifichiamo le cose e facciamo finta di provare a trasferire informazioni avanti e indietro con un amico che vive in tutto il paese. Se le informazioni sono sensibili, sarai molto preoccupato per i tre principali problemi sopra menzionati.

Non puoi semplicemente inviare una lettera e sperare per il meglio, soprattutto se sospetti che le tue comunicazioni saranno prese di mira dagli attaccanti. È invece necessario un sistema che consenta di verificare che il destinatario sia legittimo, un modo per verificare se i messaggi sono stati modificati e un modo per proteggerli da occhi indiscreti.

TLS soddisfa questi requisiti utilizzando una serie di processi diversi. Si inizia con ciò che è noto come a Stretta di mano TLS, dove avviene l’autenticazione e vengono stabilite le chiavi.

Per tornare alla nostra analogia con le lettere, la parte di autenticazione di TLS sarebbe un po ‘come inviare una lettera tramite un corriere che richiede l’identificazione. Quando il corriere consegna la lettera, confronta l’ID della persona con la sua faccia e verifica se il destinatario era o meno la persona corretta.

La fase di creazione delle chiavi sarebbe un po ‘come se la tua lettera contenesse la metà di un numero di pin che intendevi utilizzare nelle comunicazioni future. Chiederesti al destinatario di presentare la seconda metà del numero e di inviarlo nella lettera di ritorno.

Dopo che il corriere avrà verificato l’identità e stabilito il numero PIN, avrai tutto ciò di cui hai bisogno per inviare informazioni in modo sicuro. In realtà, queste fasi sono molto più complesse, ma ci arriveremo più tardi.

TLS scambia informazioni in modo sicuro con il protocollo dell’applicazione. Per portare avanti la nostra analogia, trasmettere i dati in modo sicuro su TLS sarebbe come scrivere un messaggio e metterlo in una busta. Scriveresti la tua firma sul sigillo, in modo che se la lettera fosse manomessa, il tuo destinatario sarebbe in grado di dirlo con la firma strappata (questo è effettivamente fatto con la matematica, ma di nuovo, lo tratteremo in profondità in seguito).

Quindi inseriresti la lettera in una piccola scatola di metallo con un lucchetto a combinazione, impostando la combinazione come numero di pin che hai stabilito congiuntamente con il tuo destinatario. Spediresti la scatola tramite il corriere che controlla l’identificazione al momento della consegna dei pacchi. Il destinatario risponderà allo stesso modo e qualsiasi comunicazione futura seguirà gli stessi passaggi.

TLS risolve tutti e tre i nostri problemi in modo relativamente simile. Il corriere serve per autenticare il destinatario e assicurarsi che la scatola venga consegnata alla persona designata. La casella bloccata funge da forma di crittografia, impedendo a chiunque tranne il tuo partner di accedere alle lettere. La busta firmata ti consente di sapere se il messaggio non è stato manomesso.

Questa è un’approssimazione molto approssimativa di ciò che fa TLS. In realtà, TLS si svolge tra client e server, piuttosto che due persone che si inviano posta l’un l’altro. L’analogia è solo per darti una visualizzazione di ciò che sta accadendo e del ragionamento che sta dietro. Nelle sezioni seguenti, tratteremo ciò che effettivamente accade in dettaglio.

TLS vs. SSL

Leggendo su TLS, vedrai spesso la menzione di SSL o anche come TLS / SSL. Secure Sockets Layer (SSL) è la vecchia versione di TLS, ma molti nel settore fanno ancora riferimento a TLS con il vecchio moniker. Questo articolo utilizzerà il termine TLS in tutto, ma è importante notare che i nomi sono spesso usati in modo intercambiabile. Puoi leggere di più su SSL nella nostra guida.

La storia di TLS

Tutto è iniziato con la necessità di proteggere il livello di trasporto. Come accennato in precedenza, il precursore di TLS era SSL. Le prime versioni di SSL sono state sviluppate negli anni novanta da Netscape, una società che ha creato uno dei primi browser web.

SSL 1.0 non è mai stato rilasciato perché conteneva gravi vulnerabilità. La versione 2.0 è uscita con Netscape Navigator 1.1 nel 1995, tuttavia conteneva ancora una serie di gravi difetti. SSL 3.0 era una versione fortemente riprogettata ed è uscito nel 1996, con molti problemi di sicurezza risolti.

Nel 1996, l’IETF ha rilasciato una bozza di SSL 3.0 in RFC 6101. L’IETF ha formato un gruppo di lavoro per standardizzare SSL, pubblicando i risultati nel 1999 come TLS 1.0. È stato documentato in RFC 2246 e la standardizzazione includeva alcune modifiche al protocollo originale, nonché la modifica del nome. Queste modifiche sono nate a seguito di negoziati tra Netscape, Microsoft e il gruppo di lavoro IETF.

Nel 2006, l’IETF ha rilasciato RFC 4346, che documenta TLS 1.1. Questa versione conteneva nuove disposizioni di sicurezza e una serie di altri aggiornamenti. La versione 1.2 è stata rilasciata solo due anni dopo nel 2008. Comprendeva il supporto per i codici di crittografia autenticati, una serie di modifiche all’utilizzo delle funzioni di hash e molti altri miglioramenti.

La versione successiva non è arrivata fino al 2023, quando è stato definito TLS 1.3. Presenta una serie di modifiche, tra cui il segreto diretto imposto, la rimozione del supporto per algoritmi più deboli e molto altro.

TLS 1.0 e 1.1 sono ora impostati per essere deprecati nel 2023, ma la versione 1.2 è ampiamente utilizzata. La versione 1.3 sta iniziando a vedere una maggiore adozione.

TLS: i dettagli tecnici

TLS è costituito da molti elementi diversi. La parte fondamentale è il protocollo record, il protocollo sottostante responsabile della struttura generale di tutto il resto.

Diagramma che mostra lo stack TLS. Stack di protocollo TLS di Jeffreytedjosukmono. Concesso in licenza sotto CC0.

Il protocollo di registrazione contiene cinque sottoprotocolli separati, ciascuno dei quali è formattato come record:

• Stretta di mano – Questo protocollo viene utilizzato per impostare i parametri per una connessione sicura.
• Applicazione – Il protocollo applicativo inizia dopo il processo di handshake ed è dove i dati vengono trasmessi in modo sicuro tra le due parti.
• Mettere in guardia – Il protocollo di avviso viene utilizzato da entrambe le parti in una connessione per informare l’altra in caso di errori, problemi di stabilità o un potenziale compromesso.
• Modifica le specifiche di cifratura – Questo protocollo viene utilizzato dal client o dal server per modificare i parametri di crittografia. È piuttosto semplice, quindi non lo approfondiremo in questo articolo.
• Battito cardiaco – Questa è un’estensione TLS che consente a un lato della connessione di sapere se il suo peer è ancora attivo e impedisce ai firewall di chiudere le connessioni inattive. Non è una parte fondamentale di TLS, quindi la salteremo in questa guida.

Ognuno di questi protocolli secondari viene utilizzato in diverse fasi per comunicare informazioni diverse. I più importanti da comprendere sono l’handshake e i protocolli applicativi, poiché questi sono responsabili della creazione della connessione e quindi della trasmissione sicura dei dati.

Il protocollo di handshake TLS

Qui è dove la connessione viene stabilita in modo sicuro. Può sembrare complesso se sei nuovo ad alcuni dei concetti, ma ognuno di questi è trattato più avanti nell’articolo se devi fare riferimento a loro.

Esistono tre tipi base di handshake TLS: il stretta di mano TLS di base, il stretta di mano TLS autenticata dal client e il stretta di mano abbreviata.

La stretta di mano TLS di base

Diagramma che mostra il processo di handshake TLS. Stretta di mano completa TLS 1.2 di FleshGrinder. Concesso in licenza sotto CC0.

In questo tipo di handshake, viene autenticato solo il server e non il client. Inizia con la fase di negoziazione, in cui un client invia un Cliente Ciao Messaggio. Questo contiene la versione più alta di TLS supportata dal client, possibili suite di crittografia, un’indicazione se supporta la compressione, un numero casuale e alcune altre informazioni

Il messaggio Hello Client viene visualizzato con a Server Hello Messaggio. Questa risposta contiene l’ID sessione, la versione del protocollo, la suite di crittografia e la compressione (se ne viene utilizzata una) che il server ha selezionato dall’elenco del client. Include anche un numero casuale diverso.

Dipende dalla suite di crittografia selezionata, ma il server generalmente seguirà questo inviando un Certificato messaggio per l’autenticazione. Ciò convalida la sua identità e contiene la sua chiave pubblica.

Se si utilizzano scambi di chiavi Diffie-Hellman effimeri o Diffie-Hellman anonimi, questo è seguito da un Scambio chiavi server Messaggio. Altri metodi di scambio chiave saltano questa parte. Quando il server ha terminato la sua parte della negoziazione, invia un Server Hello Fatto Messaggio.

Ora tocca di nuovo al cliente. A seconda della suite di crittografia scelta, invierà a Scambio di chiavi client Messaggio. Questo può contenere una chiave pubblica o un segreto premaster, che è crittografato con la chiave pubblica del server.

Entrambe le parti usano quindi i numeri casuali e il segreto premaster per inventare un segreto segreto. Le chiavi derivano dal segreto principale, che vengono quindi utilizzate per autenticare e crittografare le comunicazioni.

Il client quindi invia un Modifica le specifiche di cifratura Messaggio. Questo dice al server che i seguenti messaggi saranno ora autenticati e crittografati (anche se a volte la crittografia potrebbe non essere utilizzata).

Il client quindi lo segue con a Finito messaggio, che è crittografato e contiene anche un codice di autenticazione del messaggio (MAC) per l’autenticazione. Il server decodifica questo messaggio e verifica il MAC. Se uno di questi processi fallisce, la connessione deve essere rifiutata.

Ora è il turno del server di inviare a Modifica le specifiche di cifratura messaggio, nonché a Finito messaggio con lo stesso contenuto di cui sopra. Il client quindi tenta anche di decrittografare e verificare i contenuti. Se tutto è stato completato correttamente, l’handshake è terminata. A questo punto, viene stabilito il protocollo dell’applicazione. I dati possono quindi essere scambiati in modo sicuro allo stesso modo di Finito messaggio dall’alto, con autenticazione e crittografia opzionale.

Handshake TLS autenticato dal cliente

Questa stretta di mano è molto simile alla stretta di mano TLS di base, ma anche il client è autenticato. La differenza principale è che dopo che il server ha inviato il suo Certificato messaggio, inoltre invia un Richiesta certificato messaggio, chiedendo il certificato del cliente. Una volta terminato il server, il client invia il suo certificato in a Certificato Messaggio.

Il client quindi invia il suo Scambio di chiavi client messaggio, proprio come nell’handshake TLS di base. Questo è seguito dal Verifica certificato messaggio, che include la firma digitale del cliente. Poiché viene calcolato dalla chiave privata del client, il server può verificare la firma utilizzando la chiave pubblica inviata come parte del certificato digitale del client. Il resto di Handshake TLS autenticato dal cliente segue le stesse linee dell’handshake TLS di base.

Stretta di mano abbreviata TLS

Una volta che una stretta di mano è già avvenuta, TLS consente di tagliare gran parte del processo utilizzando invece una stretta di mano abbreviata. Questi handshake utilizzano l’ID sessione per collegare la nuova connessione ai parametri precedenti.

Una stretta di mano abbreviata consente a entrambe le parti di riprendere la connessione protetta con la stessa configurazione negoziata in precedenza. Poiché parte della crittografia normalmente coinvolta nell’avvio di una stretta di mano può essere piuttosto pesante per le risorse computazionali, questo fa risparmiare tempo e semplifica la connessione.

Il processo inizia con il Cliente Ciao Messaggio. È molto simile al precedente messaggio di Hello Client, ma contiene anche il ID sessione dalla connessione precedente. Se il server conosce l’ID sessione, lo include nel suo Server Hello Messaggio. Se non riconosce l’ID sessione, restituirà un numero diverso e dovrà invece aver luogo una stretta di mano TLS completa.

Se il server riconosce l’ID sessione, quindi il Certificato e Scambio di chiavi i passaggi possono essere saltati. Il Modifica le specifiche di cifratura e Finito i messaggi vengono inviati allo stesso modo dell’handshake TLS di base mostrato sopra. Dopo che il client ha decrittografato il messaggio e verificato il MAC, i dati possono essere inviati attraverso la connessione TLS protetta.

Esiste anche un’estensione TLS che consente di riprendere le connessioni con i ticket di sessione anziché gli ID di sessione. Il server crittografa i dati sulla sessione e li invia al client. Quando il client desidera riprendere questa connessione, invia il ticket di sessione al server, che lo decodifica per rivelare i parametri.

I ticket di sessione non vengono utilizzati con la stessa frequenza perché richiedono l’estensione. Nonostante ciò, possono essere vantaggiosi in determinate situazioni, perché il server non deve archiviare nulla.

Disimballare l’handshake TLS

I tre passaggi più importanti della stretta di mano includono:

• i parametri sono selezionati,
• conduce l’autenticazione e
• le chiavi sono stabilite.

Vediamoli in dettaglio un po ‘di più in modo che tu possa capire cosa sta realmente succedendo.

I parametri

All’inizio dell’handshake, il client e il server negoziano i parametri della connessione di comune accordo. Il primo di questi è quale versione di TLS verrà utilizzata. Questa è la versione più alta supportata da entrambe le parti, che tende ad essere la più sicura.

Le parti decidono inoltre quale algoritmo di scambio delle chiavi utilizzeranno per stabilire la chiave principale. In questa fase vengono concordati anche la funzione hash, l’algoritmo di crittografia e il metodo di compressione. Questi saranno trattati in dettaglio quando discuteremo di Protocollo di applicazione più avanti nell’articolo.

Autenticazione: certificati digitali

L’autenticazione è una parte fondamentale della protezione di un canale di comunicazione, perché consente a entrambe le parti di sapere che stanno effettivamente parlando con chi pensano di essere e non come impostori. In TLS e in molti altri meccanismi di sicurezza, ciò si ottiene con quelli che sono noti come certificati digitali.

I certificati digitali sono documenti elettronici che mostrano il legame tra una persona fisica o giuridica e la loro chiave pubblica. Questo collegamento è convalidato da un’autorità di certificazione (CA), che è un’organizzazione attendibile che verifica che i due siano effettivamente correlati, quindi utilizza la propria reputazione per garantire l’attendibilità del certificato.   

Diversi livelli di certificato rappresentano vari gradi di fiducia. La cosa importante da sapere è che se un client o un server ha un certificato affidabile e valido, è ragionevole supporre che la chiave pubblica sia legittima e che non si abbia a che fare con un utente malintenzionato.

Una nota sulle chiavi pubbliche

La crittografia a chiave pubblica (nota anche come crittografia asimmetrica) è una parte importante della crittografia e viene ampiamente utilizzata nei diversi aspetti di TLS. Ecco un rapido primer per coloro che non hanno familiarità con il suo funzionamento.

La breve spiegazione è quella la crittografia a chiave pubblica utilizza una coppia di chiavi per la crittografia e la decrittografia, anziché una sola chiave. Il mittente utilizza la chiave pubblica del destinatario previsto per crittografare i dati. Una volta che è stato crittografato, può essere decrittografato solo dalla chiave privata corrispondente del destinatario. Naturalmente, la chiave pubblica può essere condivisa pubblicamente mentre la chiave privata deve essere mantenuta segreta.

La crittografia a chiave pubblica consente alle parti di condividere le informazioni in modo sicuro, anche se non hanno mai incontrato o avuto l’opportunità di scambiare le chiavi in ​​anticipo. Lo fa attraverso alcune proprietà uniche dei numeri primi. Puoi saperne di più nel nostro articolo sulla crittografia a chiave pubblica.

Stabilire un segreto segreto

Come abbiamo visto sopra quando abbiamo discusso del processo dell’handshake TLS di base, dopo che una parte (o entrambe le parti) ha dimostrato la sua identità con il suo certificato pubblico, il passo successivo è stabilire il segreto principale, noto anche come segreto condiviso. Il segreto principale è la base per derivare le chiavi utilizzate sia per crittografare che per verificare l’integrità dei dati trasmessi tra le due parti.

L’handshake TLS può utilizzare una serie di meccanismi diversi per condividere questo segreto in modo sicuro. Questi includono RSA, diversi tipi di scambio di chiavi Diffie-Hellman, PSK, Kerberos e altri. Ognuno ha i suoi vantaggi e svantaggi, come fornire segretezza anticipata, ma queste differenze non rientrano nell’ambito di questo articolo.

Il processo esatto dipenderà dal metodo di scambio delle chiavi scelto, ma segue i passaggi approssimativi menzionati in La stretta di mano TLS di base sezione.

Il segreto premaster è derivato secondo il metodo di scambio di chiavi precedentemente selezionato. Il client crittografa il segreto premaster con la chiave pubblica del server per inviarlo in modo sicuro attraverso la connessione.

Il client e il server usano quindi entrambi il segreto premaster e i numeri casuali che hanno inviato all’inizio della comunicazione per trovare il segreto principale. Una volta che la chiave master è stata calcolata, viene utilizzata per creare quattro o sei chiavi separate. Queste sono le:

• Il client scrive la chiave MAC – Questa chiave viene utilizzata dal server per verificare l’integrità dei dati inviati dal client.
• Il server scrive la chiave MAC – La chiave MAC di scrittura del server viene utilizzata dal client per verificare l’integrità dei dati inviati dal server.
• Chiave di crittografia scrittura client – Il server utilizza questa chiave per crittografare i dati inviati dal client.
• Chiave di crittografia di scrittura del server – Il client utilizza questa chiave per crittografare i dati inviati dal server.
• Il cliente scrive la chiave IV – La chiave IV di scrittura del client viene utilizzata dal server nelle cifre AEAD, ma non quando vengono utilizzati altri algoritmi di scambio delle chiavi.
• Il server scrive la chiave IV – Allo stesso modo, questa chiave viene utilizzata dal client nelle cifre AEAD, ma non quando vengono utilizzati altri algoritmi di scambio delle chiavi.

Stabilire la chiave principale è una parte importante dell’handshake TLS, poiché consente a entrambi i lati della connessione di derivare in modo sicuro chiavi che possono essere utilizzate sia per l’autenticazione che per la crittografia. Le chiavi separate sono utilizzate per entrambi i processi come precauzione.

Una volta derivate le chiavi di autenticazione e crittografia, vengono utilizzate per proteggere entrambi Finito messaggi, nonché i record inviati tramite il protocollo dell’applicazione.

Il protocollo dell’applicazione

Una volta stabilita una connessione sicura dall’handshake TLS, il protocollo dell’applicazione viene utilizzato per proteggere i dati trasmessi. Può essere configurato per utilizzare una vasta gamma di algoritmi per adattarsi a diversi scenari.

Algoritmi di autenticazione

L’integrità dei messaggi può essere verificata con molti algoritmi diversi. Questi includono:

• HMAC-MD5
• HMAC-SHA1
• HMAC-SHA2
• AEAD

Per dimostrare l’integrità dei dati inviati, il mittente esegue le informazioni attraverso una funzione hash per restituire una stringa univoca di caratteri. Queste sono formule speciali che restituiranno sempre lo stesso risultato ogni volta che ricevono lo stesso input.

Il mittente firma questi dati con la loro chiave privata per formare quella che è nota come firma digitale, La firma digitale viene quindi allegata al messaggio e inviata al destinatario. Per verificare se i dati mantengono la loro integrità e non sono stati manomessi, il destinatario decodifica l’hash con la chiave pubblica del mittente. Quindi utilizzano la stessa funzione hash sui dati inviati. Il destinatario confronta quindi i due valori.

Se sono uguali, significa che i dati non sono stati modificati da quando sono stati firmati dal mittente. Se sono diversi, è probabile che i dati siano stati manomessi o che si siano verificati altri errori.

Questa è la versione breve di come le funzioni hash possono essere utilizzate per mostrare l’integrità dei dati. Se desideri una comprensione più approfondita, consulta il nostro articolo su crittografia, salatura e hash.

Algoritmi di crittografia

TLS utilizza la crittografia a chiave simmetrica per garantire la riservatezza dei dati che trasmette. A differenza della crittografia a chiave pubblica, solo una chiave viene utilizzata sia nei processi di crittografia che di decrittografia. Una volta che i dati sono stati crittografati con un algoritmo, appariranno come un miscuglio di testo cifrato. Finché viene utilizzato un algoritmo appropriato, gli aggressori non saranno in grado di accedere ai dati effettivi, anche se li intercettano.

TLS può utilizzare molti algoritmi diversi, come Camellia o ARIA, anche se il più popolare è AES.

Compressione

La compressione è il processo di codifica dei dati per occupare meno spazio. TLS supporta la compressione se entrambi i lati della connessione decidono di utilizzarla. Nonostante questa capacità, si consiglia generalmente di evitare l’uso di TLS per comprimere i dati, soprattutto dopo l’attacco CRIME (consultare il Problemi di sicurezza TLS sezione sotto) è stato trovato per essere in grado di sfruttare i dati compressi per il dirottamento della sessione.

Imbottitura

Il riempimento aggiunge ulteriori dati a un messaggio prima che venga crittografato. È un processo crittografico comune che viene utilizzato per aiutare a evitare che suggerimenti nella struttura dei dati crittografati diano il suo vero significato. TLS generalmente applica il riempimento PKCS # 7 ai record prima che vengano crittografati.

Protocollo di avviso

Se la connessione o la sicurezza diventano instabili, compromesse o si è verificato un errore grave, il protocollo di avviso consente al mittente di avvisare l’altra parte. Questi messaggi hanno due tipi, avvertimento o fatale. Un messaggio di avviso indica che la sessione è instabile e consente al destinatario di determinare se la sessione deve essere continuata o meno.

Un messaggio fatale indica al destinatario che la connessione è stata compromessa o si è verificato un errore grave. Il mittente dovrebbe chiudere la connessione dopo aver inviato il messaggio. Il protocollo di avviso contiene anche informazioni su ciò che sta causando il problema di connessione particolare. Ciò può includere errori di decodifica, un’autorità di certificazione sconosciuta, un parametro illegale e molto altro.

TLS & il modello OSI

Il modello OSI è un modo per concettualizzare e standardizzare il modo in cui guardiamo ai nostri diversi sistemi e protocolli di comunicazione. È importante notare che è solo un modello e alcuni dei nostri protocolli non sono conformi ad esso.

L’OSI ha sette livelli separati che mostrano i livelli su cui operano i protocolli, TLS non si adatta a nessuno. Scorre su un altro protocollo di trasporto come TCP, che dovrebbe implicare che si trova sopra il quarto livello, il livello di trasporto. Viene utilizzato soprattutto come livello di trasporto, ma poiché conduce le strette di mano, ciò implica che fa parte dei livelli di presentazione o applicazione.

Come puoi vedere, TLS semplicemente non è conforme al modello OSI. Ciò non significa che TLS sia rotto o sbagliato, semmai dimostra solo che il modello OSI è difettoso e non è in grado di tenere conto di tutti i nostri protocolli di comunicazione.

Utilizzo TLS

TLS viene utilizzato per garantire una parte significativa delle nostre comunicazioni online. Normalmente è implementato su protocolli come il TCP (Transmission Control Protocol), ma può anche essere utilizzato in Datagram Congestion Control Protocol (DCCP) e User Datagram Protocol (UDP).

Può proteggere protocolli come HTTP, SMTP, FTP, XMPP e NNTP, così come altri. L’applicazione più comune è come Hypertext Transfer Protocol Secure (HTTPS), che protegge la connessione tra un browser Web e un sito Web. Puoi sapere quando HTTPS viene utilizzato per proteggere la tua connessione online, perché una piccola icona a forma di lucchetto verde apparirà a sinistra dell’URL nella parte superiore del browser.

TLS può anche essere usato per costruire VPN, come in OpenConnect e OpenVPN. Utilizza le sue funzionalità di crittografia e autenticazione per formare un tunnel in grado di collegare tra loro host e reti. Le tecnologie VPN basate su TLS come OpenVPN sono vantaggiose rispetto a alternative come IPsec, perché OpenVPN non è noto per avere seri problemi di sicurezza. Queste VPN possono anche essere più facili da configurare.

Un altro dei suoi usi è quello di e-mail sicura tramite STARTTLS. Quando TLS è implementato, impedisce agli aggressori di accedere ai messaggi mentre viaggiano tra i server di posta.

Problemi di sicurezza TLS

Come la maggior parte dei protocolli, TLS ha avuto un certo numero di vulnerabilità passate e attacchi teorici contro le sue varie implementazioni. Nonostante questo, le ultime versioni sono considerate sicure per scopi pratici.

Le versioni precedenti, come SSL 2.0 e 3.0 (e TLS 1.0, che è essenzialmente uguale a SSL 3.0) presentano numerosi difetti di sicurezza, ma poiché sono protocolli obsoleti e deprecati, non entreremo nei dettagli. Dovresti invece utilizzare TLS 1.2 e 1.3 per proteggere le tue connessioni.

Le versioni più recenti di TLS hanno numerosi aggiornamenti che lo rendono meno vulnerabile rispetto a SSL. Nonostante ciò, il protocollo ha ancora avuto i seguenti problemi di sicurezza:

Attacchi di rinegoziazione

Una delle caratteristiche di TLS è che consente alle coppie client e server di rinegoziare i parametri della loro connessione esistente. Nel 2009, è stato scoperto che questo potrebbe essere sfruttato dagli aggressori in modo che possano iniettare il traffico per far sembrare che provenga dal client. I server accetteranno la richiesta come legittima, il che significa che gli aggressori potrebbero potenzialmente manipolare i messaggi in uscita.

Questo attacco non consente all’attaccante di vedere la risposta, ma ha ancora il potenziale per essere dannoso. Un’estensione che impedirà questi attacchi è attualmente uno standard proposto.

BESTIA

L’attacco Browser Exploit Against SSL / TLS (BEAST) è stato scoperto per la prima volta dai ricercatori nel 2011. Sfrutta il blocco di cifratura che incatena la vulnerabilità in TLS, che può essere utilizzato per decrittografare i messaggi. Questo attacco riguarda solo TLS 1.0, che è una versione precedente e più debole del protocollo. Sebbene non sarà deprecato fino al 2023, gli utenti dovrebbero invece utilizzare le versioni 1.2 e 1.3.

Attacchi temporali

Questi attacchi ai canali laterali analizzano il tempo necessario per l’esecuzione di un algoritmo, quindi utilizzano tali informazioni per lavorare all’indietro e capire la chiave. Nel 2013, è stato scoperto che l’attacco Lucky Thirteen sfrutta sia un attacco di cronometraggio sia un attacco di oracolo di riempimento mentre il codice di autenticazione dei messaggi (MAC) viene verificato. Questo attacco può essere utilizzato per interrompere l’algoritmo TLS, sebbene non sia considerato pericoloso per la maggior parte degli utenti TLS.

CRIMINALITA ‘ & VIOLAZIONE

L’attacco CRIME funziona contro una serie di protocolli. Quando i dati sono stati compressi, possono ottenere contenuti dai cookie di autenticazione. Queste informazioni possono essere utilizzate per il dirottamento della sessione. Sebbene influisca su una serie di protocolli, l’attacco è particolarmente preoccupante quando viene utilizzata la compressione HTTP, poiché non esistono strategie di mitigazione efficaci.

Nel 2013, l’exploit di ricognizione ed esfiltrazione del browser tramite compressione adattiva dell’ipertesto (BREACH) ha influito sulla compressione HTTP in modo simile. Questa versione dell’attacco può recuperare indirizzi e-mail e altri dati preziosi che sono stati crittografati con TLS. L’attacco BREACH può essere mitigato disabilitando la compressione HTTP o utilizzando tecniche come la protezione della falsificazione delle richieste tra siti (CSRF).

Attacchi downgrade

Si tratta di attacchi che inducono i server a utilizzare versioni precedenti e meno sicure di TLS. Gli aggressori potrebbero utilizzare queste tecniche per negoziare l’uso di scambi di chiavi e cifre meno sicure. L’attacco Logjam è un buon esempio perché potrebbe rendere i server vulnerabili utilizzare Diffie-Hellman a 512 bit, che è debole. Gli aggressori possono quindi rompere questo meccanismo di scambio di chiavi ed estrarre le chiavi, consentendo loro l’accesso completo alla sessione.

heartbleed

Heartbleed è stato un difetto di sicurezza che è stato accidentalmente introdotto nella libreria di crittografia OpenSSL nel 2012, ma non pubblicizzato fino al 2014. Poiché si tratta di un’implementazione così comunemente usata di TLS, ha causato un danno globale significativo.

Uno degli sviluppatori per l’estensione heartbeat TLS ha aggiunto una vulnerabilità di sovraccarico della lettura del buffer, che consente di esporre alcuni dati extra. L’errore non è stato rilevato quando il codice è stato rivisto, il che ha portato a una serie di attacchi significativi.

Poiché la libreria OpenSSL è implementata così ampiamente, il costo internazionale di mitigazione del problema è risultato piuttosto costoso. Gli amministratori del server hanno dovuto installare la nuova patch e rigenerare i certificati e le coppie di chiavi che potrebbero essere stati compromessi durante il periodo di due anni in cui la vulnerabilità esisteva.

ANNEGARE

L’attacco Decrypting RSA con Obsolete and Weakened eNcryption (DROWN) è stato annunciato nel 2016 e sfrutta il supporto del server per SSL 2.0. Utilizza un attacco di testo cifrato scelto contro server che supportano ancora SSL 2.0, nonché quelli che condividono lo stesso certificato di chiave pubblica con un altro server che supporta SSL 2.0.

Quando è stato annunciato l’attacco, potrebbe essere lanciato con costi iniziali di installazione di circa $ 18.000 e circa $ 400 per ogni attacco separato. Quando l’attacco DROWN ha esito positivo, acquisisce le chiavi di sessione.

L’attacco può essere mitigato non condividendo i certificati del server. Il gruppo OpenSSL ha anche rilasciato patch che rimuovono il supporto per protocolli e cifre precedenti, ma funzionano solo se il certificato del server non è condiviso con altri server che supportano SSL 2.0.

Unholy PAC

Questo attacco è stato riscontrato nel 2016. Sfrutta i punti deboli riscontrati nel WPAD (Web Proxy Autodiscovery Protocol). Quando un utente tenta di visitare un sito Web tramite una connessione crittografata TLS, il difetto può rendere visibile l’URL. Poiché a volte gli URL vengono inviati agli utenti come forma di autenticazione, l’attacco Unholy PAC consente a un utente malintenzionato di assumere l’account di un utente.

TLS è sicuro?

Mentre può sembrare che ci siano molti problemi di sicurezza, la realtà è che la maggior parte di questi sono piuttosto minori e possono o sono stati mitigati. Man mano che la tecnologia avanza, vengono scoperte vulnerabilità e vengono sviluppati nuovi attacchi, TLS continuerà ad avere più problemi di sicurezza. Nonostante ciò, per ora e per il prossimo futuro, sembra che TLS rimarrà uno degli strumenti principali e più affidabili che utilizziamo per proteggere il nostro mondo online.

Tecnologia aziendale per la sicurezza informatica da TheDigitalArtist su licenza CC0