Principali vulnerabilità del certificato SSL

Le comunicazioni su internet avvengono tramite una pletora di scambi preliminari di segnali, handshakes e verifiche di vario tipo.

A mettere ordine in tutta questa quantità di processi ci sono i protocolli.

Nello specifico, quello SSL/TLS è lo standard per l’instaurazione e il mantenimento di connessioni sicure e criptate.

Tuttavia, è sempre possibile individuare delle vulnerabilità in alcuni processi o software di cifratura, per cui la robustezza dei protocolli viene a vacillare

In questo articolo analizzeremo alcune vulnerabilità del protocollo SSL/TLS che potrebbero ancora affliggere dispositivi obsoleti.

1. Panoramica sul certificato Secure Socket Layer
2. Possibili vulnerabilità del certificato SSL/TLS
3. Strumenti per testare e prevenire le vulnerabilità del protocollo SSL/TLS
4. Conclusioni

Panoramica sul Secure Socket Layer

Uno dei principali protocolli su internet è l’SSL/TLS.

Garantisce che i dati condivisi tra due entità siano al sicuro da intromissioni di terzi non autorizzati.

Per esempio, SSL è il protocollo che protegge il dialogo tra browser e server.

SSL (Secure Socket Layer) è in realtà un nome “legacy”, rimasto invariato nonostante i cambiamenti. La sua evoluzione, infatti, è il protocollo TLS (Transport Layer Security), nelle sue varie versioni.

Al di là dei nomi, SSL è usato per stabilire connessioni autenticate e crittografate, dunque sicure.

Il certificato SSL correla l’identità di un sito ad una coppia di chiavi: una pubblica e una privata.

1. Quella pubblica è quella inviata, per mezzo del TLS, ai dispositivi con i quali si intende stabilire una connessione criptata
2. La chiave privata, invece, è nascosta sul server e serve a identificare in modo univoco i documenti presentati alla rete

È il funzionamento classico del sistema crittografico a chiave pubblica-privata: il messaggio criptato con la chiave pubblica può essere decriptato solamente con la chiave privata; quindi, anche intercettando la trasmissione della chiave pubblica, un attaccante non sarebbe in grado di decriptare i messaggi trafugati.

È per questo motivo che si raccomanda di effettuare pagamenti solamente su eCommerce che hanno il protocollo HTTPS: per evitare di consegnare il proprio denaro a dei criminali.

In aggiunta, il protocollo SSL prevede delle informazioni identificative univoche del portale, cosicché se una autorità certificata lo riconosce come sito web sicuro, anche browser degli utenti lo accetteranno come tale ed instaureranno con esso delle connessioni.

Infine, il protocollo di trasferimento dati diventa sicuro (HTTPS) se contiene il protocollo SSL/TLS validato da una autorità certificata riconosciuta.

L’ottenimento di questo riconoscimento è sinonimo di sicurezza:

1. innanzitutto, si è certi che la connessione instaurata con il server sia criptata
2. inoltre, è garanzia del fatto che il server contattato sia effettivamente quello in possesso della chiave privata corrispondente a quella pubblica contenuta nel certificato
3. infine, si ha la certezza che, in caso di attacchi Man in the Middle, sarà facile identificare dei documenti alterati

I siti sprovvisti di questo certificato non assicurano alcuna protezione crittografica dei dati.

Anzi, dato che non ci sono certificazioni delle autorità preposte, non si ha certezza neanche sulla loro efettiva affidabilità.

Possibili vulnerabilità in SSL/TLS

Sembrerebbe tutto molto sicuro ed efficace. In realtà la complessità di queste tecnologie porta con sé una serie di problematiche e punti deboli, con i quali si fanno i conti ancora oggi.

I protocolli web non sono esattamente tecnologia recenti, nascono quasi in concomitanza con l’invenzione dei computer.

Tuttavia, di pari passo con le innovazioni tecnologiche, sono venute a galla anche diverse vulnerabilità.

In generale, molti bug del certificato SSL scovati e risolti negli anni sono relativi ai sistemi con i quali si criptano i dati.

• ROBOT
• LogJam
• WeakDH

sono solo alcuni degli attacchi osservati e documentati negli anni.

Prendevano tutti di mira il sistema di scambio delle chiavi, poiché una sua compromissione consente di leggere in chiaro le conversazioni altrimenti criptate.

Inoltre, un altro fattore di debolezza è il sistema di crittazione dei dati. RC4 era uno di quelli e veniva usato massicciamente nei primi anni 2000. Con il tempo è diventato obsoleto, così come la maggior parte dei cifrari ad RSA.

Molti dei problemi tutt’ora riscontrabili sono riconducibili a vulnerabilità o obsolescenze nei sistemi del passato.

Le versioni di TLS 1.2 e precedenti soffrono attacchi di downgrade come POODLE e FREAK.

Ma vediamo in dettaglio alcune delle principali vulnerabilità note del certificato SSL, che potrebbero essere ancora presenti in sistemi mal configurati o obsoleti.

• Attacco POODLE

È stato scoperto nel 2014. Sostanzialmente, questo attacco costringe i browser moderni ad adottare protocolli obsoleti come SSL3.0. In questo modo risulta molto più facile per l’hacker decifrare i messaggi criptati con metodi poco moderni.

La conseguenza del trasmettere dati in chiaro è il furto immediato di dati sensibili, quali:

• dati si sessione
• cookie
• password

• Attacco FREAK

Questo attacco è rimasto dormiente per oltre 25 anni ed è stato notificato solamente nel 2015.

Sfrutta delle vulnerabilità nella modalità di crittazione nei protocolli SSL/TLS obsoleti.

La debolezza deriva dall’istituzione di un limite ai bit massimi usabili per le chiavi RSA. Il vincolo era stato imposto dall’ente americano per la sicurezza che voleva essere in grado, all’occorrenza, di decriptare informazioni importanti.

• Attacco LogJam

L’attaccante riesce ad effettuare un downgrade della connessione, in modo tale da ridurre l’efficacia della tecnica crittografica utilizzata.

Il man in the middle è infatti capace di

• intercettare
• leggere
• manipolare

le informazioni trasferite nella connessione.

Anche qui, il problema nasce da un algoritmo di scambio delle chiavi obsoleto, quello di Diffie-Hellman, ormai generalmente considerato deprecato.

• Attacco Beast

In questo caso, l’attaccante è in grado di leggere i contenuti della connessione, sfruttando degli algoritmi di criptazione deboli in TLS 1.0 (uno su tutti CBC, Cipher Block Chaining).

Fino a pochi anni fa, la maggioranza dei server era suscettibile ad attacchi come il BEAST, ma con l’avvento di versioni nuove nei protocolli e nuove metodologie di cifratura, questa vulnerabilità è stata notevolmente ridimensionata e relegata ai vecchi server.

• Il bug Heartbleed.

Questo bug si è originato nel software di cifratura opensource OpenSSL.

Ancora una volta, grazie ad una vulnerabilità è diventato possibile

• intercettare
• decriptare il traffico tra due entità.

Il bug consente di leggere nella memoria dei dispositivi che ne fanno uso, comportando la totale perdita di segretezza delle chiavi private di cifratura.

Quindi oltre ad un facile furto di dati in chiaro, si profila la possibilità di imitare un’entità, qualora si sia in possesso della chiave privata. Fortunatamente esistono delle versioni non vulnerabili del software, tuttavia rimangono sempre dei dispositivi obsoleti vulnerabili.

Strumenti per testare e prevenire le vulnerabilità del protocollo SSL/TLS/h2>

È immediato desumere che parte dei problemi relativi agli attacchi presentati derivino

• dall’obsolescenza dei protocolli
• delle tecniche di criptazione.

Pertanto, le norme preventive che si possono adottare derivano parzialmente da questa problematica.

• Aumentare la lunghezza delle chiavi crittografiche

Abbiamo visto come alcuni attacchi cercassero di condurre i sistemi di crittografia verso uno standard a 512 bit (lunghezza della chiave). È consigliato, al giorno d’oggi, di porre il limite minimo a 2048 bit per le chiavi RSA.

Nel caso si voglia ottenere una sicurezza maggiore, è possibile aumentare il numero di bit nelle chiavi.

È interessante notare, però, che oltre una certa soglia di bit, il livello di sicurezza acquisito non vale più l’aumento di dimensioni della chiave. Si rischia di rendere molto lenta la connessione, in quanto ogni scambio va decodificato con chiavi immense.

Esistono altri algoritmi, estremamente più efficienti e sicuri, che però non sono ancora universalmente adottati, specialmente su dispositivi obsoleti.

• Aggiornare i protocolli

La stragrande maggioranza delle vulnerabilità risiede in protocolli obsoleti. Le tecnologie SSL esistono dagli anni ’90, mentre il TLS è oggi arrivato alla versione 1.3.

Per quanto riguarda le versioni del protocollo precedenti alla TLS 1.1, l’imperativo è aggiornare il certificato quanto prima.

Alcune versioni sono così obsolete che è possibile portare a termine un attacco su due siti differenti anche se risiedono su server diversi, semplicemente a causa dell’omonimia.

1. L’attacco POODLE prolifera su dispositivi che adottano il protocollo SSL nella versione 2.0 con connessioni non sicure
2. mentre TLS 1.0 e TLS 1.1 sono ancora soggetti ad attacchi BEAST, sebbene siano notevolmente più sicuri dei predecessori.

L’ideale sarebbe adottare il protocollo TLS 1.3, ma anche il TLS 1.2 è accettato e non soffre di pericolose vulnerabilità come le precedenti versioni.

• Proteggere le chiavi private

Le chiavi private sono fondamentali nelle moderne implementazioni di cifratura.

Perdere la chiave privata equivale a perdere parte della propria firma sul web.

Inoltre, queste andrebbero generate e mantenute su apparecchi dedicati: evitate le autorità certificate che si propongono di produrle per voi.

• Utilizzo di algoritmi di cifratura avanzati

Alla base dei protocolli di sicurezza nelle comunicazioni, c’è l’idea di poter trasmettere privatamente i dati esclusivamente a chi li vogliamo comunicare. Per raggiungere questo obiettivo si usano specifici pacchetti di cifratura.

I più moderni, a fronte di una ridotta dimensione delle chiavi, offrono molti bit di sicurezza.

Ad esempio, i servizi basati su AEAD (Authenticated Encryption with Associated Data) sono da preferirsi fortemente ad altri notoriamente deboli e obsoleti come RC4 o particolari soluzioni ad RCA con un algoritmo di scambio delle chiavi prevedibile.

Conclusioni

Abbiamo visto come i protocolli di sicurezza su internet siano alla base di connessioni sicure e private.

Se si vuole assicurare l’integrità delle informazioni scambiate con un client occorre dotarsi dei più recenti protocolli di sicurezza.

Non è possibile scegliere con poca attenzione il software di cifratura delle informazioni, poiché la stragrande maggioranza delle vulnerabilità si originano da lì.

Infine, è fondamentale riporre con estrema cura le chiavi private, in quanto

• sono strumento essenziale per la cifratura
• rappresentano anche la prova dell’attendibilità del sito