The Onion Router (comunemente chiamato Tor) è un software che implementa la tecnica omonima dell’onion routing per contrastare quella forma di censura chiamata analisi del traffico.
Per capire il funzionamento e l’utilizzo di Tor, dobbiamo essere sicuri di conoscere quale problema vuole risolvere. Cosa è, quindi, l’analisi del traffico?

Con analisi del traffico si definisce una tecnica censoria basata sull’analisi passiva del traffico prodotto da una macchina o da un gruppo di esse. Ispezionando i pacchetti che escono da una rete, un attaccante è in grado di inferire un sacco di informazioni riguardanti l’origine di quei pacchetti. Pensate a una mail: un attaccante che ne intercetta il contenuto è in grado di sapere chi sia il mittente, a quale indirizzo sta scrivendo e cosa gli vuole comunicare. Quando questo concetto viene spostato a livello di traffico di rete lo scenario non cambia: un attaccante che intercetta un qualsiasi traffico di rete è in grado di inferire, dall’header dei pacchetti, chi li ha inviati, chi li riceverà e, guardando il body, cosa si vogliono comunicare.
Una prima soluzione a questo tipo di problemi è quello di impiegare la crittografia, sfortunatamente, in entrambi gli scenari descritti in precedenza, la crittografia stessa non è in grado di fermare l’analisi del traffico ma solo di impedire la lettura dei contenuti del corpo del messaggio: per come deve funzionare la comunicazione su Internet, le informazioni dell’header sono in chiaro e disponibili a chiunque riesca a leggerne il contenuto.
Questo problema è stato affrontato da tempo, con soluzioni più o meno efficaci: all’inizio degli anni 80 David Chaum propose le Mix Networks, una serie di proxy server da utilizzarsi in cascata. In questo modo un attaccante doveva ispezionare il traffico in più punti (all’uscita di ogni proxy, per la precisione) per poter inferire qualcosa di utile sul mittente del pacchetto che usciva dall’ultimo nodo della catena. L’idea di Chaum, benchè non utilizzata, è stato il seme che ha lanciato la ricerca sull’onion routing, letteralmente routing a cipolla.
La ricerca sull’onion routing è stata portata avanti nel corso degli anni 90 dallo United States Naval Research Laboratory che ha poi passato il lavoro alla Electronic Frountier Foundation e, Venerdì 13 Agosto 2004 al 13th USENIX Security Symposium, Tor è stato presentato al pubblico. Da li in poi lo sviluppo del programma è andato in crescendo, gli sviluppatori hanno salutato la EFF che ha dato casa alle prime versioni del programma e, al giorno d’oggi, Tor è un prodotto dell’ormai a se stante Tor Project.
Ma non è solo con la storia che si impara come funziona un protocollo, quindi rimbocchiamoci le maniche e guardiamo da vicino come funziona un programma. Guardiamo la prima figura:

i nodi con un simbolo + verde sono relay della rete Tor, Jane e Bob sono dei server pubblicamente raggiungibili da Internet, Alice è la nostra protagonista e sta utilizzando Tor in modalità client. Dave è un particolare server pubblico chiamato “Tor directory server”, lui e i suoi simili forniscono la lista pubblica di relay Tor e la mantegono periodicamente aggiornata. Il primo passo compiuto dal client Tor di Alice è, appunto, quello di contattare un directory server per ottenere la lista dei nodi marchiati con un simbolo + verde.
A questo punto Alice istruisce il proprio client di contattare il server Bob, per esempio perchè vuole visitare una pagina web ospitata li sopra, il nodo Tor di Alice si preoccupa di costruire una catena di nodi attraverso i quali invierà la richiesta, come mostrato nella seconda figura:

nella terminologia di Tor, i nodi prendono un particolare nome a seconda della loro posizione nella catena di comunicazione o circuito: il primo nodo si chiama Guard Node (nodo di guardia), il secondo Middleman Node (nodo intermediario) e il terzo Exit Node (nodo di uscita). La scelta dei nodi di una catena viene effettuata dal client di Alice in base alle informazioni ricevute dal directory server: ogni relay Tor quando si registra presso le directory invia il proprio indirizzo ip e una serie di caratteristiche. I nodi di uscita sono i più importanti: contattando loro personalmente le macchine esterne alla rete Tor devono dire esplicitamente di essere volenterosi e in grado di farlo. Parimenti, i nodi di guardia vincono questo status quando hanno servito la rete Tor per un lungo periodo: sono nodi fidati a cui possiamo affidare il primo passo per entrare nella rete. Tutti i rimanenti relay sono considerati nodi intermediari. Il perchè di queste scelte e di questa classificazione si può spiegare brevemente dicendo che sono il primo e l’ultimo nodo della catena che rappresentano un ottimo punto per attaccare il protocollo, purtroppo parlare di attacchi al protocollo Tor meriterebbe una serie di articoli a se stante, quindi per questa introduzione ci limitiamo a una seppur stringata spiegazione.
Un altro punto importante è osservare il colore delle frecce: la comunicazione che avviene all’interno della rete Tor è completamente crittata, questo impedisce a un attaccante che riesca a intercettare uno qualsiasi di quei messaggi, di ricostruire tutto il flusso. Nella figura, l’ultimo collegamento (tra Exit e Bob) non è crittato ma questo dipende dal tipo di richiesta che ha effettuato Alice a monte del circuito: nel nostro esempio abbiamo ipotizzato una pagina web servita con HTTP, se Alice avesse usato HTTPS anche l’ultimo link sarebbe stato verde. Va ribadito, comunque, che l’ultima comunicazione è estranea alla trasmissione di informazioni all’interno del protocollo di Tor.
Per capire come mai questo protocollo è resistente agli attacchi di analisi del traffico è utile analizzare cosa accade all’interno di un circuito:

questo è il pacchetto che viene inviato da Alice a Guard, il contenuto della buccia rossa è protetto con le chiavi di Guard stesso, quindi solo lui può leggere cosa c’è scritto. Leggendo le istruzioni contenute in questo strato, Guard capisce che deve inviare il resto del contenuto a Middleman:

questo è il contenuto visto da Middleman: come nel caso precedente la buccia di colore verde è leggibile solo dal destinatario. In questo strato Middleman legge che deve spedire il resto del contenuto ad Exit. Come potete notare, già a questo livello è sparita ogni indicazione riguardante Alice.

Questo è l’ultimo passaggio: Exit riceve da Middleman quello che rimane della cipolla, legge il contenuto decifrabile solo da lui e scopre che deve fare richiesta, secondo l’esempio che ci sta accompagnando per tutto l’articolo, di una pagina web presso il server Bob.
Una volta che Bob ha trasmesso il contenuto necessario ad Exit questo impacchetterà tutto e spedirà a Middleman il quale, vedendo che gli sta arrivando una risposta da Exit, passerà a Guard e questi chiuderà il circuito inviando la risposta ad Alice.
In questo modo il protocollo è in gradi di sconfiggere l’analisi del traffico: l’utilizzo della crittografia e del “remixaggio” dei pacchetti impedisce a un attaccante che osserva il traffico prodotto da uno qualsiasi dei nodi di correlarne il contenuto e il mittente. Inoltre, per prevenire che uno dei nodi del circuito possa leggere arbitrariamente il contenuto delle risposte, la comunicazione viene protetta con una chiave di sessione, che viene modificata frequentemente, apribile solo da Alice.

Per il momento questo è tutto: spero di aver stuzzicato il vostro interesse in questa tecnologia, l’installazione e l’utilizzo di questo programma sono sicuramente materiale per un prossimo articolo!

Marco Bonetti