Ma Ssl è sicuro?

[O'Rei]

E-banking, e-trading, e-commerce, e-tutto. Un clic sul mouse ed ecco che i nostri soldi possono incamminarsi sulla rete, acquistare azioni in borsa, comprare un biglietto aereo o prenotare una camera in un hotel dall'altra parte del mondo. Diffidenti all'idea di spedire su Internet il numero della nostra carta di credito e i nostri dati personali, chiamiamo il call center del sito che ci interessa e dall'altro capo del filo ci risponde una suadente voce che ci garantisce che le tecnologie utilizzate sono a prova di bomba, che fanno uso dei più avanzati ed impenetrabili algoritmi di crittografia e che nemmeno un Arsenio Lupin nei suoi giorni migliori ed un Simon Templar dopatissimo riuscirebbero a mettere le mani sui nostri dati. Soddisfatti, mettiamo giù la cornetta, facciamo il nostro shopping online, poi apriamo il giornale e sprofondiamo nella disperazione più nera quando scopriamo che un hacker di 15 anni si è appena impadronito di un paio di milioni di numeri di carte di credito.
Suona familiare? Sicuramente sì, in un momento in cui il business si muove con forza verso Internet, attirato dai minori costi, dalla possibilità di raggiungere una clientela più ampia e soprattutto dagli incredibili vantaggi di organizzazione aziendale. E le risposte che vengono date alle nostre domande in termini di sicurezza spesso sembrano volerci convincere che quel lucchetto che durante la transazione appare sul nostro navigatore possieda virtù quasi miracolose.
In realtà, la complessità del problema è ben superiore al cifrare un paio di comunicazioni tra un client e un server. La sicurezza dei nostri dati coinvolge un ampio spettro di elementi, i parametri da tenere d'occhio perché nulla possa andare storto sono molto numerosi e, ancora una volta, l'elemento debole di tutte le trincee scavate intorno a quel numero di carta di credito resta quasi sempre l'essere umano.
"I nostri server utilizzano Ssl per la cifratura dei dati, garantendo così alle vostre transazioni il massimo livello di sicurezza". Quasi tutti i proclami di inaffondabilità di un sito suonano pressappoco così. In questo articolo cercheremo quindi di vedere da una parte se Ssl sia effettivamente così sicuro e dall'altra se il suo utilizzo sia una condizione sufficiente per garantire effettivamente l'inviolabilità dei dati.

Ssl, questo sconosciuto
Ssl è stato sviluppato negli anni '90 da Netscape ed è giunto finora alla versione 3. Le specifiche complete del protocollo (una sessantina di pagine) sono reperibili all'indirizzo home.netscape.com, mentre una introduzione più leggera si trova all'indirizzo docs.iplanet.com.
Lo scopo di Ssl è quello di garantire autenticazione e cifratura tra due applicazioni che dialogano attraverso un mezzo insicuro quale può essere Internet. Ssl si pone al di sopra del protocollo di trasporto (es.: tcp) e permette l'incapsulamento di dati e protocolli di più alto livello.
Ssl è strutturato in due strati, che prendono il nome di Record Protocol (che definisce il formato dei dati e le modalità di incapsulamento) e di Handshaking Protocol (che definisce le modalità per l'autenticazione, gli scambi iniziali di chiave e per la successiva trasmissione e ricezione dei dati cifrati).

Cosa succede quando un client (ad esempio il nostro navigatore) si connette al un server utilizzando Ssl? Semplificando un po' le cose, i passi seguiti sono nella maggior parte dei casi i seguenti:
1. Il client (es.: user@user.com) contatta il server (es.: www.server.com), inviandogli un "client hello" contenente una serie di dati quali la versione di Ssl utilizzata, i tipi di cifratura e di compressione supportati, un session id, 32 bit con data e ora correnti e 28 byte generati in maniera casuale.
2 Il server risponde inviando informazioni analoghe ("server hello"), cui segue il proprio certificato (quasi sempre di tipo X.509) ed un "key exchange message", necessario per la generazione di una chiave segreta qualora il certificato del server sia abilitato solo alla firma e non alla cifratura. Esso conterrà informazioni quali modulo ed esponente di una chiave rsa temporanea oppure parametri Diffie-Hellman. Infine, il server potrà richiedere a sua volta un certificato al client.
3. Il client riceve il certificato, ne controlla la validità e spedisce il proprio al server, ove questi ne abbia fatto richiesta.
4. Il server riceve l'eventuale certificato del client e a sua volta ne controlla la validità.
5. A questo punto, comincia la generazione delle chiavi segrete con cui verranno cifrate le comunicazioni successive. I particolari del processo dipendono da quali algoritmi sono stati selezionati nei passi precedenti. Nel caso venga utilizzato rsa, il client genera un "premaster secret" di 48 byte, lo cifra con la chiave pubblica del server (ricevuta con il certificato o con il key exchange message) e lo trasmette al server stesso.
6. Client e server generano il master secret dal premaster secret, combinandolo con i dati casuali trasmessi nei client hello e server hello, ed applicando in sequenza sha-1 e md5.
7. Il master secret appena generato è quindi utilizzato per generare finalmente, ancora tramite md5 e sha-1, la chiave segreta che verrà utilizzata nello scambio di dati, completa di initialization vector e message authentication code.
8. Client e server comunicano che l'handshake è terminato e che i messaggi successivi verranno cifrati con la chiave appena trovata.
9. Il trasferimento dati ha inizio.

[O'Rei]

La prima domanda è ovvia: è un protocollo sicuro? Procediamo per gradi: Ssl utilizza numerosi protocolli crittografici per le sue operazioni, quali rsa per le operazioni di autenticazione, Diffie-Hellman per la negoziazione di chiavi segrete, md5 e sha-1 per la verifica di integrità dei messaggi, des e rc2/rc4 per le cifratura dei dati. La sicurezza di Ssl sarà quindi innanzitutto subordinata alla sicurezza di tutti questi algoritmi, che puntano sulla difficile risolvibilità in tempi accettabili di particolari problemi matematici. Rsa, ad esempio, fa leva sulla difficoltà di fattorizzare numeri di grandi dimensioni. Al momento attuale, tutti gli algoritmi utilizzati da Ssl sono ritenuti sicuri: cioè non si conosce un procedimento matematico che ci permetta di calcolare, a partire da una chiave pubblica, la sua corrispondente privata. Allo stesso modo, non sappiamo di nessun sistema che ci consenta di ricavare un messaggio che restituisca un dato hash sha-1. E un attacco basato su un mero brute-forcing sarà vanificato utilizzando chiavi sufficientemente lunghe. A onor del vero, è bene ricordare che per md5 sono state trovate delle collisioni nella funzione di compressione (come riportato da Hans Dobbertin in "Cryptoanalysis of md5 compress"), ma questo fatto, da solo, non è sufficiente, almeno allo stato attuale delle cose, per parlare di una vera e propria vulnerabilità dell'algoritmo che ne pregiudichi la sicurezza.
Una prima conclusione è quindi che questi algoritmi, allo stato attuale delle conoscenze e delle capacità di calcolo a disposizione degli aspiranti intrusi, possono essere considerati sicuri.

Per quanto riguarda le specifiche di Ssl, non sono state trovate vulnerabilità o debolezze nelle modalità di handshaking o di incapsulazione dei dati. Pertanto, possiamo ulteriormente procedere con la nostra analisi e valutare il modo in cui tali specifiche e i protocolli sottostanti vengono poi effettivamente implementati nelle diverse applicazioni che ne faranno uso. E purtroppo qui cominciano a scorgersi le prime debolezze, come avvenne, tanto per fare un esempio, per l'implementazione di Ssl fatta proprio da Netscape nel Navigator fino alla versione 4.72, in cui era stato scovato un bug nella gestione dell'autenticazione del server: in particolare, quando una sessione Ssl veniva instaurata, il client effettuava i controlli sull'identità del server per le successive connessioni basandosi solo sull'indirizzo ip e non sul dns, permettendo pericolose intrusioni. Maggiori dettagli in merito, insieme ad un proof of concept, possono essere trovati su: www.cert.org.
In cima a tutto quello che abbiamo appena visto troviamo infine gli utenti, i quali dovranno poi utilizzare tali algoritmi e tali applicazioni. Nel corso di tale utilizzo, essi si troveranno spesso a dover prendere delle decisioni e come vedremo tra poco la sicurezza dei loro dati dipenderà fortemente dalle scelte che verranno fatte di volta in volta.

Il Man in the Middle
Un hacker che volesse mettere le mani sui dati in transito, dovrebbe cercare di mettersi in mezzo tra noi e il server, agendo da forwarder (o almeno da listener) tra le due parti. Esistono varie tecniche per mettere in piedi un simile scenario: ad esempio, è possibile andare a modificare i record di un opportuno dns server in maniera tale che la vittima risolva il nome del server sull'ip dell'attaccante. Un'alternativa è fornire false informazioni ai router che si occuperanno dell'instradamento dei pacchetti, per alterare le loro tabelle di inoltro e controllare in questo modo il tragitto dei dati. Se invece l'attaccante e la vittima si trovano sulla stessa lan, il metodo più agevole è spedire alla vittima dei dati arp falsi, in modo da far corrispondere l'ip del default gateway della vittima al mac address dell'attaccante.

Utilizzando opportunamente queste tecniche, è possibile frapporsi tra client e server, i quali dialogheranno con l'attaccante, convinti di parlare invece con la rispettiva controparte. Si parla in questo caso di Man In The Middle (m.i.t.m.), la cui applicazione costituisce una delle situazioni più pericolose per la sicurezza di una connessione. Per una connessione in chiaro e non autenticata non c'è scampo: l'hacker sarà in grado di monitorare il traffico, impersonare il client nelle comunicazioni con il server e viceversa, assumendo il controllo assoluto della comunicazione. Un certificato digitale mira proprio ad evitare che qualcuno possa spacciarsi per qualcun altro, legando, attraverso la firma di una terza parte fidata, una coppia di chiavi ad una persona o ad un'organizzazione, garantendo così l'autenticazione delle controparti.

Cominciamo a vedere per esempio come tale processo di autenticazione sia implementato all'interno del nostro navigatore e, a questo scopo, ci poniamo all'inizio del passo 3, in cui riceviamo il certificato da parte del server appena contattato. Tale certificato conterrà la chiave pubblica del server stesso, un'indicazione della Certification Authority che ha rilasciato il certificato stesso, una data di scadenza, un identificativo del domain name per cui è stato rilasciato il certificato (in questo caso sarebbe quindi www.server.com). Il tutto sarà poi firmato con la chiave privata dell'Autorità per la Certificazione stessa, allegando cioè al certificato un hash di tutti i dati che lo compongono e cifrando tale hash con tale chiave privata.
Il navigatore, alla ricezione del certificato, ricalcola l'hash dei dati e lo confronta con quello ricevuto, decodificato con la chiave pubblica dell'Autorità (le chiavi pubbliche delle principali autorità sono già presenti nel nostro browser). Se i due hash corrispondono, saremo sicuri che il certificato è autentico e che non è stato modificato. Inoltre, il client controlla che il certificato non sia scaduto e che il domain name riportato sul certificato corrisponda a quello con cui si sta cercando di connettersi. Se tutto va a buon fine, si sarà creata quindi una "trust chain" dalla Certification Authority all'entità per cui il certificato è stato emesso. Infine, il navigatore, cifrando il premaster secret con la chiave pubblica riportata sul certificato del server, può sincerarsi che il server sia effettivamente in possesso della chiave privata corrispondente. Tale cifratura, inoltre, farà sì che nessuno possa appropriarsi del premaster, dalla cui segretezza dipendono poi le session key che da esso verranno generate.

In uno scenario come quello appena descritto, riuscire a mettersi in mezzo e fare i propri comodi diventa un problema piuttosto complesso. L'attaccante potrà monitorare tutto il traffico ma non sarà in grado di contraffare la propria identità e sostituirsi ad una delle due parti. Inoltre, quando avverrà la negoziazione della chiave segreta per il trasporto dei dati, non sarà in possesso delle informazioni necessarie per la sua computazione e resterà pertanto tagliato fuori dalla comunicazione. Una soluzione al problema è quella utilizzata da dsniff, sviluppato da Dug Song (www.monkey.org) e consiste nel crearsi, utilizzando le librerie di OpenSSL, una propria coppia di chiavi ed un proprio certificato da fornire al client al posto di quello del server. Nemmeno qui però le cose risultano essere semplici, perché tale certificato non sarebbe firmato da una Certification Authority fidata, impedendo quindi la creazione della trust chain necessaria al client per riconoscere come autentica la chiave pubblica riportata sul certificato stesso. Il risultato è che sullo schermo della vittima apparirebbe un warning, indicante che l'identità del server contattato non è risultata verificabile. Ed ecco qui quello a cui abbiamo accennato prima: la tecnologia si ferma e comincia il cervello umano, perché sarà l'utente a dover scegliere se proseguire comunque oppure no e la sua sicurezza dipenderà unicamente dalla bontà della decisione.

[O'Rei]

L'attaccante ha comunque altre frecce per il suo arco. Una possibilità potrebbe essere comprare un certificato da Verisign e fornirlo assieme alla chiave pubblica al posto di quella del server al momento dell'handshaking con il client. Ma il navigatore si accorgerebbe del trucco, perché il domain name contattato non corrisponderebbe a quello riportato sul certificato. Risultato: un altro warning all'utente.
Un metodo per evitare questi scomodi warning, è per l'attaccante fare leva sul fatto che, nella stragrande maggioranza dei casi, un utente si collega al sito all'inizio in maniera non cifrata, semplicemente digitando www.server.com senza anteporre "https://". Il browser avvierà una normale connessione http alla porta 80 del server, che provvederà poi a ridirigere la connessione verso la 443 su https. L'attaccante in questo caso può intercettare la connessione non cifrata, mantenere tale connessione sul lato client e proseguire con una
connessione cifrata dal lato server. In questo modo, il client non entrerebbe mai in modalità cifrata e non richiederebbe alcun certificato. Unico problema: non apparirebbe il lucchetto nel navigatore della vittima, che avrebbe quindi la possibilità di accorgersi che qualcosa non va (la location bar riporterebbe http invece di https ma a questo si ovvia con un po' di Javascript, nascondendola e sostituendola con una fasulla). Un altro limite di questo attacco è che non funziona se il server richiede un certificato del client ma, fortunatamente per il nostro pirata, questo avviene a tutt'oggi per ben pochi siti.

Ammesso invece che l'attaccante abbia nel suo arsenale un certificato valido e una entry corrispondente sul dns, l'azione diventa ancora più insidiosa, perché la ridirezione dalla 80 alla 443 può avvenire sul server Ssl dell'attaccante, che ridigerebbe la connessione da www.server.com:80 a www.evil.com:443. Il domain name del certificato e della connessione corrisponderebbero, il browser non lancerebbe warning di sorta, il lucchetto sarebbe al suo posto e la location bar sarebbe sempre tenuta sotto controllo tramite Javascript.

Ma non basta...
Gli attacchi appena visti sono tutti possibili applicazioni del concetto di Man in The Middle e non pretendono di elencare tutte le possibilità. In tutti i casi analizzati, comunque, prudenza, buon senso ed un po' di attenzione da parte dell'utente sono sufficienti a far fallire l'attacco, semplicemente evitando di ignorare ciecamente i messaggi del navigatore, tenendo d'occhio il famoso lucchetto e collegandosi direttamente al server https senza affidarsi a ridirezioni. A valle di tutto quello che abbiamo detto, possiamo quindi concludere che, a meno di bug nell'implementazione (peraltro verificatisi finora con poca frequenza), Ssl costituisce un ottimo strumento di sicurezza, a patto che l'utente sia munito di un pizzico di paranoia.

Purtroppo però, questa piccola dose di paranoia è molto poco diffusa: quanti utenti, nei loro acquisti online, controllano ad ogni clic del mouse la presenza del lucchetto? Quanti hanno ancora abilitati i warning che informano quando si entra e si esce da zone sicure? Quanti digitano esplicitamente https prima dell'indirizzo?
E questa è solo la punta dell'iceberg, perché se gli utenti che prestano poca attenzione a quello che succede alle loro connessioni cifrate sono parecchi, altrettanto numerosi sono quelli che per esempio lanciano allegramente ogni eseguibile che arrivi via mail, senza controllarlo prima con un antivirus aggiornato. Anche perché, diciamolo chiaramente, crearsi una coppia di chiavi, un certificato corrispondente, effettuare un poisoning delle tabelle arp della vittima, installare e configurare un fake Ssl server con uno script in perl che modifichi in real time il codice html prima di inoltrarlo al destinatario, arricchendolo nel frattempo con opportuno codice Javascript, è decisamente molto complicato. Sarà molto più semplice per l'hacker far lanciare alla vittima un eseguibile che installi un semplicissimo key logger che registri le password che vengono digitate o un qualsiasi troiano che ci spedisca le chiavi private eventualmente presenti su disco o in memoria, oppure portare la vittima su una pagina web che esegua l'upload di cookies e di token di autenticazione verso la macchina dell'attaccante.
E se dal lato client le insidie non mancano, sul lato server le cose non sono certo più rassicuranti: i dati viaggiano cifrati, d'accordo. Ma una volta raggiunto il server? Anche qui le cose che possono andare storte fioccano, perché potremmo avere a che fare con un server Ssl perfettamente corazzato che utilizza cifrature a prova di attacco atomico ma con dietro un amministratore di rete che lascia aperti tutti i vari Unicode bug che settimana dopo settimana vengono riportati su Bugtraq. Un web server, a meno di applicare tutte le patch che man mano vengono rilasciate, sarà vulnerabile a ben più di un attacco e lo stesso discorso vale per le applicazioni che costituiscono il front-end della piattaforma di e-commerce o e-banking. Solo poche settimane fa, in un test effettuato su un campione di banche online, è risultato che quasi un terzo dei server iis analizzati risultava vulnerabile ad almeno una tipologia di remote exploit. Impartire comandi ad un server siffatto è spesso un gioco alla portata di qualsiasi script kiddie, che potrà in questo modo prendere il controllo della macchina stessa in pochissimi secondi. Cosa vi troverà sopra? Dipende da come sono strutturate le applicazioni e da come esse dialogano con i server in back-end ma i diversi scenari sono tutti ugualmente preoccupanti: molte informazioni saranno già disponibili tra le directory del server stesso, e molte di più saranno ottenibili monitorando da una parte le connessioni degli utenti, dall'altra quelle con i server in back-end, che spesso e volentieri non risultano essere cifrate. Nel caso peggiore, dal web server verrà lanciato un attacco vero e proprio ai server alle sue spalle, cercando di estrarne l'intero database utenti, e raggiungendo così il cuore della rete aziendale.
Non dimentichiamoci che Carlos Salgado, nel 1997, fu in grado di mettere le mani su oltre 100.000 numeri di carte di credito proprio sfruttando bug presenti su server web, bug peraltro notissimi e per i quali le patch erano disponibili da parecchio tempo.

In ultima analisi, quindi, è proprio il fattore umano a fare la vera differenza ed è auspicabile che da parte delle aziende online, invece di pubblicizzare la loro vera o presunta inviolabilità, si faccia uno sforzo mirato ad educare gli utenti ad evitare comportamenti a rischio e a fare proprio quel pizzico di paranoia di cui parlavamo prima. Per tutto il resto, purtroppo, siamo costretti a dipendere da elementi che si trovano fuori dal nostro controllo: possiamo passare settimane a setacciare i bug delle applicazioni che utilizziamo, ma avremmo serie difficoltà a fare la stessa cosa per tutto quello che sta oltre il nostro modem, oltre il quale è necessario fidarci delle competenze tecniche di chi sta dall'altra parte (a meno di provare noi stessi a verificare l'impenetrabilità dei server, ma un simile approccio è decisamente molto poco consigliabile).
Concludendo, possiamo dire che la tecnologia per rendere sicura una transazione su Internet è più che disponibile ma che Ssl da solo è ben lontano dall'essere sufficiente e che un clic sbagliato del nostro mouse o un amministratore di rete lento nel tappare i buchi possono vanificare in un microsecondo tutti i chilometri di filo spinato virtuale che proteggono quel numero di carta di credito.