git.schokokeks.org
Repositories
Help
Report an Issue
tor-webwml.git
Code
Commits
Branches
Tags
Suche
Strukturansicht:
86929a088
Branches
Tags
bridges
docs-debian
jobs
master
press-clips
tor-webwml.git
it
hidden-services.wml
Now that the design paper was moved back to Subversion, fix links (see tor.git changeset f164a76 and svn revision r21665). Found by katoda
Steven Murdoch
commited
86929a088
at 2010-03-25 17:12:54
hidden-services.wml
Blame
History
Raw
## translation metadata # Based-On-Revision: 17024 # Last-Translator: jan at seul . org #include "head.wmi" TITLE="Tor: il protocollo Hidden Service" <div class="main-column"> <h2>Tor: il protocollo Hidden Service</h2> <hr /> <p> 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à 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>. </p> <p> Affinché 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 <em>introduction point</em> comunicandogli la sua chiave pubblica. Nelle immagini seguenti le linee verdi rappresentano circuiti, e non connessioni dirette. Usando un circuito Tor completo è difficile che qualcuno associ un introduction point con l'indirizzo IP dell'hidden server. Mentre l'introduction point e gli altri conoscono l'identità dell'hidden service (la sua chiave pubblica), essi non devono conoscere la posizione dell'hidden server (il suo indirizzo IP). </p> <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 <p> Secondo passo: l'hidden service costruisce un <em>hidden service descriptor</em>, 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à trovato dai cient che richiederanno XYZ.onion,dove XYZ è un nome di 16 caratteri derivato in modo unico dalla chiave pubblica dell'hidden service. Dopo questo passo, l'hidden service è attivo. </p> <p> Anche se usare un nome del servizio generato automaticamente sembra scomodo, ciò ha uno scopo importante: tutti – compresi gli introduction point, i directory server, e naturalmente i client – 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à un progetto <a href="http://www.skyhunter.com/marcs/petnames/IntroPetNames.html">Petname</a> per i nomi degli hidden service? </p> <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? <p> Terzo passo: quando un client desidera contattare un hidden service, deve conoscere prima il suo undirizzo onion. Dopodiché il client può 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 <em>rendezvous point</em> comunicandogli un one-time secret. </p> <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" <p> Quarto passaggio: una volta presente il descriptor e pronto il rendezvous point, il client costruisce un <em>introduce</em> 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ò collegare l'invio dell'introduce message all'indirizzo IP del client, ed il client rimane così anonimo. </p> <img alt="Tor hidden service passo quattro" src="$(IMGROOT)/THS-4.png" /> <p> 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. </p> <p> A questo punto è 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ì l'indirizzo IP dell'hidden service con una analisi sincronizzata. Questo attacco è stato descritto da Øverlier e Syverson nel loro saggio intitolato <a href="http://freehaven.net/anonbib/#hs-attack06">Locating Hidden Servers</a>. </p> <img alt="Tor hidden service passo cinque" src="$(IMGROOT)/THS-5.png" /> # it should say "Bob connects to Alice's ..." <p> Nell'ultimo passaggio, il rendezvous point notifica al client che la connessione è stata stabilita con successo. Dopodiché 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. </p> <p> Uno dei motivi per non usare l'introduction circuit per le successive comunicazioni è che nessun singolo relay deve sembrare responsabile per un certo hidden servce. Ecco perché il rendezvous point non viene mai a conoscere l'identità dell'hidden service. </p> <p> 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 è il endezvous point, gli altri 3 vengono scelti dall'hidden service. </p> <img alt="Tor hidden service passo sei" src="$(IMGROOT)/THS-6.png" /> <p> Ci sono descrizioni del protocollo hidden service più approfondite di questa. Vedi il <a href="<svnprojects>design-paper/tor-design.pdf">Tor design paper</a> per una descrizione dettagliata e la <a href="<gitblob>doc/spec/rend-spec.txt">rendezvous specification</a> per il formato dei messaggi. </p> </div><!-- #main --> #include <foot.wmi>