Za sprawą normalnych tradycyjnych stron w sieci Tor zrobiło się ostatnio głośno z powodu Facebooka. Nie dość, że Facebook wystawił stronę oficjalnie do sieci Tor pod adresem .onion, to adres był ciekawy, a całość jest dostępna po HTTPS, czyli w wersji szyfrowanej[1]. Mniejsza o powody, dla których to uczynili. Wydaje się, że nie tyle chodziło im o anonimowość użytkowników (nie miejcie złudzeń), co o ich prywatność i bezpieczeństwo (ukrycie lokalizacji). Plus przy okazji rozwiązali sobie problem false positives przy wykrywaniu włamań, które mieli przy użytkownikach korzystających z tradycyjnych exit node[2]. Będzie zatem o własnej stronie w sieci Tor.
Źródło: https://media.torproject.org/image/official-images/2011-tor-logo-flat.svg
Tak czy inaczej, wygląda, że Tor został dostrzeżony przez dużych w z właściwej perspektywy, czyli po prostu jako medium transmisji, a nie odrębna sieć, używana przez złoczyńców[3]. Myślę, że można spodziewać się kolejnych naśladowców.
Warto zauważyć, że to co zrobił Facebook to nie jest typowy hidden service w sieci Tor. W typowym chodzi o ukrycie tożsamości właściciela, miejsca hostowania itp. Czyli masa pracy poświęcona uszczelnianiu systemu i serwera WWW, która nie jest przedmiotem tego wpisu. Na stronie projektu Tor też się tym nie zajmują, ale zainteresowani znajdą tam ogólne wskazówki. Tu przeciwnie – wszystko jest dostępne, a tożsamość jest potwierdzona certyfikatem SSL, czyli wersja znacznie łatwiejsza w wykonaniu.
I właśnie takim przypadkiem zajmę się w tym wpisie. Całość opisana jest dokładnie na stronie projektu Tor. Widzę jednak, że pojawiają się pytania jak to zrobić, więc zamieszczę wersję skróconą i uproszczoną. Tak naprawdę całość sprowadza się do dwóch linii w pliku konfiguracyjnym. Zakładam, że Tor jest już skonfigurowany jako relay node lub bridge node. I nawet nie do napisania, tylko do odhashowania/edycji.
Przede wszystkim w pliku konfiguracyjnym[4] szukamy sekcji dotyczącej hidden services, zaczynającej się od linii:
############### This section is just for location-hidden services ###
Następnie odhashowujemy/edytujemy dwie linie:
HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 IP_SERWERA_WWW:80
Pierwsza musi wskazywać na katalog, który musi mieć prawa odczytu i zapisu dla użytkownika na którym działa demon Tor. W Debianie wystarczy odhashować.
Druga to wskazanie który port chcemy przekierowywać i na jaki adres oraz port. IPv4 działa na pewno, IPv6 nie udało mi się skłonić do działania. Jedyna zmiana, czy też wymóg konfiguracji po stronie serwera WWW, jest taki, że musi on pozwalać na dostęp do zasobów po IP, bez podania domeny (vhosta)[5].
Następnie należy zrestartować demona Tor i… gotowe. Pozostało jeszcze tylko sprawdzić, jaki adres ma nasz hidden service:
cat /var/lib/tor/hidden_service/hostname
Potem można już tylko zweryfikować działania serwisu za pośrednictwem adresu .onion. Jeśli nie mamy pod ręką normalnego dostępu do Tora, można posiłkować się bramką Tor2web.
[1] I całe szczęście, bo przypominam, że Tor nie szyfruje użycie Tora nie oznacza automatycznie szyfrowania danych. Co więcej, każdy węzeł, ma możliwość przechwycenia całej (co prawda zaszyfrowanej) transmisji. A exit node, jest w stanie podsłuchać nieszyfrowaną transmisję do końcowego hosta.
[2] Więcej w tym wpisie (ANG).
[3] Nie ukrywajmy, typowy użytkownik Tora kojarzył się do tej pory z nielegalnymi działaniami.
[4] W Debianie jest to /etc/tor/torrc, pewnie w Ubuntu i innych pochodnych jest analogicznie.
[5] Tu uwaga dla chcących stawiać bramki hidden service – z punktu widzenia zewnętrznego serwisu (i tylko jego, i tylko w przypadku połączeń poprzez adres .onion) mój klient Tor IP jest teraz exit node! W przypadku nadużyć za pośrednictwem sieci Tor i adresu .onion może się to skończyć wizytą policji. W przypadku serwisów, których nie jesteśmy właścicielami bezwzględnie należy mieć zgodę właściciela serwisu.
Ciekawe jak wygląda procedura otrzymania certyfikatu dla adresu .onion (nie mowie tu o jakis self-signed), domyslam sie, ze u tradycyjnych wystawcow nie istnieje. Widocznie FB ma na tyle duza sile przetargowa albo sam ma w swojej strukturze zaufanego wystawce, ze mu wystawia/moze sobie wystawic.
@nbb: Nie mam pojęcia. Jak patrzę na procedury dla klienta końcowego u niektórych wystawców SSL, to może sobie wpisać co mu się żywnie podoba w certyfikacie jako nazwę domeny. Nawiasem, ostatnio trochę nowych domen TLD doszło, więc jest spora szansa, że i .onion walidatory przepuszczą…
„I całe szczęście, bo przypominam, że Tor nie szyfruje danych, co więcej, każdy węzeł, a w szczególności exit node, jest w stanie podsłuchać transmisję.”
Bzdury. Tor szyfruje połączenia pomiędzy węzłami i TYLKO exit node jest w stanie podsłuchać transmisję.
@rr Racja, za duży skrót myślowy i bzdura wyszła. Korzystanie z Tor nie zapewnia szyfrowania danych. Między węzłami są szyfrowane (i to wielowarstwowo, jak dopytałem), ale nie oznacza to automatycznie szyfrowania całej transmisji. Exit node ma trywialny dostęp do nieszyfrowanego strumienia. Pozostałe węzły mogą przechwycić całą transmisję, która oparta jest o openssl. Patrz niedawny heartbleed. Jest lepiej, niż myślałem, bo są warstwy, ale w przypadku globalnego błędu w openssl nie na wiele się to zda, tym bardziej, że węzły uruchomione są na zbliżonym środowisku (wersje Tora, zapewne wersje openssl) i szansa, że błąd będzie dotyczył przytłaczającej większości node’ów jest spora.
Poprawiłem w treści. Mam nadzieję, że teraz nie ma zastrzeżeń.
Na pewno nie chodziło Facebookowi o anonimowość użytkowników, bo w ramach portalu i tak nadal jesteś pod imieniem i nazwiskiem – jeśli oczywiście takowe podałeś.
Co do Tora to dla mnie to dość nowe zjawisko, więc dzięki za przydatne porady.