add italian hidden service protocol page: - add the page; - first translation; - will surely need a second editing.
Jan Reister commited on 2008-07-15 11:25:27
Zeige 1 geänderte Dateien mit 130 Einfügungen und 0 Löschungen.
- it/hidden-services.wml 000000000..33e05756d
| ... | ... |
@@ -0,0 +1,130 @@ |
| 1 |
+## translation metadata |
|
| 2 |
+# Based-On-Revision: 14651 |
|
| 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 |
+Affinché i client possano contattarlo, un hidden service deve anzitutto rendere nota |
|
| 14 |
+la sua esistenza nella rete Tor. Per questo il servizio sceglie alcuni relay |
|
| 15 |
+a caso, stabilisce dei circuiti verso di essi e chiede loro di fungere da |
|
| 16 |
+introduction point comunicandogli la sua chiave pubblica. Nelle figure seguenti |
|
| 17 |
+le linee verdi rappresentano dei circuiti e non delle connessioni. Ciò rende |
|
| 18 |
+impossibile associare gli introduction point con l'indirizzo IP |
|
| 19 |
+dell'hidden service. Questo è importante perché nonostante gli introduction |
|
| 20 |
+point ed altri conoscano l'identità dell'hidden service (la chiave pubblica), |
|
| 21 |
+essi non devono venire a conoscere la posizione dell'hidden service (l'indirizzo IP). |
|
| 22 |
+</p> |
|
| 23 |
+ |
|
| 24 |
+<img alt="Tor hidden service primo passo" src="$(IMGROOT)/THS-1.png" /> |
|
| 25 |
+# maybe add a speech bubble containing "PK" to Bob, because that's what |
|
| 26 |
+# Bob tells to his introduction points |
|
| 27 |
+ |
|
| 28 |
+<p> |
|
| 29 |
+Come secondo passo, un hidden service crea un hidden service descriptor |
|
| 30 |
+contenente gli indirizzi degli introduction point e la propria chiave pubblica, firmando |
|
| 31 |
+il tutto con la sua chiave privata. Esso deposita descrittore su un gruppo di directory |
|
| 32 |
+server, usando ancora una volta un circuito per mascherare il collegamento tra il directory |
|
| 33 |
+server che ospita il descrittore |
|
| 34 |
+e l'indirizzo IP dell'hidden server. Il descrittore verrà trovato |
|
| 35 |
+dai client che richiedono XYZ.onion dove XYZ è un nome di 16 caratteri |
|
| 36 |
+ricavabile in modo univoco dalla chiave pubblica del servizio. Nonostante |
|
| 37 |
+sembri poco pratico usare un nome generato automaticamente per il servizio, esso |
|
| 38 |
+ha uno scopo importante: Tutti – inclusi gli introduction point, |
|
| 39 |
+i directory server, e ovviamente i client – possono verificare che |
|
| 40 |
+stanno parlando proprio con l'hidden service. Dopo questo passo l'hidden service è |
|
| 41 |
+ormai attivo. |
|
| 42 |
+</p> |
|
| 43 |
+ |
|
| 44 |
+<img alt="Tor hidden service passo due" src="$(IMGROOT)/THS-2.png" /> |
|
| 45 |
+# maybe replace "database" with "directory servers"; further: how incorrect |
|
| 46 |
+# is it to *not* add DB to the Tor cloud, now that begin dir cells are in |
|
| 47 |
+# use? |
|
| 48 |
+ |
|
| 49 |
+<p> |
|
| 50 |
+Quando un client desidera contattare un hidden service, deve conoscere prima |
|
| 51 |
+il suo undirizzo onion. Dopodiché il client può iniziare a |
|
| 52 |
+stabilire la connessione scaricandone il descrittore dai directory server. Se |
|
| 53 |
+esiste un descrittore per XYZ.onion (l'hidden service potrebbe essere anche |
|
| 54 |
+offline o essere scomparso da tempo, o l'indirizzo onion potrebbe contenere |
|
| 55 |
+un refuso), il client crea un circuito verso un altro relay scelto a caso e gli |
|
| 56 |
+chiede di fungere da rendezvous point, comunicandogli un segreto monouso. |
|
| 57 |
+</p> |
|
| 58 |
+ |
|
| 59 |
+<img alt="Tor hidden service passo tre" src="$(IMGROOT)/THS-3.png" /> |
|
| 60 |
+# maybe add "cookie" to speech bubble, separated from the surrounded |
|
| 61 |
+# "IP1-3" and "PK" |
|
| 62 |
+ |
|
| 63 |
+<p> |
|
| 64 |
+Una volta stabilito il rendezvous point, il client crea un introduce |
|
| 65 |
+message (cifrato con la chiave pubblica dell'hidden service) contenente |
|
| 66 |
+l'indirizzo del rendezvous point ed il segreto monouso. Il client invia |
|
| 67 |
+questo messaggio a uno degli introduction point, chiedendogli di consegnarlo |
|
| 68 |
+all'hidden service. La comunicazione avviene sempre tramite un circuito, in modo |
|
| 69 |
+che nessuno possa collegare l'invio dell'introduce message all'indirizzo IP |
|
| 70 |
+del client, assicurando così l'anonimato del client. |
|
| 71 |
+</p> |
|
| 72 |
+ |
|
| 73 |
+<img alt="Tor hidden service passo quattro" src="$(IMGROOT)/THS-4.png" /> |
|
| 74 |
+ |
|
| 75 |
+<p> |
|
| 76 |
+L'hidden service decifra l'introduce message del client e scopre l'indirizzo |
|
| 77 |
+del rendezvous point ed il segreto monouso contenuto. Il service |
|
| 78 |
+crea un circuito verso il rendezvous point e gli invia il segreto monouso in |
|
| 79 |
+un rendezvous message. |
|
| 80 |
+</p> |
|
| 81 |
+ |
|
| 82 |
+<p> |
|
| 83 |
+A questo punto è molto importante che l'hidden service continui ad |
|
| 84 |
+usare lo stesso gruppo di guard node per creare nuovi circuiti. Altrimenti un ataccante |
|
| 85 |
+potrebbe gestire un proprio nodo e forzare un hidden service a creare un numero arbitrario |
|
| 86 |
+di circuiti sperando che prima o poi il relay corrotto venga scelto come nodo |
|
| 87 |
+di ingresso, venendo a conoscere così l'indirizzo IP dell'hidden service con una analisi sincronizzata. Questo |
|
| 88 |
+attacco è stato descritto da Øverlier e Syverson nel loro saggio intitolato |
|
| 89 |
+Locating Hidden Servers. |
|
| 90 |
+</p> |
|
| 91 |
+ |
|
| 92 |
+<img alt="Tor hidden service passo cinque" src="$(IMGROOT)/THS-5.png" /> |
|
| 93 |
+# it should say "Bob connects to Alice's ..." |
|
| 94 |
+ |
|
| 95 |
+<p> |
|
| 96 |
+Nell'ultimo passaggio, il rendezvous point notifica al client che la connessione |
|
| 97 |
+è stata stabilita con successo. Dopodiché il client e l'hidden service possono usare |
|
| 98 |
+i loro circuiti verso il rendezvous point per comunicare tra di loro. |
|
| 99 |
+Il rendezvous point inoltra semplicemente i messaggi (cifrati end-to-end) dal |
|
| 100 |
+client al service e viceversa. |
|
| 101 |
+</p> |
|
| 102 |
+ |
|
| 103 |
+<p> |
|
| 104 |
+Uno dei motivi per non usare la connessione creata inizialmente attraverso |
|
| 105 |
+l'introduction point per le successive comunicazioni è che nessun singolo relay |
|
| 106 |
+deve sembrare responsabile per un certo hidden servce. Ecco perché il |
|
| 107 |
+rendezvous point non viene mai a conoscere l'identità dell'hidden service. |
|
| 108 |
+</p> |
|
| 109 |
+ |
|
| 110 |
+<p> |
|
| 111 |
+In generale il collegamento completo tra client ed hidden service |
|
| 112 |
+consiste in 6 relay: 3 di essi vengono scelti dal client, il terzo dei quali |
|
| 113 |
+è il endezvous point, gli altri 3 vengono scelti dall'hidden |
|
| 114 |
+service. |
|
| 115 |
+</p> |
|
| 116 |
+ |
|
| 117 |
+<img alt="Tor hidden service passo sei" src="$(IMGROOT)/THS-6.png" /> |
|
| 118 |
+ |
|
| 119 |
+<p> |
|
| 120 |
+Ci sono descrizioni del protocollo hidden service pi&gugrave; approfondite |
|
| 121 |
+di questa. Vedi il |
|
| 122 |
+<a href="<svnsandbox>doc/design-paper/tor-design.pdf">Tor design paper</a> |
|
| 123 |
+per una descrizione dettagliata e la |
|
| 124 |
+<a href="<svnsandbox>doc/spec/rend-spec.txt">rendezvous specification</a> |
|
| 125 |
+per il formato dei messaggi. |
|
| 126 |
+</p> |
|
| 127 |
+ |
|
| 128 |
+ </div><!-- #main --> |
|
| 129 |
+ |
|
| 130 |
+#include <foot.wmi> |
|
| 0 | 131 |