Questa figura illustra il modo di operare di un normale server proxy. Essi inoltrano le richieste per conto degli utenti fornendo il loro indirizzo IP, nascondendo di conseguenza chi ha inizialmente ha effettuato la richiesta .
I server esterni a cui ci si collega attraverso un proxy vedranno generalmente le connessioni provenienti dall'indirizzo IP del proxy, non da quello del client. Questo garantisce una relativa privacy del client (il server, o chi analizzi il traffico diretto ad esso, non può conoscere l'indirizzo IP del client), ma viceversa può anche provocare problemi nel caso tali siti utilizzino l'indirizzo IP del client per scopi di autenticazione o di riconoscimento delle sessioni.
Il protocollo HTTP prevede però che un proxy possa inserire nelle richieste che inoltra al server degli header standardizzati, che permettono di riconoscere che la richiesta è stata inoltrata da un proxy, e possono contenere anche l'indirizzo IP del client, che in questo modo può essere noto ad un server opportunamente configurato. Quando viene usata questa funzionalità, il server web "si fida" dell'indirizzo del client inviatogli dal proxy, e non può in alcun modo verificare questa informazione. L'amministratore di un server proxy può decidere se inviare o meno questi header.
I proxy HTTP, a seconda dell'anonimato che riescono a fornire, possono essere suddivisi in:

• Non anonimi: modificano alcuni header trasmessi dal browser e ne aggiungono altri, mostrano anche l'indirizzo IP reale del richiedente. Sono molto facili da riconoscere da parte del server web.
• Anonimi: non trasmettono l'IP del richiedente, ma modificano o aggiungono alcuni header. Sono pertanto riconoscibili facilmente.
• Distorcenti: trasmettono un IP casuale, diverso da quello del richiedente e modificano o aggiungono alcuni header. Solitamente vengono scambiati per proxy Anonimi, ma offrono una protezione maggiore, in quanto il server web vede le richieste di un utente provenienti da indirizzi IP diversi.
• Altamente anonimi: non trasmettono l'IP del richiedente e non modificano gli header della richiesta. Sono difficili da riconoscere attraverso i normali controlli.

Per vedere se il proxy server consente una navigazione anonima, ossia se non rivela l'IP del client a nessun altro server della rete, è bene effettuare un operazione di "Who-is". Questa operazione può essere effettuata attraverso apposite pagine web che mostrano da quale indirizzo IP vedono partire la richiesta, solo per fare un esempio: whatismyipaddress.com
Se viene restituito l'IP del proxy server il test è superato e la navigazione è prottetta dal proxy server; viceversa se è resistuito un IP diverso, presumibilmente si tratta di quello del client, e il test è fallito.

3.2.2 Svantaggi dei proxy
Come già visto precedentemente, il protocollo HTTP è stateless, ovvero una richiesta non lascia alcuno stato nel server. Tuttavia, per realizzare applicazioni web complesse, sono stati sviluppati meccanismi a livello superiore come i cookies per costruire "sessioni". Questi meccanismi possono permettere al server web di continuare ad ottenere informazioni sul client nonostante gli sforzi fatti dal proxy per difenderne l'anonimato, in particolare possono permettere di riconoscere un utente di un server web anche se questi si collega da reti totalmente diverse.
Attraverso i cookie il server può correlare un utente “registrato” indipendentemente se questo è protetto o meno da un proxy server, quindi per rendere efficacie il proxy server un utente dovrebbe evitare di accettare i cookie, cosa non sempre possibile.
Un altro problema che si presenta è che l’utente deve completamente fidarsi del proxy server e del suo gruppo di amministrazione. Conoscendo sia l’indirizzo sorgente, che la richiesta e vedendo direttamente questa, il proxy server può collezionare lui stesso i dati che volevamo precedentemente nascondere, di conseguenza il problema non si risolve ma si sposta in un altro punto sulla rete.

 
3.3 THE SECOND GENERATION ONION ROUTER (TOR)
TOR [8] è un sistema di comunicazione anonima per internet, realizzato sulla versione "OpenSource" di un progetto militare della US Naval Research Laboratory dal nome “Onion Routing”, avente come fine la creazione di una rete di proxy a bassa latenza in grado di garantire un certo livello di anonimato ai suoi utenti.
Il progetto “Onion Routing” è basato sul modello MIX-NET [9] introdotto da Chaum nel 1981.
Gli utenti della rete Tor eseguono un “onion proxy” sulla loro macchina. Questo software si connette a Tor, e periodicamente negozia un circuito virtuale attraverso la rete. L'uso della crittografia a strati (per analogia con onion, che in inglese significa cipolla), permette di ottenere una perfetta segretezza in avanti. Più in particolare, ogni “onion router” decide a quale nodo della rete spedire i pacchetti e negozia una coppia di chiavi crittografiche per spedire i dati in modo sicuro. In questo modo, nessun osservatore posto in un punto qualsiasi del circuito, è in grado di monitorare la connessione.
Allo stesso tempo, l'onion proxy fornisce un'interfaccia SOCKS tramite la quale qualsiasi software di rete che la supporti può comunicare in forma anonima.
Un altro vantaggio di TOR è la realizzazione dei servizi (di rete) nascosti, per fare ciò non sono richiesti indirizzi IP pubblici, per tanto i servizi possono essere ospitati dietro dei firewall e dei NAT ma allo stesso tempo accessibili da chiunque.
Questi accorgimenti fanno di TOR una rete robusta, versatile ed al contempo sono a bassa latenza e questo lo rende adatto alla navigazione web, alla posta, instant messaging, SSH, IRC etc.
3.3.1 Funzionamento
L'idea alla base di TOR è molto semplice: ogni volta che Alice necessita di fruire di un determinato servizio S offerto da Bob, invece di inviare direttamente una richiesta in chiaro a Bob, Alice sfrutta un proxy ("Onion Proxy", d'ora in poi OP). Tale OP sceglie casualmente una serie di nodi intermedi (“Onion Router”, d'ora in poi OR) facenti parte della rete TOR, da utilizzare per inoltrare la richiesta. Ognuna delle tratte intermedie tra OP e Bob costituisce un circuito cui è associato un identificativo univoco di circuito (d'ora in poi CircID).
Per esempio se l'OP sceglie di utilizzare gli OR “tor₁” e “tor₂ ”, esisteranno due diversi CircId:
• CircId₁ associato alla tratta OP-tor₁
• CircId₂ associato alla tratta OP-tor₁-tor₂

Creazione di un circuito
Una volta scelto un percorso, l'OP si occupa di contattare ogni OR e negoziare con esso una chiave simmetrica associata al CircId relativo a tale tratta. Questa fase di setup è eseguita in modo incrementale, ovvero l'OP contatta direttamente solo il primo OR, i successivi circuiti verranno stabiliti sfruttando quelli preesistenti. Per esempio se l'OP ha scelto di utilizzare gli OR “tor₁” e “tor₂”:

1. contatterà “tor₁ ”, stabilendo un id di circuito e negoziando una chiave;
2. per estendere il circuito a “tor₂”, sfrutterà il circuito esistente, ovvero la comunicazione passerà attraverso “tor₁”;

In questo modo “tor₂” è in grado di negoziare una chiave con Alice, senza tuttavia avere modo di sapere chi è Alice.

Come è fatta una connessione
Per estendere un circuito o utilizzarlo per comunicare con Bob, l'OP incapsula gli identificativi dei CircId, gli header ed il payload del suo messaggio in una “cipolla” composta da una serie di strati, ognuno dei quali è crittografato con la chiave precedentemente negoziata con il rispettivo OR.
Per descrivere più formalmente una connessione TOR si premettere che: OP negozia le chiavi ' K₁' e 'K₂' rispettivamente con gli OR “tor₁” e “tor₂”; ‘E_K_n(M) ’ è l'operazione di crittografazione del messaggio 'M' con la chiave ' K_n';  '|' è l'operazione di giustapposizione di due stringhe. Una connessione TOR sarà composta nel seguente modo:
CircID₁|E_K₁(CircID₂|E_K₂(M))

Come si utilizza una connessione
La comunicazione tra Alice e Bob avviene nel seguente modo:

1. Alice chiede all'OP di contattare Bob;
2. l'OP stabilisce un circuito come sopra descritto;
3. l'OP crea la cipolla come sopra descritto e invia la stessa al primo OR;
4. il primo OR legge il , recupera la chiave associata a tale CircId e con essa decritta il primo strato ottenendo il successivo , cui inoltra lo strato più interno della cipolla;
5. si procede in questo modo fino a quando la richiesta giunge all'ultimo OR il quale, decrittando l'ultimo e più interno strato della cipolla, ottiene l'indirizzo del destinatario ed il messaggio reali;
6. l'ultimo OR esegue quindi la richiesta, riceve la risposta dal server e crittografa la risposta con la chiave associata al corrispondente CircId, inviandola al primo OR a ritroso lungo il circuito;
7. ogni OR a sua volta conosce i due CircId associati all'ingresso e all'uscita dello strato corrente (della cipolla), quindi incapsula questo strato in un ulteriore strato crittografato con la chiave associata al corretto CircId e lo inoltra al successivo (nel circuito a ritroso); lo schema si ripete fino a raggiungere i nodi sorgente e destinatorio;
8. l'OP una volta ricevuta la cipolla decritta i vari strati con le chiavi che aveva precedentemente negoziato, fino ad ottenere la risposta in chiaro

3.3.2 Tecnologia
TOR è scritto in C e, per realizzare quanto sopra spiegato con una buona dose di riservatezza, utilizza diverse tecniche di crittografia forte.
In primo luogo ad ogni OR sono associate due chiavi pubbliche Transport Layer Security (TLS): una identity-key a lungo termine ed una “onion-key” a breve termine.
• La identity-key è utilizzata per firmare i certificati TLS, per firmare la descrizione dell'OR pubblicata nelle directory e per firmare le directory stesse.
• L'onion-key è utilizzata per decrittare le richieste di setup di un circuito e negoziare, tramite l'algoritmo Diffie-Hellman, una ephemeral-key (la chiave simmetrica associata al CircID di cui abbiamo parlato più sopra ).
Le comunicazioni tra due OR inoltre sono ulteriormente crittografate utilizzando AES con chiave a 128 bit in counter mode, chiamata “link key”.

3.3.3 Problemi di sicurezza noti:

Trasparenza: La trasparenza dell'OP in realtà non è un problema, è una scelta di design. Diventa un problema questa viene ignorata come nei casi dei normali server proxy.La prima versione dell'Onion Routing prevedeva infatti che l'OP stesso si preoccupasse di filtrare i pacchetti, eliminando i dati rilevanti ai fini di una possibile identificazione del mittente.
Nella seconda versione (TOR), al fine di trovare una soluzione quanto più generalista possibile, si è scelto di eliminare questa feature demandandola all'utilizzatore. Per la navigazione web ad esempio è necessario affidarsi a proxy locali (esempio: privoxy) in grado di filtrare le richieste eliminando javascript, cookies header troppo specifici.

DNS: Un problema forse meno noto riguarda la risoluzione dei nomi DNS. Tante applicazioni infatti risolvono il nome di dominio a cui collegarsi prima di inviare la richiesta al proxy socks, ciò ovviamente vanifica tutti gli sforzi ingegneristici di TOR. Mozilla e SSH sono affetti da questo problema. Nel caso di Mozilla il problema viene aggirato utilizzando privoxy. Non esiste però una soluzione unica che sia generale e portabile, come richiederebbe il caso SSH.

Rilevamento: L'utilizzo di TOR può essere rilevato. È banale prelevare l'elenco degli OR e verificare se una connessione proviene o è diretta verso uno di questi nodi:
• lato client: un amministratore di rete potrebbe impedire l'utilizzo di TOR semplicemente bloccando tutte le connessioni verso gli tutti gli ip/porte specificati nella directory dei nodi di TOR. Questa limitazione è aggirabile (senza sostanziale perdita di anonimato) connettendosi tramite un tunneling cifrato o una VPN ad un OP -fidato- eseguito all'esterno; tuttavia questa soluzione non essendo contemplata dalla specifica di TOR richiede la presenza di specifici servizi su di una macchina fidata.
• lato server: è possibile che un qualche fornitore di servizi (ed è già avvenuto) modifichi i propri servizi a seconda della provenienza della richiesta da uno degli OR. Una soluzione a questo problema consiste nel concatenare un proxy aperto alla fine del circuito TOR.

OR ed Exit Policy: Al fine di evitare pericolosi abusi (problema di sicurezza per la rete TOR) ogni OR può stabilire delle exit policy, ovvero delle regole che stabiliscono quali sono i protocolli in uscita consentiti.
Un tipico esempio di queste limitazioni è rappresentato dall'SMTP: per evitare che la rete TOR sia sfruttata dagli spammer, tale servizio è infatti disabilitato di default.
Relativamente alle exit policy è necessario sottolineare due criticità.
In primo luogo se la maggioranza degli OR avesse delle policy restrittive tali da renderli degli OR di tipo “Intermedio”, l'anonimato della rete TOR verrebbe compromesso dall'accentramento in pochi OR di tutte le connessioni in uscita verso internet (facili analisi di tipo correlativo e pochi nodi da attaccare per compromettere la rete).
In secondo luogo se un avversario controllasse un OR con delle policy particolarmente permissive, sarebbe in grado di accentrare una grande quantità di traffico sul proprio nodo, facilitando le analisi correlative.
In ultimo, ancora più grave, se questo avversario fosse in grado di controllare 'm' OR (su di un totale di 'N', magari degradando l'affidabilità dei restanti 'N-m'), esso avrebbe la capacità di correlare (m/N)^2 del traffico della rete TOR.
Directory Server: Un altro grande problema di sicurezza riguarda i Directory Server. I Directory Server hanno infatti la responsabilità di garantire la “fidatezza” degli OR. Attualmente quasi 800 nodi (OR) fanno capo a tre soli Directory Server (è previsto che la rete scali fino ad un massimo di nove): uno gestito da noreply.org e due gestiti dal MIT (i due gestiti dal MIT hanno quindi “la maggioranza”).
Un avversario che prendesse possesso di uno solo dei tre directory server sarebbe in grado di influenzare l'output finale.
Un avversario che prendesse possesso della maggioranza dei Directory Server (in questo caso due) avrebbe il controllo totale della rete in quanto avrebbe il potere di includere (tramite la votazione a maggioranza) nella directory finale solamente i propri OR, escludendo gli altri.
Essendo, infine i Directory Server molto pochi (in questo momento solo 3) essi sono particolarmente suscettibili ad attacchi di ogni genere.

3.4 FREENET
FreeNet [10] è un protocollo per lo scambio di informazioni realizzato su un'implementazione del sistema descritto da Clarke nel 99. Il protocollo crea una rete peer-to-peer decentralizzata, che è possibile utilizzare per servizi simili al web e alle BBS, sfruttando le risorse (banda passante, spazio su disco) dei suoi utenti per permettere la pubblicazione e la fruizione di qualsiasi tipo di informazione, garantendo allo stesso tempo sia anonimia in avanti sia anonimia all’indietro.
Per la sua stessa natura, FreeNet è da sempre al centro di critiche, discussioni e accuse. La maggior parte di queste contestano il fatto che la stessa tecnologia usata per lo scambio anonimo d’informazioni, potrebbe anche usata per pubblicare materiale non accettabile (es. materiali pedopornografico, inneggiamenti terroristici, ecc) che può essere visionato da chiunque partecipi al protocollo, senza che le autorità possano sapere chi lo ha inserito o chi lo ha scaricato.
In ogni caso FreeNet è stata progettata per resistere alle deformazioni: i contenuti che non vengono letti per un lungo periodo, scadono e scompaiono.
FreeNet è progettata per garantire anonimato e sicurezza, ma non a grosse velocità di trasmissione (alta latenza). Questa caratteristica la rende poco indicata per lo scambio di file di grosse dimensioni, come ad esempio file multimediali di ultima generazione.
FreeNet è sviluppata su software libero distribuito con GNU General Public License; essendo scritto in Java può funzionare su Microsoft Windows, GNU/Linux, Mac OS X e su tutti i sistemi operativi dotati di Java Virtual Machine.

3.4.1 Funzionamento
La rete di file sharing di FreeNet è disegnata per essere resistente; per questo i processi di funzionamento interni lavorano tutti coperti da anonimato e sono decentralizzati su tutta la rete.
Il sistema non ha server centrali e non è soggetta a controlli né da privati né da organizzazioni, ed nemmeno l'ideatore di FreeNet ha alcun tipo di controllo sul sistema (trapdoor).
Per ragioni politiche o legali chi mantiene un nodo su FreeNet potrebbe non voler conoscere i contenuti ospitati suo spazio disco. FreeNet infatti cripta tutti i dati che sono memorizzati localmente e che sono anche replicate su molti diversi nodi in continuo cambiamento in tutto il mondo. Nessuno può effettivamente sapere cosa il nostro nodo sta condividendo ed ha memorizzato nel data store. Solo gli utenti che mediante ricerca e download richiedono di scaricare quei determinati files potranno leggerli ed usufruirne decriptandoli (ovviamente non potranno mai sapere da chi li hanno presi).
È estremamente difficile per un attaccante capire quali nodi rendono disponibile un determinato file e gli stessi tenutari dei nodi non sanno cosa stanno distribuendo. Questo è ciò che assicura che la connessione è anonima sia in avanti che all’indietro.
Lo scopo di FreeNet è immagazzinare documenti e permetterne la lettura attraverso indirizzi univoci (detti anche "chiavi") Globally Unique Identifier (GUID), in modo simile a quanto accade sul web tramite l’indirizzo URL per il protocollo HTTP. La rete è costituita da un gran numero di nodi che si scambiano informazioni: ogni nodo comunica con i limitrofi attraverso il protocollo di FreeNet; non esiste una divisione tra "client" e "server" su FreeNet: tutti i partecipanti agiscono in entrambi i modi, permettendo sia di effettuare richieste di informazioni ad altri nodi sia di inviare documenti in risposta alle richieste altrui.
Ogni nodo mantiene un tabella di instradamento (routing table) che elenca gli indirizzi degli altri nodi e le chiavi GUID che pensa tali nodi possano avere. Quando un nodo riceve una richiesta, analizza per prima cosa il suo spazio disco per vedere se eventualmente trova li il file. Se lo trova allora lo invia indietro al nodo dal quale a ricevuto la richiesta affiancandoci un TAG che lo identifica come possessore di quel file. Altrimenti il nodo invia la richiesta al nodo che nella sua tabella ha la chiave più simile a quella cercata. Se la richiesta ha successo ogni nodo nella catena lascia passare il file indietro verso il destinatario. Inoltre in dipendenza dalla sua distanza dal mittente ogni nodo potrebbe anche conservare sul proprio spazio una copia di quel file.
Per nascondere l'identità del possessore dei dati i nodi occasionalmente alterano i messaggi di risposta, fingendo di essere loro i possessori del file. Con richieste successive si riuscirà di nuovo a trovare i dati perché i nodi conservano la vera identità del possessore del file nella loro tabella di instradamento e quindi si riuscirà a indirizzare la richiesta nella direzione giusta. Le tabelle di instradamento non vengono mai rivelate agli altri nodi.

Supponendo che Alice invia la richiesta per un determinato file ad un nodo (Bob) ma il file richiesto non viene trovato, un messaggio di richiesta fallita viene inviato Alice, così che possa selezionare un altro nodo (Charly) a cui inviare il messaggio in base alla chiave più simile a quella richiesta successiva nella sua tabella di instradamento. Se un nodo esaurisce tutti i candidati nella tabella a cui chiedere restituisce un messaggio di fallimento al nodo precedente nella catena, che quindi prova con la sua seconda possibilità nella tabella di instradamento.e così via.

 

In figura è rappresentata una tipica sequenza di ricerca. L'utente avvia la ricerca al nodo A e la spedisce a B, che la spedisce a C. Il nodo C non è capace di contattare altri nodi e risponde a B con un messaggio 'richiesta fallita' . Il nodo B allora prova con la sua seconda scelta, E, che invia il messaggio al nodo F. il nodo F a sua volta invia il messaggio a B che rileva un loop ( ovvero arrivo di un messaggio di richiesta ad un nodo dal quale quel messaggio è già passato ) e rispedisce il messaggio dietro. Incapace di contattare altri nodi, il nodo F rispedisce ancora indietro il messaggio ad E, che spedisce il messaggio di richiesta alla sua seconda scelta nella tabella di instradamento, D. D trova il file sul suo hard disk. A questo punto D invia il file dietro attraverso E quindi B fino a farlo giungere al nodo A dal quale era partita la richiesta. Lungo il percorso E,B ed A possono anche conservare una copia nel proprio spazio disco di questo file.
 

Tecnologia
FreeNet usa due tipi di chiavi TLS: le Content Hash Key (CHK) e le Signed Subspace Key (SSK).
CHK - E' la chiave che viene usata per la memorizzazione dei dati a basso livello e viene generata calcolando un codice hash SHA-1 in base ai contenuti dei file. Questo processo fornisce ad ogni file un identificatore assolutamente unico (collisioni SHA-1 vengono considerate quasi impossibili) che può essere verificato molto velocemente. I CHK fanno si che differenti copie dello stesso file inserite da persone diverse sulla rete vengano automaticamente unite perché ogni utente calcolerà la stessa chiave CHK per quel file.
SSK - Crea uno spazio per il nome del file che tutti possono leggere ma che solo il proprietario originario di quel file ( ovvero che lo ha immesso sulla rete per la prima volta ) può modificare. Supponendo che un utente voglia dare un nome ad un file, FreeNet creerà prima una coppia di chiavi pubblica-privata attraverso l’algoritmo Digital Signature Algorithm (DSA) ed la chiave privata sarà data al possessore del file. A questo punto per inserire il file sulla rete occorrerà assegnargli un testo descrittivo ovvero un nome. Quindi verrà creata la chiave SSK estrapolandola con un algoritmo di hash dalla metà chiave pubblica e dal nome che si è scelto di dare al file, poi concatenando queste le due stringhe si genera un nuovo hash. Firmare il file con la chiave privata consente di verificare l'integrità del file poiché ogni client che viene in possesso della SSK può verificarne la firma prima di accettare il download.
Per scaricare un file quindi occorre avere la chiave pubblica e la stringa descrittiva attribuita al file (nome). Con queste due informazioni è possibile ricreare la chiave SSK.
Per aggiornare un file invece occorre anche la chiave privata per generare una firma valida. Questo assicura che solo il proprietario di quel file potrà modificarlo successivamente al rilascio sulla rete.
Solitamente le chiavi SSK vengono utilizzate per memorizzare file indiretti che contengono puntatori a chiavi CHK (che identificano fisicamente il file sulla rete) piuttosto che per memorizzare direttamente file di dati.
I File indiretti combinano la facilità di consultazione di cui necessita l'uomo attraverso il nome file, con la veloce verifica dell'integrità dei contenuti dei file resa possibile dalla chiave CHK.
Consentono inoltre di aggiornare i dati conservando l'identità referenziale su FreeNet.
Per eseguire un aggiornamento il proprietario di quel file ne inserisce prima una nuova versione a cui verrà attribuito un nuovo CHK proprio perché il nuovo file è fisicamente diverso dal vecchio. Quindi aggiorna l'SSK in modo da farlo puntare alla nuova versione.
I file indiretti possono anche essere usati per dividere i file grandi in tante parti più piccole attribuendo ad ogni parte un CHK diverso, quindi creando un file indiretto che punta a tutte le parti.

 

RIFERIMENTI

[1] RFC: 793 TRANSMISSION CONTROL PROTOCOL
http://www.faqs.org/rfcs/rfc793.html

[2] RFC: 791 INTERNET PROTOCOL
http://www.faqs.org/rfcs/rfc791.html

[3] RFC 2068 - HYPERTEXT TRANSFER PROTOCOL - HTTP/1.1
http://www.faqs.org/rfcs/rfc2068.html

[4] RFC 2965 - HTTP STATE MANAGEMENT MECHANISM
http://www.faqs.org/rfcs/rfc2965.html

[5] TECNOLOGIE PER LA COMUNIVAZIONE RISERVATA ED ANONIMA IN RETE - Ass.Prof. GIANNI BIANCHINI
http://www.giannibi.net/ld05.pdf

[6] RFC 1919 - CLASSICAL VERSUS TRANSPARENT IP PROXIES
http://www.faqs.org/rfcs/rfc1919.html

[7] ANONIMIA - Prof. ALFREDO DE SANTIS
http://www.dia.unisa.it/~ads/corso-security/www/CORSO-9900/anonimia

[8] TOR: THE SECOND GENERATION ONION ROUTER- R. DINGLEDINE, N. MATHEWSON, P. SYVERSON,
http://tor.eff.org/tor-design.pdf

[9] UNTRACEABLE ELECTRONIC MAIL, RETURN ADDRESSES, AND DIGITAL PSEUDONYMS - Prof. DAVID L. CHAUM
http://gnunet.org/papers/p84-chaum.pdf

[10] FREENET: A DISTRIBUTED ANONYMOUS INFORMATION STORAGE AND RETRIEVAL SYSTEM - IAN CLARKE
http://www.cl.cam.ac.uk/~twh25/academic/papers/icsi-revised.pdf

[11] THE SECURE HYPERTEXT TRANSFER PROTOCOL
http://www.rfc-editor.org/rfc/rfc2660.txt