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&agrave; 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&eacute; 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&ograve; ha uno scopo importante: tutti &ndash; compresi gli introduction
61) point, i directory server, e naturalmente i client &ndash; 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&eacute; il client
82) pu&ograve; 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) At this point it is of special importance that the hidden service sticks to
120) the same set of <a
121) href="<wiki>TorFAQ#Whatsthisaboutentryguardformerlyknownashelpernodes">entry
122) guards</a> when creating new circuits. Otherwise an attacker could run his
123) own relay and force a hidden service to create an arbitrary number of
124) circuits in the hope that the corrupt relay is picked as entry node and he
125) learns the hidden server's IP address via timing analysis. This attack was
126) described by &Oslash;verlier and Syverson in their paper titled <a