tor-webwml.git

1) ## translation metadata

2) # Based-On-Revision: 17024

3) # Last-Translator: jan at seul . org
4) 
5) #include "head.wmi" TITLE="Tor: il protocollo Hidden Service"
6) 
7) <div class="main-column">
8) 
9) <h2>Tor: il protocollo Hidden Service</h2>
10) <hr />
11) 

12) <p>
13) Tor consente ai suoi utilizzatori di offrire vari servizi, come pagine
14) web od un server di messaggistica, nascondendo la propria posizione
15) nella rete. Usando i "rendezvous point" di Tor, gli altri utenti Tor
16) possono utilizzare questi servizi nascosti senza che sia possibile conoscere la

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

18) tecnico di questo rendezvous protocol. Per una guida pratica, vedi la pagina <a
19) href="<page docs/tor-hidden-service>">come configurare un hidden service</a>.
20) </p>
21) 

22) <p>
23) Affinch&eacute; i client possano contattarlo, un hidden service deve anzitutto rendere nota
24) la sua esistenza nella rete Tor. Per questo il servizio sceglie alcuni relay
25) a caso, stabilisce dei circuiti verso di essi e chiede loro di fungere da

26) <em>introduction point</em> comunicandogli la sua chiave pubblica. Nelle
27) immagini seguenti le linee verdi rappresentano circuiti, e non
28) connessioni dirette. Usando un circuito Tor completo &egrave; difficile che
29) qualcuno associ un introduction point con l'indirizzo IP dell'hidden server.
30) Mentre l'introduction point e gli altri conoscono l'identit&agrave;
31) dell'hidden service (la sua chiave pubblica), essi non devono conoscere la
32) posizione dell'hidden server (il suo indirizzo IP).

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

40) Secondo passo: l'hidden service costruisce un <em>hidden service
41) descriptor</em>, contenente la sua chiave pubblica ed un sommario
42) degli introduction point, e firma questo descriptor con la sua chiave privata.
43) Invia il descriptor a un gruppo  di directory server, usando sempre un
44) circuito completo Tor per celare il collegamento tra il directory server contenente
45) il descriptor e l'indirizzo IP dell'hidden server. Il descriptor verr&agrave;
46) trovato dai cient che richiederanno XYZ.onion,dove XYZ &egrave; un nome di 16 caratteri
47) derivato in modo unico dalla chiave pubblica dell'hidden service. Dopo
48) questo passo, l'hidden service &egrave; attivo.
49) </p>
50) 
51) <p>
52) Anche se usare un nome del servizio generato automaticamente sembra

53) scomodo, ciò ha uno scopo importante: tutti – compresi

54) gli introduction point, i directory server, e naturalmente i
55) client – possono verificare di stare parlando con il giusto hidden
56) service. Vedi anche <a href="https://zooko.com/distnames.html">la congettura di Zooko
57) </a> per cui dei tre fattori Decentrato, Sicuro ed Umanamente Comprensibile ne

58) puoi ottenere solo due contemporaneamente. Un giorno forse qualcuno realizzer&agrave; un progetto <a

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

60) per i nomi degli hidden service?

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

69) Terzo passo: quando un client desidera contattare un hidden service, deve 
70) conoscere prima

71) il suo undirizzo onion. Dopodiché il client può iniziare a
72) stabilire la connessione scaricandone il descrittore dai directory server. Se
73) esiste un descrittore per XYZ.onion (l'hidden service potrebbe essere anche
74) offline o essere scomparso da tempo, o l'indirizzo onion potrebbe contenere

75) un refuso), il client ora conosce il gruppo di introduction point e la
76) corretta chiave pubblica. In questo momento il client crea anche un
77) circuito verso un altro relay scelto a caso e gli chiede di fungere da
78) <em>rendezvous point</em> comunicandogli un one-time secret.

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

86) Quarto passaggio: una volta presente il descriptor e pronto il rendezvous point,

87) il client costruisce un <em>introduce</em>

88) message (cifrato con la chiave pubblica dell'hidden service) contenente
89) l'indirizzo del rendezvous point ed il segreto monouso. Il client invia

90) questo messaggio a uno degli introduction point, chiedendo che venga consegnato
91) all'hidden service. La comunicazione avviene sempre tramite un circuito Tor:
92) in questo modo nessuno può collegare l'invio dell'introduce message all'indirizzo IP
93) del client, ed il client rimane così anonimo.

94) </p>
95) 
96) <img alt="Tor hidden service passo quattro" src="$(IMGROOT)/THS-4.png" />
97) 
98) <p>

99) Quinto passaggio: l'hidden service decifra l'introduce message del client
100) e scopre l'indirizzo

101) del rendezvous point ed il segreto monouso contenuto. Il service
102) crea un circuito verso il rendezvous point e gli invia il segreto monouso in
103) un rendezvous message.
104) </p>
105) 
106) <p>
107) A questo punto &egrave; molto importante che l'hidden service continui ad

108) usare lo stesso gruppo di <a
109) href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#EntryGuards">entry
110) guard</a> per creare nuovi circuiti. Altrimenti un attaccante

111) potrebbe gestire un proprio nodo e forzare un hidden service a creare un numero arbitrario
112) di circuiti sperando che prima o poi il relay corrotto venga scelto come nodo
113) di ingresso, venendo a conoscere così l'indirizzo IP dell'hidden service con una analisi sincronizzata. Questo 
114) attacco è stato descritto da Øverlier e Syverson nel loro saggio intitolato

115) <a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden Servers</a>.

116) </p>
117) 
118) <img alt="Tor hidden service passo cinque" src="$(IMGROOT)/THS-5.png" />
119) # it should say "Bob connects to Alice's ..."
120) 
121) <p>
122) Nell'ultimo passaggio, il rendezvous point notifica al client che la connessione
123) &egrave; stata stabilita con successo. Dopodich&eacute; il client e l'hidden service possono usare
124) i loro circuiti verso il rendezvous point per comunicare tra di loro.
125) Il rendezvous point inoltra semplicemente i messaggi (cifrati end-to-end) dal
126) client al service e viceversa.
127) </p>
128) 
129) <p>

130) Uno dei motivi per non usare l'introduction circuit 
131) per le successive comunicazioni è che nessun singolo relay

132) deve sembrare responsabile per un certo hidden servce. Ecco perché il
133) rendezvous point non viene mai a conoscere l'identità dell'hidden service.
134) </p>
135) 
136) <p>
137) In generale il collegamento completo tra client ed hidden service
138) consiste in 6 relay: 3 di essi vengono scelti dal client, il terzo dei quali
139) &egrave; il endezvous point, gli altri 3 vengono scelti dall'hidden
140) service.
141) </p>
142) 
143) <img alt="Tor hidden service passo sei" src="$(IMGROOT)/THS-6.png" />
144) 
145) <p>

146) Ci sono descrizioni del protocollo hidden service più approfondite