pl/hidden-services.wml (2a7f3da1b) - tor-webwml.git

hidden-services.wml

## translation metadata
# Based-On-Revision: 16828
# Translation-Priority: 3-low
# Last-Translator: bogdandr _at_op.pl

#include "head.wmi" TITLE="Tor: Protokół Usług Ukrytych" CHARSET="UTF-8"

<h2>Tor: Protokół Usług Ukrytych</h2>
<hr />

Usługa ukryta musi ogłosić swoje istnienie w sieci Tora zanim klienci będą mogli
się z nią skontaktować. W tym celu usługa wybiera losowo kilka przekaźników
sieci, tworzy do nich obwody i prosi, by stały się one punktami przedstawiającymi
ją, poprzez przekazanie im swojego klucza publicznego. Na poniższych obrazkach linki
zielone to linki obwodu, a nie połączenia bezpośrednie. Uniemożliwia to komukolwiek
powiązanie punktów przedstawiających z adresem IP usługi ukrytej. Jest to ważne, gdyż
pomimo tego, że punktom przedstawiającym i innym przekazywana jest tożsamość
usługi ukrytej (klucz publiczny), to nie mogą one znać tożsamości serwera tej usługi
(adresu IP).

<img alt="Usługi ukryte Tora, krok 1" src="$(IMGROOT)/THS-1.png" />
# maybe add a speech bubble containing "PK" to Bob, because that's what
# Bob tells to his introduction points

W kolejnym kroku usługa ukryta tworzy deskryptor usługi ukrytej, zawierający adresy jej
punktów przedstawiających i je klucz publiczny, oraz podpisuje go swoim kluczem
prywatnym. Deskryptor ten jest zachowywany na kilku serwerach katalogowych, ponownie
z użyciem obwodu ukrywającego powiązanie między zapisywaniem deskryptora a adresem
IP usługi ukrytej. Deskryptor ten będzie znajdowany przez klientów żądających
połączenia z XYZ.onion, gdzie XYZ jest składającą się z 16 znaków nazwą
w sposób jednoznaczny otrzymaną z klucza publicznego usługi ukrytej.
Mimo iż używanie nazwy wygenerowanej automatycznie wydaje się niepraktyczne,
ma to ważny cel: wszyscy -- łącznie z punktami przedstawiającymi, serwerami katalogowymi,
i oczywiście klientami -- mogą sprawdzić, że faktycznie łączą się z tą usługą ukrytą.
 Po wykonaniu tego kroku, usługa ukryta jest uruchomiona.

<img alt="Usługi ukryte Tora, krok 2" 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?

Klient chcący połączyć się z usługą ukrytą musi najpierw poznać jej adres onion.
Po zrobieniu tego, klient może zacząć połączenie od pobrania deskryptora z
serwerów katalogowych. Jeśli istnieje deskryptor dla XYZ.onion (usługa ukryta
może być offline, dawno nieaktualna lub może być błąd w adresie), klient tworzy
obwód do innego losowo wybranego przekaźnika i prosi go, by stał się punktem
spotkania, przekazując mu jednorazowy klucz.

<img alt="Usługi ukryte Tora, krok 3" src="$(IMGROOT)/THS-3.png" />
# maybe add "cookie" to speech bubble, separated from the surrounded
# "IP1-3" and "PK"

Po ustawieniu punktu spotkania, klient tworzy wiadomość początkową (zaszyfrowaną
kluczem publicznym usługi ukrytej), zawierającą adres punku spotkania i ten
sam klucz jednorazowy. Klient wysyła tę wiadomość do jednego z punktów
przedstawiających z prośbą o dostarczenie jej do usługi ukrytej. Tu także
cała komunikacja odbywa się przez obwody, więc nikt nie może powiązać wysłanie
wiadomości początkowej do adresu IP klienta, zapewniając mu anonimowość.

Usługa ukryta odszyfrowuje wiadomość początkową klienta i znajduje adres punktu
spotkania wraz z kluczem jednorazowym. Usługa tworzy obwód do punktu spotkania
i wysyła do niego klucz jednorazowy w wiadomości spotkania.

W tym momencie ważny jest fakt, że usługa ukryta trzyma się ciągle tych samych
węzłów-strażników w czasie tworzenia nowych obwodów. W innym przypadku napastnik
mógłby prowadzić własny przekaźnik sieci i zmusić usługę ukrytą do tworzenia
dowolnej liczby obwodów z nadzieją, że jego przekaźnik zostałby wybrany na
punkt wejścia i poznałby adres IP usługi ukrytej poprzez analizę czasów.
Ten atak został opisany przez &Oslash;verlier'a i Syversona w ich dokumencie
pod tytułem Znajdowanie Usług Ukrytych (Locating Hidden Services).

<img alt="Usługi ukryte Tora, krok 5" src="$(IMGROOT)/THS-5.png" />
# it should say "Bob connects to Alice's ..."

W ostatnim kroku punkt spotkania powiadamia klienta o pomyślnym nawiązaniu połączenia.
Po tym fakcie zarówno klient, jak i usługa ukryta mogą używać swoich obwodów do
punktu spotkania do łączności między sobą. Punkt spotkań po prostu przekazuje
wiadomości (zaszyfrowane na całej trasie od odbiorcy do nadawcy) od klienta do
usługi ukrytej i na odwrót.

Jednym z powodów niekorzystania z uprzednio stworzonego połączenia poprzez
punkt przedstawiający jest to, że żaden węzeł nie powinien wydawać się
być odpowiedzialnym za daną usługę ukrytą. To dlatego punkty spotkania
nigdy nie poznają tożsamości usługi ukrytej.

W ogólnym przypadku, połączenia między klientem a usługą ukrytą składa się z
6 przekaźników: 3 z nich zostały wybrane przez klienta, przy czym trzeci jest
punktem spotkania, a pozostałe 3 zostały wybrane przez usługę ukrytą.

Istnieją bardziej szczegółowe opisy protokołu usług ukrytych niż ta strona.
Przeczytaj <a href="<svnsandbox>doc/design-paper/tor-design.pdf">dokument projektowy Tora</a>
zawierający dogłębny opis projektu, oraz
<a href="<svnsandbox>doc/spec/rend-spec.txt">specyfikację spotkań (rendezvous)</a>,
zawierającą formaty wiadomości.

</div>

#include <foot.wmi>

tor-webwml.git

Mainetance/polish translation update.