it/volunteer.wml (e9bf86850) - tor-webwml.git

volunteer.wml

## translation metadata
# Based-On-Revision: 18815
# Last-Translator: jan at seul dot org

#include "head.wmi" TITLE="Tor: partecipa" CHARSET="UTF-8"

<h2>Alcune cose che puoi fare subito:</h2>
<ol>
<li>Puoi <a href="<page docs/tor-doc-relay>">realizzare
un relay</a> per aiutare a far crescere la rete Tor.</li>
<li>Parla coi tuoi amici! Fagli realizzare un relay. Fagli aprire degli hidden
services. Falli parlare di Tor coi loro amici.</li>
<li>Se condividi gli obiettivi di Tor, per favore <a href="<page donate>">fai una donazione
e sostieni lo sviluppo futuro di Tor</a>. Cerchiamo anche
pi&ugrave; sponsor &mdash; se conosci aziende, ONG, enti od
altre organizzazioni interessate ad anonimato / privacy / sicurezza delle
comunicazioni, fagli conoscere il nostro progetto.</li>
<li>Cerchiamo altri <a href="<page torusers>">buoni esempi sull'uso di Tor
e sui suoi utenti</a>. Se usi Tor in una situazione o per scopi non ancora
descritti su questa pagina e se sei disposto a condividere queste informazioni con noi, ci
piacerebbe sentire la tua storia.</li>
</ol>

<a id="Usability"></a>
<h2><a class="anchor" href="#Usability">Applicazioni di supporto</a></h2>
<ol>
<li>Servono dei migliori e nuovi metodi per intercettare le richieste DNS in modo che non siano svelate
a un osservatore locale mentre cerchiamo di essere anonimi. (Ci&ograve;
succede se l'applicazione esegue la risoluzione DNS prima di rivolgersi
al proxy SOCKS.)</li>
<li>Tsocks/dsocks:
<ul>
<li>C'&egrave; bisogno di <a
href="https://wiki.torproject.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 mapaddress 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 torify 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>
<li>Chi gestisce un relay spesso vuole avere un BandwidthRate
durante parte della giornata, e un altro BandwidthRate nell'altra
parte del giorno. Invece di programmarlo dentro Tor, sarebbe bello avere
un piccolo script che parla tramite la <a href="<page gui/index>">Tor
Controller Interface</a> e fa un setconf per modificare la banda disponibile.
Ce n'&egrave; gi&agrave; uno per Unix e Mac (usa bash e cron),
ma gli utenti Windows hanno ancora bisogno di una soluzione.
</li>
<li>A proposito di geolocalizzazione, qualcuno potrebbe disegnare un mappamondo
indicante tutti i relay 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>Aiuta Matt Edman con la documentazione e con le guide del suo
Tor controller,
<a href="<page vidalia/index>">Vidalia</a>.</li>
<li>Analizzare e documentare
<a href="https://wiki.torproject.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, come pure un miglior uso
della nosta nuova funzione TransPort.</li>

<li>C'&egrave; una lista immensa di <a href="https://wiki.torproject.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 e migliorare le pagine web e la documentazione in altre
lingue. Vedi le <a href="<page translation>">linee guida per
la traduzione</a> se vuoi dare una mano. Servono in particolare traduzioni in
Arabo e Farsi, per i tanti utenti Tor in aree dove vige la censura.
Serve anche aiuto per correggere e migliorare questa traduzione italiana.</li>
</ol>

<a id="Coding"></a>
<a id="Summer"></a>
<a id="Projects"></a>
<h2><a class="anchor" href="#Projects">Progetti di siluppo software</a></h2>

Ecco una lista di idee proposte per il <a href="<page gsoc>">Google Summer of Code 2009</a>
Anche alcuna delle <a href="<svnsandbox>doc/spec/proposals/">proposte correnti</a> 
potrebbe aver bisogno di sviluppatori. Se pensi di potere dare una mano, <a href="<page contact>"> dillo!</a> 


(NdT: Le schede di alcuni progetti sono in inglese e verranno tradotte man mano.)

<ol>

<li>
Help track the overall Tor Network status
 
It would be great to set up an automated system for tracking network
health over time, graphing it, etc. Part of this project would involve
inventing better metrics for assessing network health and growth. Is the
average uptime of the network increasing? How many relays are qualifying
for Guard status this month compared to last month? What's the turnover
in terms of new relays showing up and relays shutting off? Periodically
people collect brief snapshots, but where it gets really interesting is
when we start tracking data points over time.
 
Data could be collected from the "Tor Node Scanner" item above, from
the server descriptors that each relay publishes, and from other
sources. Results over time could be integrated into one of the <a
href="https://torstatus.blutmagie.de/">Tor Status</a> web pages, or be
kept separate. Speaking of the Tor Status pages, take a look at Roger's
<a href="http://archives.seul.org/or/talk/Jan-2008/msg00300.html">Tor
Status wish list</a>.
</li>

<!-- Is this still a useful project? If so, move it to another section.
<li>
Una migliore gestione dei pacchetti Debian/Ubuntu per Tor e Vidalia
 
Vidalia al momento non funziona bene su Debian e Ubuntu con i pacchetti
standard di Tor. Gli attuali pacchetti Tor fanno partire automaticamente Tor
come demone sotto l'utente debian-tor e (giustamente) senza una
<a href="<svnsandbox>doc/spec/control-spec.txt">ControlPort</a> definita
del file torrc. Di conseguenza, Vidalia cerca di far 
partire il suo processo Tor, dato che non riesce a connettersi a un processo
Tor esistente, col risulato che il processo Tor di Vidalia termina con un messaggio di errore
che l'utente probabilmente non capisce, dato che non pu&ograve; collegarsi alle sue
porte in ascolto &mdash; che sono gi&agrave; utilizzate dal demone Tor originale.
 
La soluzione attuale prevede o di dire all'utente di fermare il demone
Tor esistente e farne partire uno da Vidalia, oppure di spiegare all'utente
come definire una port e una password nel file di configurazione
torrc. Su Debian una soluzione migliore sarebbe usare il ControlSocket di Tor,
che permetterebbe a Vidalia di parlare con Tor attraverso un Unix domain socket, e potrebbe
essere abilitata di default nei pacchetti Debian di Tor. Vidalia potrebbe 
quindi autenticarsi a Tor con una autenticazione basata sul filesystem (cookie),
usa Vidalia fa parte del gruppo debian-tor.
 
Questo progetto richiede di aggiungere a Vidalia il supporto per ControlSocket
di Tor. Lo studente svilupper&agrave; e tester&agrave; i pacchetti Vidalia
per Debian e Ubuntu in conformit&agrave; agli standard di pacchetto Debian,
e verificher&agrave; che essi funzionino bene con i pacchetti Tor esistenti. Possiamo anche
creare un repository apt per ospitare i nuovi pacchetti Vidalia.
 
Il prossimo passo sar&agrave; trovare un metodo intuitivo e facile perch&eacute; Vidalia
possa modificare la configurazione di Tor (torrc) anche se si trova
in <code>/etc/tor/torrc</code> ed &egrave; quindi non modificabile. Finora la cosa
migliore che abbiamo pensato &egrave; fornire a Tor una nuova configurazione tramite
il ControlSocket quando Vidalia si avvia, ma ha il difetto di far partire Tor
ad ogni boot con una configurazione diversa da quella desiderata dall'utente. L'alternativa
che
ci &egrave; venuta in mente &egrave; che Vidalia scriva un file torrc temporaneo
e chieda all'utente di spostarlo manualmente in <code>/etc/tor/torrc</code>,
ha il difetto di fare interagire l'utente direttamente con i file.
 
Le persone interessate a questo progetto dovrebbero conoscere bene il
Debian package management ed avere qualche esperienza di sviluppo in C++. Apprezzata,
ma non obbligatoria, dell'esperienza con Qt.
</li>

-->
<li>
Improving Tor's ability to resist censorship
 
The Tor 0.2.0.x series makes <a
href="<svnsandbox>doc/design-paper/blocking.html">significant
improvements</a> in resisting national and organizational censorship.
But Tor still needs better mechanisms for some parts of its
anti-censorship design. For example, current Tors can only listen on a
single address/port combination at a time. There's
<a href="<svnsandbox>doc/spec/proposals/118-multiple-orports.txt">a
proposal to address this limitation</a> and allow clients to connect
to any given Tor on multiple addresses and ports, but it needs more
work. Another anti-censorship project (far more difficult) is to try
to make Tor more scanning-resistant. Right now, an adversary can identify
<a href="<svnsandbox>doc/spec/proposals/125-bridges.txt">Tor bridges</a>
just by trying to connect to them, following the Tor protocol, and 
seeing if they respond. To solve this, bridges could
<a href="<svnsandbox>doc/design-paper/blocking.html#tth_sEc9.3">act like
webservers</a> (HTTP or HTTPS) when contacted by port-scanning tools,
and not act like bridges until the user provides a bridge-specific key.
 
This project involves a lot of research and design. One of the big
challenges will be identifying and crafting approaches that can still
resist an adversary even after the adversary knows the design, and
then trading off censorship resistance with usability and robustness.
</li>

<li>
Tor Controller Status Event Interface
 
Vi sono numerosi cambiamenti di stato in Tor, di cui l'utente dovrebbe venire
informato. Ad esempio, se l'utente vuol trasformare Tor in un
relay e Tor decide che le sue porte non sono raggiungibili dall'esterno
della rete dell'utente, l'utente dovrebbe venire avvertito. Adesso tutto quello che l'utente
riceve sono un paio di messaggi nella finestra'message log' di Vidalia, che 
probabilmente non viene mai letta dato che non viene mai ricevuta un avviso
che qualcosa &egrave; andato storto. Anche se l'utente si leggesse il message log,
la maggior parte dei messaggi sarebbe poco utile ad un utente inesperto.
 
Tor pu&ograve; informare Vidalia di vari cambiamenti di stato e da poco
abbiamo realizzato il supporto per alcuni di questi eventi. Rimangono ancora
molti altri eventi di stato di cui si dovrebbe informare l'utente e serve
una interfaccia utente migliore per mostrarli.
 
Lo scopo di questo progetto &egrave; quindi il disegno e la realizzazione di una interfaccia utente
per mostrare gli eventi di stato Tor all'utente. Ad esempio con una piccola
etichetta sull'icona di stato di Vidalia, per avvertire l'utente di nuovi
eventi di stato da controllare. Un doppio clic sull'icona dovrebbe far comparire 
una finsetra di dialogo con un sommario in termini comprensibili degli eventi recenti
e magari con un suggerimento per risolvere gli eventi negativi su cui l'utente
pu&ograve; intervenire. Questo &egrave; comunque solo un esempio e si &egrave;
completamente liberi di suggerire un approccio differente.
 
Le persone interessate a questo progetto dovrebbero avere una buona esperienza nel design e layout di interfacce utente
e qualche esperienza di programmazione in C++. Esperienze con Qt e con
il designer di Qt sono utilissime, ma non obbligatorie. Utile anche
la capaciti&agrave; di comunicazione scritta in inglese, dato che il progetto
probabilmente implicher&agrave; di scrivere una documentazione minima di aiuto
comprensibile per degli utenti non tecnici. Molto apprezzate le capacit&agrave; di
design, grafica, Photoshop dato che potremmo anche avere bisogno di nuove icone.
</li>

<li>
Tuneup Tor!
 
Right now, Tor relays measure and report their own bandwidth, and Tor
clients choose which relays to use in part based on that bandwidth.
This approach is vulnerable to
<a href="http://freehaven.net/anonbib/#bauer:wpes2007">attacks where
relays lie about their bandwidth</a>;
to address this, Tor currently caps the maximum bandwidth
it's willing to believe any relay provides. This is a limited fix, and
a waste of bandwidth capacity to boot. Instead,
Tor should possibly measure bandwidth in a more distributed way, perhaps
as described in the
<a href="http://freehaven.net/anonbib/author.html#snader08">"A Tune-up for
Tor"</a> paper
by Snader and Borisov. One could use current testing code to
double-check this paper's findings and verify the extent to which they
dovetail with Tor as deployed in the wild, and determine good ways to
incorporate them into their suggestions Tor network without adding too
much communications overhead between relays and directory
authorities.
</li>

<li>
Improve our unit testing process
 
Tor needs to be far more tested. This is a multi-part effort. To start
with, our unit test coverage should rise substantially, especially in
the areas outside the utility functions. This will require significant
refactoring of some parts of Tor, in order to dissociate as much logic
as possible from globals.
 
Additionally, we need to automate our performance testing. We've got
buildbot to automate our regular integration and compile testing already
(though we need somebody to set it up on Windows),
but we need to get our network simulation tests (as built in TorFlow: see
the "Tor Node Scanner improvements" item)
updated for more recent versions of Tor, and designed to launch a test
network either on a single machine, or across several, so we can test
changes in performance on machines in different roles automatically.
</li>
 
<li>
Help revive an independent Tor client implementation
 
Reanimate one of the approaches to implement a Tor client in Java,
e.g. the <a href="http://onioncoffee.sourceforge.net/">OnionCoffee
project</a>, and make it run on <a
href="http://code.google.com/android/">Android</a>. The first step
would be to port the existing code and execute it in an Android
environment. Next, the code should be updated to support the newer Tor
protocol versions like the <a href="<svnsandbox>doc/spec/dir-spec.txt">v3
directory protocol</a>. Further, support for requesting or even
providing Tor hidden services would be neat, but not required.
 
A prospective developer should be able to understand and write new Java code, including
a Java cryptography API. Being able to read C code would be helpful,
too. One should be willing to read the existing documentation,
implement code based on it, and refine the documentation
when things are underdocumented. This project is mostly about coding and
to a small degree about design.
</li>

<li>
Bring moniTor to life
 
Implement a <a href="http://www.ss64.com/bash/top.html">top-like</a>
management tool for Tor relays. The purpose of such a tool would be
to monitor a local Tor relay via its control port and include useful
system information of the underlying machine. When running this tool, it
would dynamically update its content like top does for Linux processes.
<a href="http://archives.seul.org/or/dev/Jan-2008/msg00005.html">This
or-dev post</a> might be a good first read.
 
A person interested in this should be familiar
with or willing to learn about administering a Tor relay and configuring
it via its control port. As an initial prototype is written in Python,
some knowledge about writing Python code would be helpful, too. This
project is one part about identifying requirements to such a
tool and designing its interface, and one part lots of coding.
</li>

<li>
Porting Polipo to Windows
 
Help port <a
href="http://www.pps.jussieu.fr/~jch/software/polipo/">Polipo</a> to
Windows. Example topics to tackle include:
1) handle spaces in path names and understand the filesystem
namespace &mdash; that is, where application data, personal data,
and program data typically reside in various versions of Windows. 2) the
ability to handle ipv6 communications. 3) the ability to asynchronously
query name servers, find the system nameservers, and manage netbios
and dns queries. 4) use native regex capabilities of Windows, rather
than using 3rd party GNU regex libraries. 5) manage events and buffers
natively (i.e. in Unix-like OSes, Polipo defaults to 25% of ram, in
Windows it's whatever the config specifies). 6) some sort of GUI config
and reporting tool, bonus if it has a systray icon with right clickable
menu options. Double bonus if it's cross-platform compatible.
</li>

<!-- Is Blossom development still happening?
<li>
Rework and extend Blossom
 
Rework and extend Blossom (a tool for monitoring and
selecting appropriate Tor circuits based upon exit node requirements
specified by the user) to gather data in a self-contained way, with
parameters easily configurable by the user. Blossom is presently
implemented as a single Python script that interfaces with Tor using the
Controller interface and depends upon metadata about Tor nodes obtained
via external processes, such as a webpage indicating status of the nodes
plus publically available data from DNS, whois, etc. This project has
two parts: (1) Determine which additional metadata may be useful and
rework Blossom so that it cleanly obtains the metadata on its own rather
than depend upon external scripts (this may, for example, involve
additional threads or inter-process communication), and (2) develop a
means by which the user can easily configure Blossom, starting with a
configuration file and possibly working up to a web configuration engine.
Knowledge of Tor and Python are important; knowledge of 
TCP, interprocess communication, and Perl will also be helpful. An
interest in network neutrality is important as well, since the
principles of evaluating and understanding internet inconsistency are at
the core of the Blossom effort.
</li>

<li>
Improve Blossom: Allow users to qualitatively describe exit nodes they desire
 
Develop and implement a means of affording Blossom
users the ability to qualitatively describe the exit node that they
want. The Internet is an inconsistent place: some Tor exit nodes see
the world differently than others. As presently implemented, Blossom (a
tool for monitoring and selecting appropriate Tor circuits based upon
exit node requirements specified by the user) lacks a sufficiently rich
language to describe how the different vantage points are different.
For example, some exit nodes may have an upstream network that filters
certain kinds of traffic or certain websites. Other exit nodes may
provide access to special content as a result of their location, perhaps
as a result of discrimination on the part of the content providers
themselves. This project has two parts: (1) develop a language for
describing characteristics of networks in which exit nodes reside, and
(2) incorporate this language into Blossom so that users can select Tor
paths based upon the description.
Knowledge of Tor and Python are important; knowledge of
TCP, interprocess communication, and Perl will also be helpful. An
interest in network neutrality is important as well, since the
principles of evaluating and understanding internet inconsistency are at
the core of the Blossom effort.
</li>
-->

<li>
Contribuisci con delle nuove idee!
 
Nessuna di queste proposte ti piace? Dai un'occhiata alla <a
href="<svnsandbox>doc/roadmaps/2008-12-19-roadmap-full.pdf">Tor development
roadmap</a> per avere altri spunti.
</li>

</ol>

<a id="OtherCoding"></a>
<h2><a class="anchor" href="#OtherCoding">Altre idee di sviluppo e design</a></h2>
<ol>
<li>I relay Tor non funzionano bene su Windows XP. Su
Windows, Tor usa la normale chiamata di sistema <tt>select()</tt>,
che usa spazio nel pool non-page. Ci&ograve; significa
che un server Tor di medie dimensioni esaurir&agrave; il non-page pool, <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/WindowsBufferProblems">causando
confusione e crash del sistema</a>. Probabilmente dovremmo usare overlapped IO.
Una soluzione sarebbe far usare a <a
href="http://www.monkey.org/~provos/libevent/">libevent</a> l'
overlapped IO invece di select() su Windows, per poi adattare Tor
alla nuova interfaccia libevent. Christian King ha dato un
<a href="https://svn.torproject.org/svn/libevent-urz/trunk/">buon inizio
al lavoro</a> nell'estate 2007.</li>

<li>Dobbiamo iniziare a realizzare il nostro <a href="<page
documentation>#DesignDoc">blocking-resistance design</a>. Occorre
ideare il design, modificare varie parti di Tor, adattare
<a href="<page vidalia/index>">Vidalia</a> perch&eacute; supporti le
nuove funzionalit&agrave; e progettarne lo sviluppo.</li>

<li>Serve un framework flessibile di simulazione per studiare gli attacchi
end-to-end di conferma del traffico. Molti ricercatori hanno creato dei sumulatori
ad hoc a sostegno delle loro intuizioni sul funzionamento degli attacchi
o di certe difese e contromisure. Possiamo costruire un simulatore
ben documentato e aperto che possa fornire a ciascuno risposte
adeguare? Questo potrebbe contribuire a molte nuove ricerche.
Vedi la voce <a href="#Research">qui sotto</a> sui confirmation attack per
maggior dettagli sulla ricerca in questo campo &mdash; chiss&agrave; forse al
termine potresti scrivere qualche paper sull'argomento.</li>

<li>Tor 0.1.1.x e successivi includono 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>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>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="https://wiki.torproject.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/spec/proposals/100-tor-spec-udp.txt">specifiche
per Tor e
UDP</a> &mdash; facci sapere se presentano dei problemi.</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>

<li>Ci serve un sistema per generare i diagrammi sul sito web (ad esempio, le immagini
How Tor Works" nella <a href="<page overview>">pagina di panoramica</a>
a partire daisorgenti, in modo da tradurli come testo UTF-8 invece di modificarli
a mano con Gimp. Potremmo integrare ci&ograve;
come file wml per i traduttori e generare cos&igrave; le immagine
in pi&ugrave; lingue quando risostruiamo il sito web.</li>

<li>Come possiamo rendere il <a
href="http://anonymityanywhere.com/incognito/">LiveCD Incognito</a>
pi&ugrave; facile da mantenere, migliorare e documentare?</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>Un altro problema collegato &egrave;: Creare un relay/bridge offre qualche 
protezione in pi&ugrave; contro questi timing attacks? Un avversario esterno che non pu&ograve;
leggere dentro i link TLS pu&ograve; riuscire a riconoscere i singoli flussi in modo affidabile?
La quantit&agrave; di traffico trasportato limita in qualche modo questa eventualit&agrave;? Cosa accadrebbe se
il client-relay ritardasse apposta il traffico upstream creando una coda
che potrebbe essere usata per simulare il timing dal client downstream cos&igrave; da fingere
che sia traffico relayed anch'esso? Questa stessa coda potrebbe essere usata per mascherare
i timing nel traffico upstream monte dai client con tecniche di <a
href="http://www.freehaven.net/anonbib/#ShWa-Timing06">adaptive padding</a>,
ma senza aver bisogno di traffico addizionale. Una simile miscela di
traffico upstream monte dal client potrebbe forse offuscare il timing per un avversario esterno? Questa strategia
deve essere modificata in caso di link asimmetrici? Ad esempio, su
link asimmentrici si riesce a distinguere il traffico del client dai
picchi naturali dovuti all'asimmetria della capacit&agrave; del link? Od &egrave; pi&ugrave;
facile sui link asimmetrici, per qualche altro motivo?</li>
<li>Ripetere l' <a
href="http://www.cl.cam.ac.uk/~sjm217/projects/anon/#torta">attacco da
Oakland 05</a> di Murdoch e Danezi sull'attuale rete Tor. Provare a capire perch&eacute;
funziona bene contro alcuni nodi e non su altri. /La mia teoria &egrave; che
i nodi veloci con capacit&agrave; aggiuntiva resistono meglio al'attacco) Se questo &egrave; vero
allora bisogna provare con le opzioni RelayBandwidthRate e RelayBandwidthBurst
per gestire un relay usato come client mentre si fa da relay al traffico
dell'attaccante: riducendo RelayBandwidthRate, forse l'attacco
diventa pi&ugrave; difficile? Quale &egrave; il rapporto ideale tra RelayBandwidthRate e
capacit&agrave; reale? Ma &egrave; poi un rapporto? Gi&agrave; che ci siamo, un numero
maggiore di potenziali relay aumenta forse il tasso di falsi positivi
o altri fattori complessi per l'attacco? (La rete Tor oggi &egrave; di quasi due
ordini di grandezza maggiore rispetto a quando fu scritto il paper.) Leggi anche
<a href="http://freehaven.net/anonbib/#clog-the-queue">Don't
Clog the Queue</a>.</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>Nella ricerca su Tor vi sono altre questioni riguardo la diversit&agrave; geografica:
considera il costo tra scegliere un circuito client efficienteicient e sceglierne uno
casuale. Leggi il <a
href="http://swiki.cc.gatech.edu:8080/ugResearch/uploads/7/ImprovingTor.pdf">position
paper</a> di Stephen Rollyson per come scartare alcuni circuiti particolarmente lenti senza ledere
"troppo" l'anonimato. Su questa linea di ricerca serve pi&ugrave; lavoro,
ma pare assai promettente.</li>
<li>Tor funziona male quando un relay 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>Uno degli obiettivi per resistere alla censura &egrave; impedire
ad un attaccante che osservi il traffico Tor su una connessione di <a
href="<svnsandbox>doc/design-paper/blocking.html#sec:network-fingerprint">distinguerlo
dal normale traffico SSL</a>. Non possiamo ovviamente ottenere perfetta
steganografia e al contempo essere ancora utilizzabili, ma come primo passo ci
bloccare tutti quegli attacchi che funzionano solo osservando pochi pacchetti. Uno degli
altri attacchi che non abbiamo esaminato ancora a fondo &egrave; che le celle Tor sono di 512
byte, e quindi il traffico sulla connessione potrebbe essere di multipli di 512 byte.
Batching e overhead nei record TLS modificano questo dato sulla connessione?
Ci sono altre strategie di buffer flushing in Tor che influiscono su questo dato? Possiamo
aspettarci dei risultati usando un po' di padding, o si tratta di un attacco che dobbiamo accettare cos&igrave; com'&egrave;?</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 relay 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 relay o alle autorit&agrave; di directory. I client
puzzle sono la soluzione giusta? Quali altri approcci pratici esistono? Un premio
se sono compatibili col protocollo Tor attuale.</li>
<li>Programmi come <a
href="<page torbutton/index>">Torbutton</a> cercano di nascondere
la stringa UserAgent del tuo browser sostituendola con una risposta uniforme
per ogni utente Tor. In questo modo un attaccante non pu&ograve; ridurre l'anonymity set
in base a questo header. Torbutton cerca di usare una stringa comunemente usata anche
da utenti non-Tor in modo da non dare nell'occhio. Prima domanda: quanto
&egrave; dannoso aggiornare periodicamente la versione di Firefox che
Torbutton dichiara? Se la aggiorniamo troppo spessp suddividiamo da soli
l'anonymity set. se non l'aggiorniamo abbastanza spesso allora tutti gli
utenti di Tor spiccano dato che dichiarano una versione obsoleta di
Firefox. La risposta dipende probabilmente dalle versioni di Firefox osservabili
dal vivo. Seconda domanda: ci viene regolarmente chiesto di ruotare N stringhe
UserAgent invece di usarne una sola. &Egrave; un approccio utile, dannoso
o indifferente? Considera per esempio: uso di cookie e riconoscimento di utenti
Torbutton dai loro UserAgent; siti web maliziosi che attaccano solo certi
browser; e se le risposte alla domanda numero uno hanno in impatto sulla seconda domanda.
</li>
<li>Per ora i client Tor riutilizzano un circuito per dieci minuti
da quando &egrave; stato stabilito. Lo scopo &egrave; di evitare il sovraccarico
della rete con troppe operazioni di estensione di circuito, e di evitare al contempo
che i client usino lo stesso circuito troppo a lungo, tanto da permettere a un exit node
di realizzare un profilo pseudonimo utile su di essi. Purtroppo 10 minuti sono
troppo, specie se vengono fatte sullo stesso circuto connessioni per protocolli multipli (come IM e
web browsing). Se manteniamo fisso il numero totale di
circuit extend che la rete deve compiere, esistono altri metodi
pi&ugrave; efficienti o sicuri perch&eacute; i client allochino flussi ai circuiti,
o perch&eacute; i client costruiscano preventivamente dei circuiti? Forse un punto di partenza in
questa ricerca &egrave; la raccolta di informazioni su che genere di connessioni
vengono tipicamente lanciate dai client, in modo da disporre di un quadro realistico su cui lavorare.
</li>
<li>Quanti bridge relay occorre conoscere per mantenere una raggiungibilit&agrave;
ottimale? Bisognerebbe misurare il tasso di esaurimento dei nostri bridge. Se questo &egrave;
alto, ci sono dei modi per mantenere meglio connessi gli utenti dei
bridge?
</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

change the vidalia index page