quello che mi piace di tor sono i "differenti livelli di partecipazione".
vuoi essere il client ignorante ? lo puoi essere.
vuoi essere un nodo di middle ? lo puoi essere.
vuoi essere il nodo d'uscita ? lo puoi ...
ognuno di questi punti richiede all'utente un diverso livello di
consapevolezza, risorse, voglia e competenze.
la soluzione che sogno non e' un modo per "ridare vita alla rete di
remailer", secondo me ha gia' dimostrato i suoi limiti, ma non tanto
livello software/client, quanto risorse necessarie lato server, non
espansione della rete, e il fatto che una rete decentralizzata con una
30-ina di elementi sia stata fatta fuori in un anno -se c'era la reale
neciessita'- (mi affido al caso pratico della rete dei server eDonkey).
pertanto una rete con una 30-ina di elementi, fissi (perche' non hanno
un grande ricambio) destinata a diminuire e non a crescere, mi sembra
come forma di rete meno resistente di altre reti anonime, che a questo
punto potrebbero essere usate come appoggio (come trasporto, come base)
per farci transitar sopra email anonime (e svilupparci sopra le feature
di SURB o di nym o quali altre chissa').
putro wrote:
> On Tue, Sep 16, 2008 at 05:16:54PM +0200, vecna wrote:
> volendo si puo' rimettere, sia paranoia che il remailer del flug (mi
> pare) ce l'avevano, noi mi pare si tolse perche' qualcuno aveva trovato il
> modo (nulla di complicato immagino) per accedere a ripetizione
> all'interfaccia per postare molti msg in modo automatico.
e' una POST https, la si puo' fare con curl come base e qualunque genere
di script semplice sopra.
>> seguire i thread, e se fosse possibile mettere una sorta di notifica di
>> uscita dell'email dal circuito anonimo [si, stando attendi a non rendere
>> la notifica una vulnerabilita']).
>
> questo e' difficile, direi impossibile visto che con le catene perdi
> traccia del mittente.
mah, supponendo che il mittente non possa avere un segreto condiviso con
il primo hop, perche' non e' sicuro, sarebbe sufficente (ad esempio) che
ogni remailer postasse in un grosso storage pubblico, l'hash del proprio
messaggio inoltrato. solo il mittente sa riconosce l'hash della sua
chain, e l'uso di storage condivisi si basa sullo stesso principio dei
messaggi anonimi su newsgroup (scarico tutto il newsgroup e provo a
decifrare la roba finche' qualcosa non si decifra per me).
per questi fini, servizi come nopaste, rafb, mailinator sono
interessanti, insicuri, ma servizi ai quali ci si puo' gia' appoggiare.
poi il meccanismo crittogrfico e' da pensare.
premetto pero' che non voglio mettermi a disegnare protocolli :)
> tutto sommato il numero dei remailer e' sufficiente, certo la
> difficolta' di utilizzo non favorisce l'espansione dell'uso.
a me inquieta l'uso delle risorse. e vorrei porvi questa riflessione.
il fatto che i computer possano collegarsi direttamente rappresenta il
successo o il fallimento di internet come rete distribuita. ( = tutti si
collegano a chi vogliono, tutti hanno lo stesso valore). se i client
cessano di potersi collegare reciprocamente interner prende una forma
decentralizzata (= domini intestati a persone, certificati SSL firmati
da autorita', e gli aspetti di controllo aumentano). decentralizzazione
implica o business o volontariato (o gmail o autistici) distribuzione
implica liberta' e software che ti fa fare cose, ma in piu' le fa fare
anche altri altri.
questo come generalismo tecnico, ma piu' o meno gli elementi in gioco
sono questi.
il NAT e' la forma tecnologica che blocca la connessione tra client, le
tecniche di nat bypass sono quelle che le consentono comunque, hanno
un'interessante storia e il meglio della loro tecnologia e'
rappresentata da ICE
(
http://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment).
quindi, supponendo il futuro dark in cui far girare software d'anonimato
sara' vietato (ma sara' imponibile solo ai server per la loro
staticita') i server avranno il ruolo di far svolgere il nat bypass ai
client che sotto faranno girare client d'anonimato (o di file sharing, o
di quello che gli pare).
pertanto, il fatto che un server tor per girare richieda un ip pubblico,
il fatto che un nodo emule per avere priorita' maggiore richieda un ip
pubblico, sono segni che i server con ip pubblico hanno una possibiita'
necessaria alla proliferazione della rete.
immaginiamo questo: 10 client dietro nat (rete aziendale) e 1 server
tor. 10 client = 1/10 di banda per ogni client. se invece il server
offre un servizio di nat bypass con priorita' maggiore del routing tor,
i 10 client hanno tutte le loro bande da usare indipendentemente.
e' lo stesso discorso che si sono fatti quelli di emule e bittorrent
quando hanno deciso a chi dare priorita'. non e' stato usato il nat
bypass, quindi ha priorita' nel download chi ha ip pubblico cosi' che
gli ip privati possano scaricarlo da lui anziche' dalla sorgente unica.
> la latenza media e' attorno ai 30 minuti per ogni step, c'e' chi sta
> sui 10 minuti e chi si avvicina all'ora, mi pare cmq il problema
> meno importante.
a me pare che se posso navigare a latenza 0 anonimo, anche mandare email
deve avere la stessa latenza. se no mi apro un account usa e getta su
gmail tramite tor :P
>> 5) prima vedevo varie liste da echolot, ora solo:
>> http://pboxmix.winstonsmith.info/echolot/clist.html, e il fatto che una
>> rete decentralizzata anonima, per essere accessibile, debba affidarsi al
>> web e' un punto debole (thepiratebay cosa ci ha insegnato ? :)
>
> ?? quasi tutti i remailer hanno un pinger associato
> http://www.noreply.org/allpingers/
non lo sapevo :) pensavo ce ne fossero pochi di riferimento.
> vero :)
> mixminion e' ancora acerbo, e temo che sara' cosi' per molto.
TOR e' una rete di trasporto e pure freenet.
mixminion|mixmaster sono applicazioni.
e' lo stesso rapporto che c'e' tra web e TCP... meglio avere una
connessione tcp da dirigere come voglio e dove voglio, piuttosto che un
applicativo solo (per quanto sicuro sia).
pertanto, ora che tor mostra la sua dimensione e le sue possibilita',
c'e' da trovare un modo nuovo perche' le email si anonimizzino e escano
da TOR senza passare per essere spam.
vabe', c'e' da riflettere, secondo me pero' se vogliamo discutere
soluzioni devono essere sviluppate guardando *un po' piu'* avanti.
gli AR resistno perche' chi li ha sviluppati si e' fatto trip
allucinante sulle possibilita' degli attaccanti (anche se di fatto non
esiste un attaccante con quelle possibilita').
10 anni fa il problema non erano: le leggi, gli ISP, i brevetti, il NAT,
la DPI, la profilazione... ma era l'idea di echelon. cambia il modello
di minaccia ? cambia la soluzione.
ciao ciao,
vecna
