it/hidden-services.wml (82c260a30) - 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 identit6agrave; 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; compresig
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 <a
href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">Petname</a>
progetto 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 descripto e pronto ilrendezvous 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="<svnsandbox>doc/design-paper/tor-design.pdf">Tor design paper</a>
per una descrizione dettagliata e la
<a href="<svnsandbox>doc/spec/rend-spec.txt">rendezvous specification</a>
per il formato dei messaggi.

</div>

#include <foot.wmi>

tor-webwml.git

update italian hidden service protocol webpage -rewording, clarification and links.