Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Quella (finta) sicurezza dei certificati SSL

pittogramma Zerouno

Secure Sockets Layer

Quella (finta) sicurezza dei certificati SSL

03 Dic 2010

di redazione TechTarget

Le minacce potenziali nell’uso in azienda del protocollo Secure Sockets Layer non sono banali. Ma è possibile identificare i potenziali sistemi vulnerabili e quindi rendere l’organizzazione meno esposta a rischi

Molti utenti e alcune imprese fanno troppo affidamento su SSL, confidando che sia una panacea per la sicurezza Internet. In realtà, l’implementazione di SSL su un sito non protegge un’organizzazione da tutte le vulnerabilità di sicurezza Web, ma fornisce – nella migliore delle ipotesi – una connessione cifrata tra il client e il server.

Questo articolo illustra i motivi per cui le aziende dovrebbero valutare attentamente i rischi per le loro organizzazioni e cosa possono fare per ridurre al minimo tali rischi.

 

Stato dell’SSL: vulnerabilità e possibili attacchi

SSL è stato sviluppato nel 1994 da Netscape al fine di attivare connessioni sicure per il commercio elettronico su quello che allora era un mezzo di comunicazione emergente e conosciuto come Internet. Dall’epoca, sono stati fatti molti miglioramenti a SSL, come il protocollo Transport Layer Security (TLS), ma nel corso degli anni sono state scoperte diverse vulnerabilità e ci sono stati molti attacchi contro l’SSL. L’FEP SSL Observatory Project e Qualys SSL Labs hanno entrambi dimostrato carenze nella sicurezza dello stato attuale dell’SSL.

Nell’ambito della sua ricerca, il progetto FEP ha raccolto i certificati SSL in uso su Internet e ha notato un comportamento interessante di client e server. Una delle scoperte più importanti è che un significativo numero di server che utilizzano SSL e le autorità di certificazione (CA) sono vulnerabili e presentano problemi di sicurezza, soprattutto nei confronti attacchi man in-the-middle. E nonostante ciò, molti di questi server e certificati sono ancora ritenuti sicuri dagli utenti enterprise.

La presentazione di Qualys SSL Labs è stata invece incentrata sulle opzioni di cifratura del protocollo SSL e sulle sue debolezze nell’uso in Internet. Uno dei punti più importanti di questa presentazione è che i browser hanno solo bisogno di 10-20 CA installate per poter utilizzare SSL con la maggioranza di siti Web.

Di conseguenza, gli attacker più ambiziosi potrebbero causare danni rilevanti attraverso il Web, sfruttando meno di due dozzine di CA dal momento che ogni autorità di certificazione può firmare un certificato per ciascun nome DNS. E questo è sicuramente un motivo di preoccupazione. Uno degli attacchi evidenziati si basava su certificati deboli generati su Debian Linux; questi certificati sono stati creati prima che fosse resa disponibile una patch per OpenSSL la quale ha risolto il problema inerente i certificati deboli.

Tali certificati permettono attacchi man-in-the-middle, di collisione o in cui il cracker è in grado di dar vita a certificati vulnerabili forzando il certificato principale, abilitando così la visualizzazione di qualsiasi certificato. E’ anche presente una vulnerabilità di rinegoziazione SSL, che potrebbe consentire a un utente malintenzionato di prendere il controllo delle connessioni SSL.Sapere chi e quali sono le configurazioni vulnerabili agli attacchi e quali sono i rischi specifici per l’impresa è difficile, soprattutto se si considerano le configurazioni SSL complesse di oggi, che spesso includono il bilanciamento del carico e certificati wildcard. Le minacce per un’impresa non sono banali, ma è possibile identificare i potenziali sistemi vulnerabili.

Utilizzando il lavoro del team di ricerca menzionato in precedenza, non solo gli attacker possono identificare i server SSL di un’impresa, ma possono anche stabilire in che modo SSL viene utilizzato su tali server.

Una volta che l’attacker sa dove sono i server sicuri SSL può usare tali informazioni per lanciare attacchi, per esempio del tipo man-in-the-middle. Questi attacchi possono anche essere usati contro altri protocolli, per cui, per maggiore sicurezza, sarebbe bene estendere gli studi ai protocolli non HTTP che utilizzano SSL, come IMAP, SMTP o altri. Questo offre una comprensione più approfondita dell’utilizzo di SSL sui server e può aiutarvi a capire dove vengono impiegati certificati o protocolli non sicuri per la cifratura ma anche dove un attacker può sfruttare la cifratura usata in un sistema. Per accertarvi che un client sia vulnerabile agli exploit citati in precedenza, dovete controllare la versione del browser Web in uso sulla vostra rete attraverso un’analisi del traffico passivo o la verifica dei sistemi client.

Questo controllo potrebbe anche essere il grado di robustezza dei certificati dei server SSL e se tali macchine possono essere usate per sferrare un attacco al sistema o alle connessioni. Questo controllo potrebbe anche funzionare per i protocolli non HTTP, ma può essere più difficile da eseguire in quanto tali protocolli possono supportare diverse opzioni di crittografia o di uso frequente.

 

Strategia di difesa aziendale per l’SSL 

Per difendere l’impresa e gli utenti contro le minacce SSL, è necessario capire dove e come si utilizza SSL in azienda. Questo può essere fatto utilizzando metodi come quelli impiegati da FEP e Qualys, oltre al monitoraggio del traffico di rete o agli inventari delle applicazioni software utilizzate su client e server. Una volta che ciò è stato fatto, il primo passo è valutare il livello di competenza ed esperienza in tecnologie quali PKI e SSL, in quanto è piuttosto frequente configurare SSL in modo non sicuro sul lato server.

Sul lato client, l’uso di software aggiornati e di configurazioni sicure con un elenco attuale delle autorità di certificazione fidate, aiuta a prevenire gli attacchi che utilizzano SSL. Se la vostra impresa ha bisogno di complesse configurazioni SSL – come l’utilizzo di un acceleratore SSL o di smart card che supportano solo alcuni tipi di certificati – o di competenze per gestire la complessità, le configurazioni dovranno essere amministrate con attenzione, daro che è facile attivare configurazioni non sicure, come dimostrano le presentazioni citate.

Un ultimo controllo riguarda l’abilitazione – o whitelisting – delle autorità di certificazione necessarie all’utilizzate nei browser Web dell’organizzazione. Tuttavia, questo potrebbe richiedere uno sforzo notevole sia nell’individuazione di quali sono tali certificati sia nella disattivazione di tutti gli altri.

Si potrebbe partire dai certificati SSL contenuti nella presentazione di SSL Labs Qualys, integrando eventualmente autorità di certificazione aggiuntive se necessario.

Si può anche considerare l’utilizzo sui server di certificati Extended Validation, che forniscono un livello superiore di affidabilità rispetto agli attuali certificati standard.. Va sottolineato che i certificati EV non cambiano il protocollo SSL e hanno gli stessi problemi dei certificati regolari, però aiutano gli utenti a distinguere i diversi tipi di certificati e che li ha emessi. Inoltre, alzano il livello di sicurezza dei browser Web, i quali visualizzano una barra verde quando un certificato EV è in uso.

Concludiamo osservando che sono stati fatti comunque molti miglioramenti nei protocolli SSL/TLS, nei server e nei sistemi client per la protezione contro le vulnerabilità e gli exploit. I tool inclusi nei sistemi operativi e nelle applicazioni per la gestione e il supporto di SSL (e dei relativi sistemi a corredo) sono stati drasticamente migliorati. E dato che oggi sono ampiamente implementati, il mantenimento della sicurezza di SSL e dei relativi sistemi è fondamentale per la tutela della privacy in Internet.

Le imprese dovrebbero anche monitorare le discussioni relative a quali autorità di certificazione sono incluse di default nelle liste di affidabiltà presenti nei certificati all’interno del browser Web, al fine di sapere se sono aggiunte tutte le organizzazioni “not trust”. 

redazione TechTarget

Articolo 1 di 5