it/volunteer.wml (3a9733aeb) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 8183
# Last-Translator: jan@seul.org

#include "head.wmi" TITLE="Partecipa"

<h2>Quattro cose che puoi fare subito:</h2>
<ol>
<li>Puoi <a href="<page docs/tor-doc-server>">realizzare
un server</a> per aiutare a far crescere la rete Tor.</li>
<li>Dai un'occhiata alla <a href="<page gui/index>">Tor GUI Competition</a>, e
aiutaci a migliorare l'interfaccia
e l'usabilit&agrave; di Tor. Una T-shirt Tor gratis per ogni proposta!</li>
<li>Parla coi tuoi amici! Fagli realizzare un server. Fagli aprire degli hidden
services. Falli parlare di Tor coi loro amici.</li>
<li>Cerchiamo finanziamenti e sponsor. Se ne apprezzi gli obiettivi, per favore
  <a href="<page donate>">fai una donazione per sostenere
lo sviluppo di Tor</a>. Se conosci qualche azienda, ente o
associazione che ha bisogno di sicurezza nelle
comunicazioni, fagli conoscere il progetto Tor.</li>
</ol>

<a id="Bugs"></a>
<h2><a class="anchor" href="#Bugs">Bachi</a></h2>
<ol>
<li>Attualmente i server Tor su Windows XP non sono stabili,
perch&eacute; usiamo centinaia di socket che il
kernel di Windows non &eacute; in grado di gestire. <a
href="http://wiki.noreply.org/noreply/TheOnionRouter/WindowsBufferProblems">Aiutaci
a risolvere questo problema!</a> Probabilmente la soluzione migliore &egrave; fare in modo che libevent
usi un IO overlapped invece di libevent() in Windows, e poi adattare Tor
in modo che usi la nuova interfaccia libevent.</li>
</ol>

<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">Applicazioni di supporto</a></h2>
<ol>
<li>Serve un buon sistema per intercetare le richieste DNS in modo che non siano svelate
a un osservatore locale mentre cerchiamo di essere anonimi. (Ci&ograve;
succede se l'applicazione segue la risoluzione DNS prima di rivolgersi
al proxy SOCKS.)</li>
<ul>
<li>C'&egrave; bisogno di <a
+href="http://wiki.noreply.org/noreply/TheOnionRouter/TSocksPatches">applicare
tutte le nostre patch a tsocks</a> e mantenerne un nuovo fork. Lo possiamo ospitare sul
nostro server se vuoi.</li>
<li>Bisognerebbe applicate le patch al programma "dsocks" di Dug Song in modo che usi
i comandi <i>mapaddress</i> di Tor dall'interfaccia di controllo, cos&igrave;
da non sprecare un intero ciclo in Tor per fare la risoluzione prima di
connettersi.</li>
<li>Dobbiamo fare in modo che il nostro script <i>torify</i> distingua se siano installati tsocks o
dsocks, e li chiami di conseguenza. Ci&ograve; significa probabilemnte
unificarne le interfacce e potrebbe essere necessario condividere del codice tra di essi
o scartarne uno direttamente.</li>
</ul>
<li>Chi gestisce un server ci dice spesso che vorrebbe avere un certo BandwidthRate
in certe ore del giorno e un diverso BandwidthRate in altre.
Invece di programmare questa funzione in Tor, si potrebbe fare un piccolo
script che dialoghi con la <a href="<page gui/index>">Tor Controller Interface</a>,
e faccia un setconf per cambiare la banda disponibile. Potrebbe girare con
cron, o magari attivarsi solo al momento giusto per fare
la sua configurazione (probabilmente cos&igrave; &egrave; pi&ugrave; portabile). Qualcuno pu&ograve; scrivercelo
cos&igrave; lo mettiamo in <a href="<svnsandbox>contrib/">contrib/</a>?
Questa &egrave; una buona prova per il <a href="<page gui/index>">concorso per una GUI
Tor</a>.</li>
<li>Tor &ograve; <a
href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit">uscire dalla
rete Tor network da un particolare exit node</a>, ma dovremmo riuscire a
specificare solo una certa nazione e  fare scegliere l'exit node automaticamente. La
cosa migliore sembra prendere la directory Blossom e usare un client Blossom
locale che recuperi la directory in modo sicuro (via Tor e verificandone la
firma), intercetti i <tt>.country.blossom</tt> hostname, e faccia
la cosa giusta.</li>
<li>A proposito di geolocalizzazione, qualcuno potrebbe disegnare un mappamondo
indicante tutti i server Tor. Un premio se si aggiorna man mano che
la rete cresce e cambia. Purtroppo la maniera pi&ugrave; semplice per farlo implica
inviare tutti i dati a Google che disegni la mappa per te. Che
conseguenze ha per la privacy? Ci sono altre buone soluzioni?</li>

</ol>

<a id="Documentation"></a>
<h2><a class="anchor" href="#Documentation">Documentazione</a></h2>
<ol>
<li>Sappiamo che l'anonimato degli utenti Tor pu&ograve; essere attaccato da
javascript, java, activex, flash, etc, se non vengono disabilitati.
Ci sono dei plugin (come NoScript per Firefox) che possono aiutare
gli utenti a gestire questo rischio? E di che rischio si tratta esattamente?</li>
<li>Esiste una suite completa di plugin che sostituisca tutte le funzioni di Privoxy
per Firefox 1.5+? Sappiamo che Tor &egrave; molto pi&ugrave; veloce senza
Privoxy.</li>
<li>Aiuta Matt Edman con la documentazione e con le guide del suo
<a href="http://vidalia-project.net/">Tor Controller</a>.</li>
<li>Analizzare e documentare
<a href="http://wiki.noreply.org/wiki/TheOnionRouter/TorifyHOWTO">la
nostra lista di programmi</a> configurabili per essere usati con Tor.</li>
<li>Abbiamo bisogno di una documentazione migliore per intercettare dinamicamente
le connessioni e inviarle via Tor. tsocks (Linux), dsocks (BSD),
e freecap (Windows) sembrano dei buoni candidati.</li>
<li>C'&egrave; una lista immensa di <a href="http://wiki.noreply.org/noreply/TheOnionRouter/SupportPrograms">programmi potenzialmente
utili che si interfacciano con Tor</a>. In quali situazioni sono utili?
Aiutaci a testarli e a documentare i risultati.</li>
<li>Aiuta a tradurre le pagine web e la documentazione in altre
lingue. Vedi le <a href="<page translation>">linee guida per
tradurre</a> se vuoi dare una mano. Servono anche persone che aiutino
a mantenere le traduzioni esistenti in italiano, francese e svedese -
vedi lo <a href="<page translation-status>">stato delle
traduzioni</a>.</li>

</ol>

<a id="Coding"></a>
<h2><a class="anchor" href="#Coding">Programmazione e design</a></h2>
<ol>
<li>Per ora i descrittori dei hidden service sono contenuti in solo in
pochi directory server. &#200; uno svantaggio per la privacy e per la robustezza. Per
una maggiore robustezza dovremo rendere ancora meno privati i descrittori dei
hidden service dato che dovremo duplicarli in
molti mirror diversi. Idealmente vorremmo separare del tutto il sistema di storage/lookup dai
directory server Tor. TIl primo problema &egrave; che occorre
disegnare un nuovo formato per i descrittori dei hidden service che a) sia ascii piuttosto che
binario, per praticit&agrave;; b) tenga criptata la lista degli introduction point
a meno di non conoscere l'indirizzo <tt>.onion</tt>, in modo che la directory
non possa conoscerli; e c) permetta alle directory di verificare il timestamp
e la firma su un descrittore di un hidden service in modo che non possano
rivelarne uno falso. In secondo luogo, va bene qualsiasi sistema affidabile
di storage distribuito, fintanto che permetta aggiornamenti automatici, ma per ora
pare che nessun codice DHT implementato supporta gli aggiornamenti automatici.</li>
<li>Gli exit server Tor devono eseguire numerose risoluzioni DNS in parallelo. Purtroppo
gethostbyname() &egrave; mal disegnato --- si blocca finch&eacute; non ha finito
di risolvere una query --- e richiede il proprio thread or processo. Cos&igrave; Tor
deve aprire numerosi thread DNS "di lavoro". Esistono alcune librerie
DNS asincrone, ma sono storicamente bacate e abbandonate.
Qualcuna di queste &egrave; anche software stabile, pulito e libero? (Ricorda che
Tor usa OpenSSL e che OpenSSL probabilmente non &egrave; compatibile con la GPL, perci&ograve;
le librerie GPL sono escluse.) Se fosse cos&igrave;
(o se potessimo renderle tali), le integreremmo in Tor. vedi <a
href="http://archives.seul.org/or/talk/Sep-2005/msg00001.html">il post di Agl
</a> per uno degli approcci possibili. Vedi anche
<a href="http://daniel.haxx.se/projects/c-ares/">c-ares</a> e
<a href="http://www.monkey.org/~provos/libdnsres/">libdnsres</a>.
</li>
<li>Tor 0.1.1.x include il supporto per acceleratori crittografici hardware
tramite OpenSSL. Nessuno tuttavia lo ha ancora testato. C'&egrave; qualcuno che vuole
prendere una scheda e farci sapere come va?</li>
<li>Dato che i server Tor fanno store-and-forward di ogni cellula che gestiscono,
i server Tor a larga banda finiscono ad usare dozzine di megabyte di memoria
solo per i buffer. Dobbiamo sapere quando restringere o espandere
i buffer. Forse si potrebbe modellare una soluzione come i buffer nel kernel
Linux, dove ci sono buffer pi&ugrave; piccoli che si collegano l'un l'altro,
invece che dei buffer monolitici?</li>
<li>Implementare richieste di reverse DNS dentro Tor (gi&agrave; specificato nella
sezione 5.4 delle <a href="<svnsandbox>doc/tor-spec.txt">tor-spec.txt</a>).</li>
<li>Effettuare una analisi di sicurezza di Tor con <a
href="http://en.wikipedia.org/wiki/Fuzz_testing">"fuzz"</a>. Determinare
se esistono delle buone librerie di fuzzing adatte al nostro scopo. Guadagnati la fama
e il credito quando potremo fare una nuova release grazie a te!</li>
<li>Sarebbe difficile fare una patch per bind o per
un DNS proxy per redirigere le richieste a Tor tramite la nostra <a
+href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#CompatibleApplications">estensione socks
tor-resolve</a>? dsocks lo permette gi&agrave; su BSD. E si potrebbe
convertire le richieste DNS UDP in richieste TCP da inviare via Tor?</li>
<li>Tor usa TCP per il trasporto e TLS per la cifratura del
collegamento. Funziona ed &egrave; semplice, ma significa che se un pacchetto
viene scartato tutte le cellule di un collegamento subiscono un ritardo; inoltre
significa che possiamo ragionrvolmente supportare solo flussi TCP. Abbiamo una <a
href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#TransportIPnotTCP">lista
di motivi per evitare il trasporto UDP</a>, ma sarebbe bello accorciare
questa lista. Abbiamo proposto anche delle <a
href="<svnsandbox>doc/tor-spec-udp.txt">specifiche per Tor e
UDP</a> &mdash; facci sapere se presentano dei problemi.</li>
</li>
<li>Non ci manca molto per avere supporto IPv6 per indirizzi destinazione
(sugli exit node). Se per te IPv6 &egrave; molto importante, questo &egrave;
il punto da cui cominciare.</li>
</ol>

<a id="Research"></a>
<h2><a class="anchor" href="#Research">Ricerca</a></h2>
<ol>
<li>Attacco di tipo "website fingerprinting": fai un elenco di quanche
centinaio di siti famosi, scaricane le pagine, crea una serie di
"signature" per ciascun sito. Poi osserva il traffico di un client Tor. Mentre
riceve dati, potresti indovinare se e quale di questi siti
il client sta visitando. Per prima cosa, che possibilit&agrave; di successo
ha questo attacco sull'installato Tor attuale? Poi, cerca delle difese
possibili: ad esempio, potremmo cambiare le dimensioni delle cellule Tor da 512
byte a 1024 byte, potremmo usare tecniche di padding come <a
href="http://freehaven.net/anonbib/#timing-fc2004">il defensive dropping</a>,
o potremmo aggiungere ritardi nel traffico. Che impatto avrebbe,
che conseguenze avrebbe sull'usabilit&agrave; (con un metro di riferimento adeguato)
l'uso di difese efficaci in ciascuno di questi casi?</li>
<li>Attacco di tipo "end-to-end traffic confirmation":
osservando il traffico dal lato di Alice e di Bob, si possono <a
href="http://freehaven.net/anonbib/#danezis:pet2004">confrontare
le signature del traffico e dedurre che si sta osservando lo stesso
flusso</a>. Finora Tor si rassegna ad accettare questa situazione, assumendo
che in ogni caso questo attacco &egrave; triviale. Ma &egrave; davvero cos&igrave;? Quanto
 e quale traffico &egrave; necessario perch&eacute; un aversario
sia certo di aver vinto? Ci sono situazioni che rallentano l'attacco (es. trasmissioni modeste)?
Il traffic padding o il traffic shaping
funzionano meglio di altri sistemi?</li>
<li>Attacco di tipo "routing zones": gli studi attuali considerano
il percorso di rete tra Alice e il suo entry node (e tra
l'exit node e Bob) come un singolo collegamento in un grafico. In realt&agrave;
invece il percorso attraversa diversi autonomous system (AS), e <a
href="http://freehaven.net/anonbib/#feamster:wpes2004">non &egrave; infrequente che
lo stesso AS appaia sia nell'entry path che nell'exit path</a>.
Purtroppo, per calcolare se una certa configurazione tra Alice, entry,
exit e Bob sia pericolosa occorre scaricare una intera
routing zone Internet ed effettuare su di essa molte operazioni. Ci sono dei
rimedi pratici approssimativi, come ad esempio evitare gli indirizzi IP nella stessa rete /8?</li>
<li>Tor funziona male quando un server dispone di banda asimmetrica
(come via cavo o DSL). Siccome Tor usa connessioni TCP separate per
ogni nodo, se i bye in arrivo giungono regolarmente e quelli in uscita
vengono tutti persi, il meccanismo di push-back del TCP non
ritrasmette questa informazione ai flussi in entrata.
Tor potrebbe rilevare se sta perdendo molti pacchetti in uscita ed eseguire
un rate-limit sui flussi in ingresso per autoregolarsi? Ho in mente
un sistema di accumulo e scarico in cui si sceglie un rate-limit prudente e
lo si incrementa lentamente finch&eacute; non si perdono pacchetti, poi si decrementa etc.
Ci serve qualcuno esperto di reti per simulare il meccanismo e aiutarci a disegnare
una soluzione; oppure dovremmo capire quanto ne vengono degradate le
prestazioni, e decidere se riconsiderare il trasporto UDP.</li>
<li>Un argomento simile &egrave; il controllo delle congestioni. Il nostro sistema attuale
sar&agrave; sufficiente quando avremo un uso molto intenso?
Potremmo sperimentare finestre di ampiezza variabile, invece
di finestre di ampiezza fissa? Questo sembrava funzionare bene in un <a
href="http://www.psc.edu/networking/projects/hpn-ssh/theory.php">esperimento
di throughput ssh</a>. Dovremmo misurare e provare, e forse applicare il metodo
se i risultati fossero soddisfacenti.</li>
<li>Per permettere ai dissidenti in tutto il mondo di usare Tor senza essere
bloccati dai firewall del loro paese, serve un sistema per avere decine di migliaia
di relay, non qualche centinaio. Potremmo immaginare la GUI di un client Tor con
un pulsante "help China" che apre una porta e fa il relay di pochi
KB/s di traffico verso la rete Tor. (Pochi KB/s non dovrebbero essere un problema,
e ci sarebbero pochi abusi, dato che non sarebbero degli exit
node.) Ma come si fa a distribuire automaticamente ai dissidenti
la lista di questi client volontari ed ad impedire ai firewall nazionali di
intercettarli ed enumerarli? Forse si dovrebbe lavorare a livello di
fiducia personale. Vedi la nostra <a
href="http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#China">FAQ
</a> sull'argomento e poi leggi la <a
href="http://freehaven.net/anonbib/topic.html#Communications_20Censorship">sezione
di anonbib sulla resistenza alla censura</a>.</li>
<li>I circuiti Tor si stabiliscono un nodo alla volta, per cui potremmo
fare uscire alcuni flussi dal secondo nodo, altri dal terzo e cos&igrave; via.
Sembra una buona idea, dato che riduce i flussi in uscita
che ciascun server pu&ograve; vedere. Se per&ograve; vogliamo assicurare la sicurezza di ciascun flusso,
il percorso pi&ugrave; breve dovrebbe essere almeno di tre nodi, secondo i criteri correnti, e
gli altri dovrebbero essere anche pi&ugrave; lunghi. Dobbiamo valutare questo compromesso tra
sicurezza e prestazioni.</li>
<li>Non &egrave; difficile effettuare un DoS ai Tor server o ai dirserver. I client
puzzle sono la soluzione giusta? Quali altri approcci pratici esistono? Un premio
se sono compatibili col protocollo Tor attuale.</li>
</ol>

<a href="<page contact>">Facci sapere</a> se hai fatto progressi in qualcuno di
questi campi!

</div>

#include <foot.wmi>

tor-webwml.git

r9602@danube: weasel | 2006-08-29 01:18:28 +0200 Move based-on-revision numbers to svn