tor-webwml.git

1) 
2) 

3) 
4) 
5) 
6) 
7) ## translation metadata
8) # Revision: $Revision$
9) # Translation-Priority: 3-low
10) #include "head.wmi" TITLE="Tor: Hidden Service Protocol" CHARSET="UTF-8"

11) <div class="main-column">
12) 
13) <h2>Tor: il protocollo Hidden Service</h2>
14) <hr />
15) 

16) <p>

17) Tor consente ai suoi utilizzatori di offrire vari servizi, come pagine web
18) od un server di messaggistica, nascondendo la propria posizione nella
19) rete. Usando i "rendezvous point" di Tor, gli altri utenti Tor possono
20) utilizzare questi servizi nascosti senza che sia possibile conoscere la

21) reciproca identità di rete. Questa pagina spiega il funzionamento

22) tecnico di questo rendezvous protocol. Per una guida pratica, vedi la pagina
23) <a href="<page docs/tor-hidden-service>">come configurare un hidden
24) service</a>.

25) </p>
26) 

27) <p>

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

38) </p>
39) 
40) # maybe add a speech bubble containing "PK" to Bob, because that's what
41) # Bob tells to his introduction points

42) <img alt="Tor hidden service primo passo" src="$(IMGROOT)/THS-1.png" />
43) 
44) 

45) 
46) <p>

47) Secondo passo: l'hidden service costruisce un <em>hidden service

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

56) </p>
57) 
58) <p>

59) Anche se usare un nome del servizio generato automaticamente sembra scomodo,
60) ciò ha uno scopo importante: tutti – compresi gli introduction
61) point, i directory server, e naturalmente i client – possono
62) verificare di stare parlando con il giusto hidden service. Vedi anche <a
63) href="https://zooko.com/distnames.html">la congettura di Zooko </a> per cui
64) dei tre fattori Decentrato, Sicuro ed Umanamente Comprensibile ne puoi
65) ottenere solo due contemporaneamente. Un giorno forse qualcuno
66) realizzer&agrave; un progetto <a

67) href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">Petname</a>

68) per i nomi degli hidden service?

69) </p>
70) 

71) # maybe replace "database" with "DHT"; further: how incorrect

72) # is it to *not* add DB to the Tor cloud, now that begin dir cells are in
73) # use?

74) <img alt="Tor hidden service passo due" src="$(IMGROOT)/THS-2.png" />
75) 
76) 
77) 

78) 
79) <p>

80) Terzo passo: quando un client desidera contattare un hidden service, deve
81) conoscere prima il suo undirizzo onion. Dopodiché il client
82) può iniziare a stabilire la connessione scaricandone il descrittore
83) dai directory server. Se esiste un descrittore per XYZ.onion (l'hidden
84) service potrebbe essere anche offline o essere scomparso da tempo, o
85) l'indirizzo onion potrebbe contenere un refuso), il client ora conosce il
86) gruppo di introduction point e la corretta chiave pubblica. In questo
87) momento il client crea anche un circuito verso un altro relay scelto a caso
88) e gli chiede di fungere da <em>rendezvous point</em> comunicandogli un
89) one-time secret.

90) </p>
91) 
92) # maybe add "cookie" to speech bubble, separated from the surrounded
93) # "IP1-3" and "PK"

94) <img alt="Tor hidden service passo tre" src="$(IMGROOT)/THS-3.png" />
95) 
96) 

97) 
98) <p>

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

107) </p>
108) 
109) <img alt="Tor hidden service passo quattro" src="$(IMGROOT)/THS-4.png" />
110) 
111) <p>

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

116) </p>
117) 
118) <p>
119) A questo punto &egrave; molto importante che l'hidden service continui ad

120) usare lo stesso gruppo di <a
121) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#EntryGuards">entry

122) guard</a> per creare nuovi circuiti. Altrimenti un attaccante potrebbe
123) gestire un proprio nodo e forzare un hidden service a creare un numero
124) arbitrario di circuiti sperando che prima o poi il relay corrotto venga
125) scelto come nodo di ingresso, venendo a conoscere cos&igrave; l'indirizzo IP
126) dell'hidden service con una analisi sincronizzata. Questo attacco &egrave;
127) stato descritto da &Oslash;verlier e Syverson nel loro saggio intitolato <a
128) href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden
129) Servers</a>.

130) </p>
131) 
132) # it should say "Bob connects to Alice's ..."

133) <img alt="Tor hidden service passo cinque" src="$(IMGROOT)/THS-5.png" />
134) 

135) 
136) <p>

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

142) </p>
143) 
144) <p>

145) Uno dei motivi per non usare l'introduction circuit per le successive
146) comunicazioni è che nessun singolo relay deve sembrare responsabile
147) per un certo hidden servce. Ecco perché il rendezvous point non viene
148) mai a conoscere l'identità dell'hidden service.

149) </p>
150) 
151) <p>

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

155) </p>
156) 
157) <img alt="Tor hidden service passo sei" src="$(IMGROOT)/THS-6.png" />
158) 
159) <p>

160) Ci sono descrizioni del protocollo hidden service più approfondite di
161) questa. Vedi il <a href="<svnsandbox>doc/design-paper/tor-design.pdf">Tor
162) design paper</a> per una descrizione dettagliata e la <a
163) href="<svnsandbox>doc/spec/rend-spec.txt">rendezvous specification</a> per
164) il formato dei messaggi.

165) </p>
166) 

167)   </div>
168)