Kilka dni temu dowiedzieliśmy się, że NSA prawdopodobnie jest w stanie skutecznie atakować wiele rodzajów szyfrowania, stosowanych w sieci. Jak się okazuje, jedną z możliwych ofiar tych praktyk mogą być również połączenia w anonimowej sieci TOR.
Rob Graham, prezes firmy Errata Security, uruchomił węzeł wyjściowy sieci TOR, dzięki czemu mógł analizować statystyki otrzymywanych połączeń. Sprawdził, jak wygląda szyfrowanie połączeń przychodzących do jego węzła. Okazało się, że spośród 22,920 zarejestrowanych połączeń, 76% korzystało z protokołu wymiany kluczy szyfrujących Diffego-Hellmana z kluczem o długości 1024 bitów. W czym jednak problem, jeśli do tej pory nie opublikowano udanego ataku na klucz o tej długości?
Co potrafi złamać NSA
Główną obawą Grahama są niedawne rewelacje dotyczące wysiłków NSA w zakresie analizowania zaszyfrowanego ruchu sieciowego. Biorąc pod uwagę budżet 10 miliardów dolarów i 35 tysięcy osób zatrudnionych do łamania szyfrów, można podejrzewać, że klucze DHA o długości 1024 bitów mogą być łamane w czasie bliskim rzeczywistego. Nawet zakładając, że NSA nie udało się dokonać żadnego przełomu w zakresie samej technologii łamania szyfrowania, dysponuje ona budżetem, który pozwala na zbudowanie dostatecznie szybkich i wydajnych urządzeń, łamiących klucze z użyciem ogromnej mocy obliczeniowej.
Problem rozwiązany, tylko implementacja wolno postępuje
Na szczęście problem został już zauważony przez twórców oprogramowania, z którego korzysta sieć TOR. Już wersja 0.2.4.8, wydana w styczniu tego roku, umożliwia użycie szyfrowania opartego o krzywe eliptyczne (curve25519), uznawane za bezpieczniejsze od poprzednich rozwiązań. Niestety statystyki pokazują, że obecnie tylko 10% serwerów sieci TOR korzysta z wersji 0.2.4.x. Choć twórcy sieci zachęcają do migracji do najnowszej wersji, to wiele repozytoriów (w tym popularnych dystrybucji Linuxa) ciągle domyślnie instaluje wersję 0.2.3.x, ponieważ wersja 0.2.4.x ma status „alpha”.
Kto za to wszystko płaci?
Do problemów sieci TOR doliczyć można także informację o tym, że 60% z 2-milionowego rocznego budżetu organizacji ją wspierającej pochodzi ze skarbca rządu USA. Deweloperzy zarzekają się, że prędzej polegną, niż wprowadzą do kodu tylną furtkę, jednak jak nauczyły nas doświadczenia ostatnich dni, wiemy, że tylne furtki mogą mieć bardzo subtelną formę – jak chociażby lekko niedomagające generatory liczb losowych. Pozostaje mieć nadzieję, że w projekcie, który regularnie monitoruje wiele osób o wysokim poziomie paranoi, tego typu modyfikacja została by szybko zidentyfikowana.
PS. A liczba użytkowników dalej rośnie – wygląda na to, że botnet Sefnit/Mevade/SBC ma już 3 miliony zombie.
Komentarze
Obecnie jak dodasz węzeł (bridge lub relay) to od razu jesteś na publicznej liście.
Niech dadzą opcję ukrywania swojego węzła z publicznej listy.
Jest parametr #PublishServerDescriptor 0, ale gdy będzie aktywny to nie przykłada się do polepszenia sieci.
Przydałoby się sporo ukrytych, które wymieniają ruch i nie są na publicznej liście.
Ciekawa teoria, jak mają nie być na publicznej liście i nawiązywać połączenia z innymi ? Poza tym, jak robisz bridge to nie jesteś na liście „publicznej” tylko na stronie rozdającej mostki (po jednym!). A jak zmienisz #PublishServerDescriptor 0 to możesz zrobić prywatny mostek dla siebie i znajomych, przydatny jak jedziesz do Chin w interesach.
To jest bardzo ciekawa teoria powiązana z praktyką.
Zrób sobie BridgeRelay 1 oraz PublishServerDescriptor 0.
Wtedy jesteś niewykorzystywany w sieci tor czyli bezużyteczny.
Nawet jak zrobisz tylko PublishServerDescriptor 0 i chcesz wymieniać ruch wewnętrzny to i tak nie jesteś wykorzystywany.
W praktyce nie wymieniasz ruchu jak nie jesteś na publicznej liście.
Na stronie https://bridges.torproject.org/bridges dostałem 9 adresów, a nie jeden.
No i co z tego ? Chcesz żeby serwer skanował randomowe ip i porty w poszukiwaniu innego serwera ? musi ściągnąć listę która zawsze będzie publiczna, jak sobie wyobrażasz nawiązywanie połączenia ?
Chcę, żeby mój węzeł wymeniał ruch z innym węzłem, ale tak żeby mój węzeł nie był publiczny.
Czy to jest zrozumiałe?
Nie potrzeba do tego skanowania.
Lista nie musi być publiczna.
Serwer B daje info mojemu serwerowi A, że niepubliczne serwery C i D chcą wymieniać ruch.
Serwer C i D będzie znany tylko dla A i B.
Ma ktoś linka do paczek .deb nowego tor’a dla Debiana?
archlinux -> w AUR wersja tor to 0.2.5. Tak dla informacji.
„(…)który regularnie monitoruje wiele osób o wysokim poziomie paranoi, tego typu modyfikacja została by szybko zidentyfikowana.”
Paranoja jest chorobą. Rozumiem więc, że tylko chorzy ludzie potrafią zadbać o pełne bezpieczeństwo oprogramowania. Zatem komuś powinno być głupio. Z jednej strony wymaga się profesjonalizmu i kategoryzuje lepszy-gorszy, a z drugiej tych najlepszych nazywa się ludźmi chorymi.
Takim „paranoikom” to pewnie mniej płaci się w firmach, bo oni po prostu tacy są. Prawie jak niepełnosprawni, więc respekt zdecydowanie mniejszy.
wiesz gdzie ta wersje 2.4.8 znalezc?
https://www.torproject.org/projects/torbrowser.html.en
tu jej nie ma. z wyszukiwarki tylko odsylacze do dyskusji o wersji.
? .(
dziekuje.
Wszystkie wersje, w tym 2.4.8 masz tutaj:
https://archive.torproject.org/tor-package-archive/
Obecnie najnowsza niestabilna jest 2.4.17 (https://www.torproject.org/dist/tor-0.2.4.17-rc.tar.gz).
2.3.25 to obecnie najnowsza wersja stabilna.
Hmm, może by zrobić szyfrową bombę dekompresyjną, ciekawe jak NSA by z nią sobie poradziła ;)