it/volunteer.wml (760af3c30) - tor-webwml.git

volunteer.wml

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

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

<h2>Tre 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>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="Usability"></a>
<h2><a class="anchor" href="#Usability">Applicazioni di supporto</a></h2>
<ol>
<li>Servono altri buoni 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>Tor pu&ograve; <a
href="https://wiki.torproject.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 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="http://vidalia-project.net/">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>

Alcuni di questi progetti potrebbero essere dei buoni candidati per <a href="<page
gsoc>">Google Summer of Code 2008</a>. Abbiamo classificato ogni idea
secondo l'utilit&agrave; complessiva al progetto Tor
(priorit&agrave;), quanto lavoro stimiamo sia necessario (livello d'impegno), quante
conoscenze servono per iniziare (livello di competenze), e quali dei nostri <a href="<page
people>#Core">principali programmatori</a> potrebbero essere dei buoni mentori.


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

<ol>

<li>
Framework per l'aggiornamento automatico di Tor/Polipo/Vidalia Framework
 
Priorit&agrave;: Alta
 
Impegno: Alto
 
Competenze: Alte
 
Possibili mentori: Matt, Jacob
 
Ci seve un buon framework per l'aggiornamento autenticato.
Vidalia si accorge gi&agrave; se l'utente ha una versione obsoleta
o deprecata di Tor, tramite dei signed statement nelle informazioni
di directory Tor. Al momento Vidalia manda una semplice
finestra di avviso che informa l'utente che dovrebbe aggiornare manualmente.
Lo scopo del progetto &egrave; di estendere Vidalia aggiungendo la
possibilit&agrave; di scaricare e installare il software Tor aggiornato al
posto dell'utente. Il download dovrebbe avenire via Tor quando possibile, con un buon
meccanismo di fall back al download diretto. Tempo permettendo sarebbe bello
potere aggiornare altre applicazioni
contenute nei pacchetti di installazione, come Polipo e
Vidalia stessa.
 
Per portare a termine il progetto, lo studente dovr&agrave; anzitutto studiare
il framework di auto-update esistente (ad es., Sparkle su OS X) per valutarne
vantaggi, debolezze, fattori di sicurezza e possibilit&agrave; di venire
integrato in Vidalia. Se non se ne trovano di adatti, lo studente
disegner&agrave; uno proprio frameword di auto aggiornamento, documentando il disegno e
discutendolo con altri sviluppatori per verificarne gli aspetti di sicurezza.
Lo studente realizzer&agrave; poi il framework (o lo integrer&agrave; con
uno esistente) e lo sottoporr6agrave; a test.
 
Gli studenti interessati a questo progetto devono avere una buona esperienza di sviluppo
in C++. Utili, ma non obbligatorie, esperienze di Qt. Occorre anche
una buona comprensione delle comuni pratiche di sicurezza,
come la package signature verification. Importanti per il progetto anche buone
capacit&agrave; di comunicazione scritta, poich&eacute; una fase cruciale
sar&agrave; la produzione di un design document che altri valuteranno e discuteranno
con lo studente prima della realizzazione.
</li>

<li>
Una Network Map per Vidalia migliore e pi&ugrave; usabile
 
Priorit&agrave;: Media
 
Impegno: Medio
 
Competenze: Medio-alte
 
Possibili mentori: Matt
 
Vidalia ha una carta della rete che mostra all'utente la posizione
geografica approssimata dei nodi nella rete Tor e che
disegna il percorso del traffico dell'utente attraverso i tunnel stabiliti nella
rete Tor. The mappa per ora non &egrave; molto interattiva ed ha una grafica
spartana. Ci piacerebbe usare il widget KDE Marble che
crea mappe di miglior qualit&agrave; ed offre maggior einterattivit&agrave;,
permettendo all'utente di fare clic su singoli nodi o circuiti per ottenere
maggiori informazioni. Potremmo anche permettere all'utente di fare
clic su un particolare nodo o su un paese contenente uno o pi&ugrave;
Tor exit relay e dire, ad esempio: "Voglio che le mie connessioni a pippo.com
escano da qui."
 
Questo progetto richiede anzitutto che lo studente si familiarizzi con Vidalia
e le API del widget Marble. Lo studente integrer&agrave; poi il widget
in Vidalia e personalizzer&agrave; Marble per adattarlo meglio ai nostri bisogni,
ad esempio rendendo cliccabili i circuiti, memorizzando i dati di cache nella
data directory di Vidalia, e personalizzando alcuni messaggi di dialogo del widget.
 
Gli studenti impegnati in questo progettp devono avere una buona esperienza
di sviluppo C++. Utile, ma non obbligatorio, avere avuto esperienza con Qt e
Cmake.
</li>

<li>
Una migliore gestione dei pacchetti Debian per Tor e Vidalia
 
Priorit&agrave;: Alta
 
Impeglo: Medio
 
Competenze: Medie
 
Possibili mentori: Peter, Matt
 
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.
 
Studenti interessati 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>
Tor Controller Status Event Interface
 
Priorit&agrave;: Media
 
Impegno: Medio
 
Comtepenze: Medie
 
Possibili mentori: Matt, Roger
 
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 lo studente sar&agrave;
completamente libero di suggerire un approccio differente.
 
Gli studenti interessati 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>
Translation Wiki
 
Priorit&agrave;: Alta
 
Impegno: Medio
 
Competenze: Medie
 
Possibili mentori: Jacob
 
Ci serve un sistema per modificare e tradurre il nostro sito web. Ad oggi
il sito &egrave; fatto con alcuni <a href="<svnwebsite>en/">file
wml</a> ed i <a href="<page translation>">traduttori</a> scaricano i file
wml, li traducono in un editor e ci spediscono la traduzione oppure
usano svn per fare un commit direttamente. Il "costo" attuale per pubblicare
modifiche al sito web &egrave; abbastanza alto anche per utenti di lingua inglese. Una
modifica di una sola parola o per qualsiasi modifica minore,
pu&ograve; capitare che la pagina non venga mai aggiornata o tradotta. Sarebbe
bello avere un wiki rivolto specificamente alla traduzione,
che in qualche modo seguisse le versioni upstream (in inglese) per segnalare
quando serve una nuova traduzione, analogamente alla nostra
<a href="<page translation-status>">pagina sullo stato delle traduzioni</a>. Sembra
probabilmente un lavoro per un integratore di
wiki o per l'autore di un software per wiki. Di certo la persona dovrebbe essere
interessata alle lingue e alla traduzione. Il candidato dovrebbe avere una
certa familiarit&agrave; di base con Tor, ma non dovrebbe interagire col
software, bens&igrave; solo con la documentazione e con il sito web.
</li>

<li>
Improvements on our active browser configuration tester - 
<a href="https://check.torproject.org/">https://check.torproject.org/</a>
 
Priority: Medium
 
Effort Level: Low
 
Skill Level: Low to Medium
 
Likely Mentors: Jacob, Steven
 
We currently have a functional web page to detect if Tor is working. It
has a few places where it falls short. It requires improvements with
regard to default languages and functionality. It currently only responds
in English. In addition, it is a hack of a perl script that should have
never seen the light of day. It should probably be rewritten in python
with multi-lingual support in mind. It currently uses the <a
href="http://exitlist.torproject.org/">Tor DNS exit list</a>
and should continue to do so in the future. It currently result in certain
false positives and these should be discovered, documented, and fixed
where possible. Anyone working on this project should be interested in
DNS, basic perl or preferably python programming skills, and will have
to interact minimally with Tor to test their code.
 
If you want to make the project more exciting
and involve more design and coding, take a look at <a
href="<svnsandbox>doc/spec/proposals/131-verify-tor-usage.txt">proposal
131-verify-tor-usage.txt</a>.
</li>

<li>
Improvements on our DNS Exit List service - 
<a href="http://exitlist.torproject.org/">http://exitlist.torproject.org/</a>
 
Priority: Medium
 
Effort Level: Low
 
Skill Level: Low
 
Likely Mentors: Jacob, Tup
 
The <a href="http://p56soo2ibjkx23xo.onion/">exitlist software</a>
is written by our fabulous anonymous
contributer Tup. It's a DNS server written in Haskell that supports part of our <a
href="https://www.torproject.org/svn/trunk/doc/contrib/torel-design.txt">exitlist
design document</a>. Currently, it is functional and it is used by
check.torproject.org and other users. The issues that are outstanding
are mostly aesthetic. This wonderful service could use a much better
website using the common Tor theme. It would be best served with better
documentation for common services that use an RBL. It could use more
publicity. A person working on this project should be interested in DNS,
basic RBL configuration for popular services, and writing documentation.
The person would require minimal Tor interaction &mdash; testing their
own documentation at the very least. Furthermore, it would be useful
if they were interested in Haskell and wanted to implement more of the
torel-design.txt suggestions.
</li>

<li>
Testing integration of Tor with web browsers for our end users
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Jacob, Mike, Greg
 
The Tor project currently lacks a solid test suite to ensure that a
user has a properly and safely configured web browser. It should test for as
many known issues as possible. It should attempt to decloak the
user in any way possible. Two current webpages that track these
kinds of issues are run by Greg Fleischer and HD Moore. Greg keeps a nice <a
href="http://pseudo-flaw.net/tor/torbutton/">list of issues along
with their proof of concept code, bug issues, etc</a>. HD Moore runs
the <a href="http://metasploit.com/research/projects/decloak/">metasploit
decloak website</a>. A student interested in defending Tor could start
by collecting as many workable and known methods for decloaking a
Tor user. (<a href="https://torcheck.xenobite.eu/">This page</a> may
be helpful as a start.) The student should be familiar with the common
pitfalls but
possibly have new methods in mind for implementing decloaking issues. The
website should ensure that it tells a user what their problem is. It
should help them to fix the problem or direct them to the proper support
channels. The student should be closely familiar with using Tor and how
to prevent Tor information leakage.
</li>

<li>
Improving Tor's ability to resist censorship
 
Priority: High
 
Effort Level: High
 
Skill Level: High
 
Likely Mentors: Nick
 
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>
Libevent and Tor integration improvements
 
Priority: Medium
 
Effort Level: High
 
Skill Level: Medium to High
 
Likely Mentors: Nick
 
Tor should make better use of the more recent features of Niels
Provos's <a href="http://monkey.org/~provos/libevent/">Libevent</a>
library. Tor already uses Libevent for its low-level asynchronous IO
calls, and could also use Libevent's increasingly good implementations
of network buffers and of HTTP. This wouldn't be simply a matter of
replacing Tor's internal calls with calls to Libevent: instead, we'll
need to refactor Tor to use Libevent calls that do not follow the
same models as Tor's existing backends. Also, we'll need to add
missing functionality to Libevent as needed &mdash; most difficult likely
will be adding OpenSSL support on top of Libevent's buffer abstraction.
Also tricky will be adding rate-limiting to Libevent.
</li>

<li>
Tuneup Tor!
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium to High
 
Likely Mentors: Nick, Roger, Mike
 
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. A student 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
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Nick
 
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
 
Priority: Medium
 
Effort Level: High
 
Skill Level: Medium to High
 
Likely Mentors: Karsten, Nick
 
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.
 
The student 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. The student 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>
Automatic system tests and automatically starting private Tor networks
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Karsten, Nick, Roger
 
Write a tool that runs automatic system tests in addition
to the existing unit tests. The Java-based Tor simulator <a
href="https://tor-svn.freehaven.net/svn/puppetor/trunk/">PuppeTor</a>
might be a good start for starting up a private Tor network, using it
for a while, and verifying that at least parts of it are working. This
project requires to conceive a blueprint for performing system tests
of private Tor networks, before starting to code. Typical types of
tests range from performing single requests over the private network to
manipulating exchanged messages and see if nodes handle corrupt messages
appropriately.
 
The student should be able to obtain a good understanding
of how Tor works and what problems and bugs could arise to design good
test cases. Understanding the existing Tor code structure and documentation is
vital. If PuppeTor is used, the student should also be able to understand
and possibly extend an existing Java application. This project is partly
about design and partly about coding.
</li>

<li>
Bring moniTor to life
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Low to Medium
 
Likely Mentors: Karsten, Jacob
 
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.
 
The student 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>
Tor Exit Scanner improvements
 
Priority: High
 
Effort Level: High
 
Skill Level: High
 
Likely Mentors: Mike
 
The Tor exit node scanner 'SoaT', part of the <a
href="<svnsandbox>torflow/">Torflow project</a>, makes connections out
of each Tor exit node and compares the content it gets back with what it
"should" get back. The goal is to notice misconfigured, broken, and even
malicious exit relays. Alas, the code is
currently written in rather rickety perl and relies on MD5sums of
entire documents in order to determine if exit nodes are modifying
content. The problem with this is threefold: 1) Perl sucks at life.
2) The scanner can't verify pages that are dynamic, and attackers can
focus malicious content injection on only those dynamic pages. 3)
Pages change after a while (or based on GeoIP) and begin generating
false positives.
 
Ideally, soat.pl would be reimplemented in a sane language with a
robust html parser library (since the rest of Torflow is in Python
that would be nice, but it is not required), and calculate signatures only for
tags and content likely to be targeted by a malicious attacker (script
tags, object links, images, css). It should also be robust in the face of
changes to content outside of Tor, and ultimately even GeoIP localized
content.
 
This scanner would likely be run by the Directory Authorities and
report its results to the control port via the AuthDirBadExit config
setting.
 
</li>

<li>
Tor Node Scanner improvements
 
Priority: High
 
Effort Level: Medium to High
 
Skill Level: Medium to High
 
Likely Mentors: Mike
 
Similar to the exit scanner (or perhaps even during exit scanning),
statistics can be gathered about the reliability of nodes. Nodes that
fail too high a percentage of their circuits should not be given
Guard status. Perhaps they should have their reported bandwidth
penalized by some ratio as well, or just get marked as Invalid. In
addition, nodes that exhibit a very low average stream capacity but
advertise a very high node bandwidth can also be marked as Invalid.
Much of this statistics gathering is already done, it just needs to be
transformed into something that can be reported to the Directory
Authorities to blacklist/penalize nodes in such a way that clients
will listen.
 
In addition, these same statistics can be gathered about the traffic
through a node. Events can be added to the <a
href="https://www.torproject.org/svn/torctl/doc/howto.txt">Tor Control
Protocol</a> to
report if a circuit extend attempt through the node succeeds or fails, and
passive statistics can be gathered on both bandwidth and reliability
of other nodes via a node-based monitor using these events. Such a
scanner would also report information on oddly-behaving nodes to
the Directory Authorities, but a communication channel for this
currently does not exist and would need to be developed as well.
</li>

<li>
Help track the overall Tor Network status
 
Priority: High
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Roger, Nick, Mike
 
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>

<li>
Tor path selection improvements
 
Priority: High
 
Effort Level: Low to Medium
 
Skill Level: High
 
Likely Mentors: Roger, Nick, Mike
 
Some simple improvements can be made to Tor's path selection to vastly
improve Tor speed. For instance, some of the (unofficial) <a
href="http://wiki.noreply.org/noreply/TheOnionRouter/FireFoxTorPerf">Tor
Performance Recommendations</a> on the wiki are to increase the number of
guards and decrease the CircuitBuildTimeout. Ideally, the client would
<a href="http://archives.seul.org/or/talk/Feb-2008/msg00012.html">learn
these values by gathering statistics on circuit construction
time</a> (and/or using values gained from Torflow), and set the timeouts
low enough such that some high percentile (75%, 90%, 1-stddev?) of
circuits succeed, yet extremely slow nodes are avoided. This would
involve some statistics gathering+basic research, and some changes to 
Tor path selection code.
 
In addition, to improve path security, some elements from the <a
href="http://www.torproject.org/svn/trunk/doc/spec/proposals/115-two-hop-paths.txt">Two
Hop Paths proposal</a> could be done as part of this (since it will
likely touch the same code anyways), regardless of the adoption of
that proposal. In particular, clients probably should avoid guards that
seem to fail an excessive percentage of their circuits through them,
and non-firewalled clients should issue a warning if they are only able
to connect to a limited set of guard nodes. See also
<a href="http://archives.seul.org/or/dev/Feb-2008/msg00003.html">this
or-dev post</a>.
</li>

<li>
Torbutton improvements
 
Priority: Medium
 
Effort Level: High
 
Skill Level: High
 
Likely Mentors: Mike
 
Torbutton has a number of improvements that can be made in the post-1.2
timeframe. Most of these are documented as feature requests in the <a
href="https://bugs.torproject.org/flyspray/index.php?tasks=all&project=5">Torbutton
flyspray section</a>. Good examples include: stripping off node.exit on http
headers, more fine-grained control over formfill blocking, improved referrer
spoofing based on the domain of the site (a-la <a
href="http://addons.mozilla.org/firefox/addon/4513">refspoof extension</a>),
tighter integration with Vidalia for reporting Tor status, a New Identity
button with Tor integration and multiple identity management, and anything
else you might think of.
 
This work would be independent coding in Javascript and the fun world of <a
href="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">XUL</a>,
with not too much involvement in the Tor internals.
</li>

<li>
Porting Polipo to Windows
 
Priority: Medium
 
Effort Level: Medium
 
Skill Level: Medium to High
 
Likely Mentors: Andrew, Steven, Roger
 
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>

<li>
Make our diagrams beautiful and automated
 
Priority: Medium
 
Effort Level: Low
 
Skill Level: Low
 
Likely Mentors: Andrew
 
We need a way to generate the website diagrams (for example, the "How
Tor Works" pictures on the <a href="<page overview>">overview page</a>
from source, so we can translate them as UTF-8 text rather than edit
them by hand with Gimp. We might want to
integrate this as an wml file so translations are easy and images are
generated in multiple languages whenever we build the website. See the
"Translation Wiki" idea above.
</li>

<li>
Improve the LiveCD offerings for the Tor community
 
Priority: Low
 
Effort Level: Low
 
Skill Level: Medium to High
 
Likely Mentors: Anonym, Jacob, Roger
 
How can we make the <a
href="http://anonymityanywhere.com/incognito/">Incognito LiveCD</a>
easier to maintain, improve, and document?
</li>

<li>
Rework and extend Blossom
 
Priority: Medium
 
Effort Level: Medium to High
 
Skill Level: Medium to High
 
Likely Mentors: Goodell
 
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.
</li>

<li>
Improve Blossom: Allow users to qualitatively describe exit nodes they desire
 
Priority: Low
 
Effort Level: Medium
 
Skill Level: Medium
 
Likely Mentors: Goodell
 
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.
</li>

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

</ol>

<h2><a class="anchor" href="#Coding">Programmazione 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://tor-svn.freehaven.net/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="http://vidalia-project.net/">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>
</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>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>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 "Tor for Freedom" 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 il nostro <a href="<page documentation>#DesignDoc">early
blocking-resistance design document</a> e la nostra <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#BlockingResistance">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 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>
</ol>

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

</div>

#include <foot.wmi>

tor-webwml.git

italian: fix broken link for GSoC item in volunteer page, it's no.5 translation wiki