Wymaganie, aby każdy użytkownik Tora był przekaźnikiem, pomogłoby w skalowaniu sieci, aby obsłużyć wszystkich naszych użytkowników, a prowadzenie przekaźnika Tora może pomóc w zachowaniu anonimowości.
Jednak wielu użytkowników Tora nie może być dobrymi przekaźnikami - na przykład niektórzy klienci Tora działają zza restrykcyjnych zapór sieciowych, łączą się przez modem lub w inny sposób nie są w stanie przekazywać ruchu.
Świadczenie usług dla tych klientów jest krytyczną częścią zapewniania skutecznej anonimowości dla wszystkich, ponieważ wielu użytkowników Tora podlega tym lub podobnym ograniczeniom, a włączenie tych klientów zwiększa rozmiar zestawu anonimowości.
To powiedziawszy, chcemy zachęcić użytkowników Tora do uruchamiania przekaźników, więc to, co naprawdę chcemy zrobić, to uprościć proces konfigurowania i utrzymywania przekaźnika.
W ciągu ostatnich kilku lat poczyniliśmy ogromne postępy w zakresie łatwego dostosowywania: Tor jest dobry w automatycznym określaniu, czy jest dostępny i jaką przepustowość może zaoferować.
Zanim jednak będziemy mogli to zrobić, musimy wykonać cztery kroki:
Po pierwsze, wciąż musimy lepiej radzić sobie z automatycznym szacowaniem odpowiedniej przepustowości.
Być może przełączenie na transport UDPjest tutaj najprostszą odpowiedzią — która niestety wcale nie jest bardzo prostą odpowiedzią.
Po drugie, musimy popracować nad skalowalnością, zarówno sieci (jak przestać wymagać, aby wszystkie przekaźniki Tora mogły łączyć się ze wszystkimi przekaźnikami Tora), jak i katalogu (jak przestać wymagać, aby wszyscy użytkownicy Tora wiedzieli o wszystkich przekaźnikach Tora).
Zmiany takie jak ta mogą mieć duży wpływ na potencjalną i faktyczną anonimowość.
Szczegółowe informacje można znaleźć w sekcji 5 dokumentu Wyzwania.
Również w tym przypadku pomocny byłby transport UDP.
Po trzecie, musimy lepiej zrozumieć ryzyko związane z umożliwieniem atakującemu wysyłania ruchu przez przekaźnik, podczas gdy inicjujemy również własny anonimowy ruch.
W trzech różnych badaniach opisano sposoby identyfikacji przekaźników w obwodzie poprzez przepuszczanie ruchu przez kandydujące przekaźniki i wyszukiwanie spadków w ruchu, gdy obwód jest aktywny.
Te ataki zatykające sieć nie są tak straszne w kontekście Tora, o ile przekaźniki nigdy nie są również klientami.
Ale jeśli staramy się zachęcić więcej klientów do włączenia funkcji przekaźnika (czy to jako przekaźniki pomostowe, czy jako zwykłe przekaźniki), musimy lepiej zrozumieć to zagrożenie i nauczyć się je łagodzić.
Po czwarte, możemy potrzebować jakiegoś systemu zachęt, aby zachęcić ludzi do przekazywania ruchu innym i/lub do stania się węzłami wyjściowymi.
Oto nasze aktualne przemyślenia na temat zachęt Tor.
Prosimy o pomoc we wszystkich tych sprawach!
Byłoby miło pozwolić operatorom przekaźników mówić takie rzeczy jak reject www.slashdot.org w swoich zasadach wyjścia, zamiast wymagać od nich uczenia się całej przestrzeni adresów IP, która może być objęta witryną (a następnie blokowania innych witryn pod tymi adresami IP).
Jednakże, są dwa problemy.
Po pierwsze, użytkownicy nadal mogli obejść te blokady.
Na przykład, mogą zażądać adresu IP zamiast nazwy hosta, gdy opuszczają sieć Tor.
Oznacza to, że operatorzy nadal musieliby nauczyć się wszystkich adresów IP dla danych miejsc docelowych.
Drugi problem polega na tym, że pozwoliłoby to zdalnym atakującym na cenzurowanie dowolnych stron.
Na przykład, jeśli operator Tor blokuje www1.slashdot.org, a następnie jakiś atakujący zatruwa DNS przekaźnika Tor lub w inny sposób zmienia tę nazwę hosta, aby rozwiązać adres IP głównej witryny z wiadomościami, to nagle ten przekaźnik Tor blokuje witrynę z wiadomościami.
Nie, nie można ufać, że sieć wybierze ścieżkę.
Złośliwe przekaźniki mogą przekierowywać użytkownika przez swoich zmówionych przyjaciół.
Dałoby to przeciwnikowi możliwość obserwowania całego Twojego ruchu od początku do końca.
Byłoby to przydatne z wielu powodów:
Dzięki temu Tor będzie w stanie lepiej obsługiwać nowe protokoły, takie jak VoIP.
Mogłoby to rozwiązać całą potrzebę SOCKSowania (protokołowania pośredniczącego) aplikacji.
Przekaźniki wyjściarównież nie musiałyby alokować wielu deskryptorów plików dla wszystkich połączeń wyjścia.
Zmierzamy w tym kierunku. Niektóre z ciężkich problemów to:
Pakiety IP ujawniają charakterystykę systemu operacyjnego.
Nadal musielibyśmy przeprowadzić normalizację pakietów na poziomie IP, aby powstrzymać ataki typu pobieranie skótu danych TCP.
Biorąc pod uwagę różnorodność i złożoność stosów TCP, a także ataki typu „fingerprinting” na urządzenia, wygląda na to, że naszym najlepszym rozwiązaniem jest dostarczenie własnego stosu TCP w przestrzeni użytkownika.
Strumienie na poziomie aplikacji nadal wymagają oczyszczenia.
Nadal będziemy potrzebować aplikacji po stronie użytkownika, takich jak Torbutton.
Nie będzie to więc tylko kwestia przechwytywania pakietów i anonimizowania ich w warstwie IP.
Niektóre protokoły nadal będą powodować wyciek informacji.
Na przykład, musimy przepisać żądania DNS, aby były one dostarczane do niepowiązanego serwera DNS, a nie do serwera DNS u dostawcy usług internetowych użytkownika; dlatego musimy rozumieć protokoły, które transportujemy.
DTLS (datagram TLS) w zasadzie nie ma użytkowników, a IPsec z pewnością jest duży.
Po wybraniu mechanizmu transportowego, musimy zaprojektować nowy protokół Tor end-to-end, aby uniknąć ataków tagowania i innych potencjalnych problemów z anonimowością i integralnością, teraz, gdy zezwalamy na spadki, ponowne wysyłanie itp.
Zasady wyjścia dla dowolnych pakietów IP oznaczają zbudowanie bezpiecznego systemu wykrywania włamań (IDS).
Nasi operatorzy węzłów mówią nam, że polityka wyjścia jest jednym z głównych powodów, dla których są skłonni uruchomić Tora.
Dodanie IDS do obsługi polityk wyjścia zwiększyłoby złożoność bezpieczeństwa Tora i prawdopodobnie i tak by nie zadziałało, o czym świadczy cała dziedzina dokumentów dotyczących IDS i przeciwdziałania IDS.
Wiele potencjalnych problemów związanych z nadużyciami rozwiązuje fakt, że Tor transportuje tylko prawidłowe strumienie TCP (w przeciwieństwie do dowolnych adresów IP, w tym zniekształconych pakietów i powodzi IP).
Zasady wyjścia stają się jeszcze ważniejsze, gdy jesteśmy w stanie transportować pakiety IP.
Musimy również kompaktowo opisać zasady wyjścia w katalogu Tor, aby klienci mogli przewidzieć, które węzły pozwolą ich pakietom wyjść.
Klienci muszą również przewidzieć wszystkie pakiety, które będą chcieli wysłać w sesji, przed wybraniem węzła wyjściowego!
Wewnętrzne przestrzenie nazw Tor musiałyby zostać przeprojektowane.
Obsługujemy adresy usługi cebulowej „.onion”, przechwytując adresy, gdy są one przekazywane do klienta Tor.
Zrobienie tego na poziomie IP będzie wymagało bardziej złożonego interfejsu między Tor i lokalnym resolwerem DNS.