[e-privacy] Documento su tor pubblicato sul blog makeinstall.it

[Marco A. Calamari]

On Mon, 2007-01-01 at 18:49 +0100, nobody at mixminion.paranoici.org wrote:
> -----BEGIN TYPE III ANONYMOUS MESSAGE-----

....

> >
> > E' un software a sorgente aperto, che chiunque puo' esaminare,
> > modificare, riscrivere, migliorare o forkare a piacimento.
> >
> 
> in effetti questo è un punto che andrebbe approfondito.. è vero che è software libero per cui virtualmente esistono quelle libertà , però:
> 
> - - il software libero -tra le varie cose- permette di fare ispezione del codice, testing, debugging, verifica formale dei protocolli; tuttavia queste metodologie non proteggono da scelte di design deliberatamente tendenziose...
> 
> - - al dilà che la scelta di accentrare tutto entro pochi directory server controllati dagli autori/finanziatori del progetto sia volutamente tendeziosa o meno (domanda: esistono altre soluzioni che sono state scartate? se si, perché?), tale scelta ha comunque delle considerevoli implicazioni a livello di sicurezza e fidatezza -accentrare il controllo dell'intera rete entro pochi nodi, controllati da poche persone-;
> 
> - - vista la stuola di finanziatori governativi che ci stanno dietro (vedi sopra) ho la sensazione che non sia così facile far includere delle modifiche sostanziali, soprattutto a livello di design, nel tree ufficiale;
> 
> - - per quanto riguarda il forking c'è un passaggio nel documento di design che allontana questa possibilità , definendola sostanzialmente un attacco ai directory server:"Encourage directory server dissent. The directory agreement protocol assumes that directory server operators agree on the set of directory servers. An adversary who can persuade some of the directory server operators to distrust one another could split the quorum into mutually hostile camps, thus partitioning users based on which directory they use. Tor does not address this attack." Ovvero se qualcuno eseguisse un fork allo scopo di prendere il controllo dei directory server, questo sarebbe considerato un attacco alla rete TOR in quanto partizionerebbe l'utenza in base ai directory server utilizzati. Ciò sarebbe un problema per entrambe le reti (sia quella forkata che quella originale) in quanto TOR non può difendersi da questo tipo di attacchi. Quindi, a meno di un radicale cambiamento di design che eli
>  mini la necessità dei Directory Server, il sistema attuale è stato progettato in modo per cui sostanzialmente un fork non solo è altamente scoraggiato, ma è persino ritenuto un attacco, tale da rappresentare un un problema di sicurezza per entrambe le parti..
> 
> - -anche nel caso che non ci si fidi dell'amministrazione attuale dei directory server e si voglia fare un fork o una rete parallela, il problema dell'accentramento del controllo della rete TOR si ripresenterebbe puntuale
> 

Fare il fork significa sviluppare una applicazione diversa e modificata,
non clonare o suddividere la rete tor esistente.

Nessuno lo puo' impedire con una licenza libera e se una scelta di 
 progetto e' sub ottimale, arbitraria o tendenziosa basta
 modificarla e riscrivere il codice interessato.
Certo questo richiede lavoro ....

...

> o sistema adottato fin tanto che qualcosa di nuovo non verrà inventato: nella sezione 9, infatti, non c'è in realtà nessun approfondimento, ma solo domande aperte.
> 
> Ricapitolando: 
> - - TOR è software libero, tutt'ora finanziato dai militari+EFF (per un anno);
> - - nonostante sia software libero, per deliberate scelte di design il forking anche solo della rete sarebbe un attacco alla rete stessa;
> - - chi controlla tanti OR può correlare il traffico;
> - - chi controlla i directory server, controlla l'inserimento degli OR;
> - - chi controlla la creazione di directory server controlla la rete; 
> - - è quindi necessario che gli OR siano fidati;
> - - a garanzia di questo ci sono i directory server;
> - - è quindi necessario che i directory server siano fidati;
> - - a garanzia di questo ci sono gli autori/finanziatori;
> - - è quindi necessario che gli autori siano/finanziatori siano fidati
> - - essendo il forkin di difficile realizzazione il controllo continuerà a lungo a rimanere nelle stesse mani;
> - - è quindi doppiamente necessario che gli autori/finanziatori siano fidati
> 
> Insomma, secondo voi, è o non è l'accentramento del controllo dell'intera rete TOR nelle mani di pochi un problema di sicurezza?
> Io penso di si, a prescindere da chi ha il controllo oggi o chi l'avrà domani. Figuriamoci poi la gioia nel rendermi conto che chi controlla oggi sono in gran parte enti governativi americani e che a meno di radicali cambiamenti continueranno fisiologicamente ad esserlo...
> Se a questo ci aggiungiamo le più o meno legittime considerazioni sugli interessi che entità governative americane possano avere nel diffondere un software che permetterebbe ai loro nemici di nascondergli informazioni.. avete capito il mio punto di vista.

Per sintetizzare quindi; se Tor fosse un progetto rogue,
 compromesso fin dall'inizio per essere un'arma dell'esercito
 americano e del Grande Fratello, allora sarebbe meglio non usarlo.

Lapalissiano ! Difficile non dirsi d'accordo. Ma e' credibile ?

Resto tutt'ora dell'opinione che le considerazioni esposte siano
 paranoia mal diretta, non distinguibile da un FUD deliberato.
L'assenza di qualunque proposta od idea costruttiva e' una delle
 caratteristiche piu' salienti di questo tipo di comunicazione.

Un saluto.     Marco Calamari
 
-- 

+--------------- http://www.winstonsmith.info ---------------+
| il Progetto Winston Smith: scolleghiamo il Grande Fratello |
| the Winston Smith Project: unplug the Big Brother          |
| Marco A. Calamari marcoc at marcoc.it  http://www.marcoc.it   |
| DSS/DH:  8F3E 5BAE 906F B416 9242 1C10 8661 24A9 BFCE 822B |
+ PGP RSA: ED84 3839 6C4D 3FFE 389F 209E 3128 5698 ----------+

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part
URL: <http://lists.winstonsmith.org/pipermail/e-privacy/attachments/20070102/3e09a4ba/attachment.pgp>