it/hidden-services.wml (9829567ed) - tor-webwml.git

hidden-services.wml

## translation metadata
# Revision: $Revision: 22359 $
# Translation-Priority: 3-low
#include "head.wmi" TITLE="Tor: Hidden Service Protocol" CHARSET="UTF-8"
<div class="main-column">

<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).

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

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?

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

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.

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

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>.

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

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

updated translations for the website