it/hidden-services.wml (86929a088) - tor-webwml.git

hidden-services.wml

## translation metadata
# Based-On-Revision: 17024
# Last-Translator: jan at seul . org

#include "head.wmi" TITLE="Tor: il protocollo Hidden Service"

<h2>Tor: il protocollo Hidden Service</h2>
<hr />

Tor consente ai suoi utilizzatori di offrire vari servizi, come pagine
web od un server di messaggistica, nascondendo la propria posizione
nella rete. Usando i "rendezvous point" di Tor, gli altri utenti Tor
possono utilizzare questi servizi nascosti senza che sia possibile conoscere la
reciproca identit&agrave; di rete. Questa pagina spiega il funzionamento
tecnico di questo rendezvous protocol. Per una guida pratica, vedi la pagina <a
href="<page docs/tor-hidden-service>">come configurare un hidden service</a>.

Affinch&eacute; i client possano contattarlo, un hidden service deve anzitutto rendere nota
la sua esistenza nella rete Tor. Per questo il servizio sceglie alcuni relay
a caso, stabilisce dei circuiti verso di essi e chiede loro di fungere da
introduction point comunicandogli la sua chiave pubblica. Nelle
immagini seguenti le linee verdi rappresentano circuiti, e non
connessioni dirette. Usando un circuito Tor completo &egrave; difficile che
qualcuno associ un introduction point con l'indirizzo IP dell'hidden server.
Mentre l'introduction point e gli altri conoscono l'identit&agrave;
dell'hidden service (la sua chiave pubblica), essi non devono conoscere la
posizione dell'hidden server (il suo indirizzo IP).

<img alt="Tor hidden service primo passo" src="$(IMGROOT)/THS-1.png" />
# maybe add a speech bubble containing "PK" to Bob, because that's what
# Bob tells to his introduction points

Secondo passo: l'hidden service costruisce un hidden service
descriptor, contenente la sua chiave pubblica ed un sommario
degli introduction point, e firma questo descriptor con la sua chiave privata.
Invia il descriptor a un gruppo di directory server, usando sempre un
circuito completo Tor per celare il collegamento tra il directory server contenente
il descriptor e l'indirizzo IP dell'hidden server. Il descriptor verr&agrave;
trovato dai cient che richiederanno XYZ.onion,dove XYZ &egrave; un nome di 16 caratteri
derivato in modo unico dalla chiave pubblica dell'hidden service. Dopo
questo passo, l'hidden service &egrave; attivo.

Anche se usare un nome del servizio generato automaticamente sembra
scomodo, ci&ograve; ha uno scopo importante: tutti &ndash; compresi
gli introduction point, i directory server, e naturalmente i
client &ndash; possono verificare di stare parlando con il giusto hidden
service. Vedi anche <a href="https://zooko.com/distnames.html">la congettura di Zooko
</a> per cui dei tre fattori Decentrato, Sicuro ed Umanamente Comprensibile ne
puoi ottenere solo due contemporaneamente. Un giorno forse qualcuno realizzer&agrave; un progetto <a
href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">Petname</a>
per i nomi degli hidden service?

<img alt="Tor hidden service passo due" src="$(IMGROOT)/THS-2.png" />
# maybe replace "database" with "directory servers"; further: how incorrect
# is it to *not* add DB to the Tor cloud, now that begin dir cells are in
# use?

Terzo passo: quando un client desidera contattare un hidden service, deve 
conoscere prima
il suo undirizzo onion. Dopodich&eacute; il client pu&ograve; iniziare a
stabilire la connessione scaricandone il descrittore dai directory server. Se
esiste un descrittore per XYZ.onion (l'hidden service potrebbe essere anche
offline o essere scomparso da tempo, o l'indirizzo onion potrebbe contenere
un refuso), il client ora conosce il gruppo di introduction point e la
corretta chiave pubblica. In questo momento il client crea anche un
circuito verso un altro relay scelto a caso e gli chiede di fungere da
rendezvous point comunicandogli un one-time secret.

<img alt="Tor hidden service passo tre" src="$(IMGROOT)/THS-3.png" />
# maybe add "cookie" to speech bubble, separated from the surrounded
# "IP1-3" and "PK"

Quarto passaggio: una volta presente il descriptor e pronto il rendezvous point,
il client costruisce un introduce
message (cifrato con la chiave pubblica dell'hidden service) contenente
l'indirizzo del rendezvous point ed il segreto monouso. Il client invia
questo messaggio a uno degli introduction point, chiedendo che venga consegnato
all'hidden service. La comunicazione avviene sempre tramite un circuito Tor:
in questo modo nessuno pu&ograve; collegare l'invio dell'introduce message all'indirizzo IP
del client, ed il client rimane cos&igrave; anonimo.

Quinto passaggio: l'hidden service decifra l'introduce message del client
e scopre l'indirizzo
del rendezvous point ed il segreto monouso contenuto. Il service
crea un circuito verso il rendezvous point e gli invia il segreto monouso in
un rendezvous message.

A questo punto &egrave; molto importante che l'hidden service continui ad
usare lo stesso gruppo di <a
href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#EntryGuards">entry
guard</a> per creare nuovi circuiti. Altrimenti un attaccante
potrebbe gestire un proprio nodo e forzare un hidden service a creare un numero arbitrario
di circuiti sperando che prima o poi il relay corrotto venga scelto come nodo
di ingresso, venendo a conoscere cos&igrave; l'indirizzo IP dell'hidden service con una analisi sincronizzata. Questo 
attacco &egrave; stato descritto da &Oslash;verlier e Syverson nel loro saggio intitolato
<a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden Servers</a>.

<img alt="Tor hidden service passo cinque" src="$(IMGROOT)/THS-5.png" />
# it should say "Bob connects to Alice's ..."

Nell'ultimo passaggio, il rendezvous point notifica al client che la connessione
&egrave; stata stabilita con successo. Dopodich&eacute; il client e l'hidden service possono usare
i loro circuiti verso il rendezvous point per comunicare tra di loro.
Il rendezvous point inoltra semplicemente i messaggi (cifrati end-to-end) dal
client al service e viceversa.

Uno dei motivi per non usare l'introduction circuit 
per le successive comunicazioni &egrave; che nessun singolo relay
deve sembrare responsabile per un certo hidden servce. Ecco perch&eacute; il
rendezvous point non viene mai a conoscere l'identit&agrave; dell'hidden service.

In generale il collegamento completo tra client ed hidden service
consiste in 6 relay: 3 di essi vengono scelti dal client, il terzo dei quali
&egrave; il endezvous point, gli altri 3 vengono scelti dall'hidden
service.

Ci sono descrizioni del protocollo hidden service pi&ugrave; approfondite 
di questa. Vedi il
<a href="<svnprojects>design-paper/tor-design.pdf">Tor design paper</a>
per una descrizione dettagliata e la
<a href="<gitblob>doc/spec/rend-spec.txt">rendezvous specification</a>
per il formato dei messaggi.

</div>

#include <foot.wmi>

tor-webwml.git

Now that the design paper was moved back to Subversion, fix links (see tor.git changeset f164a76 and svn revision r21665). Found by katoda