SS to oryginał, SSR to wersja firm trzecich, wywodząca się z oryginału, kompatybilna z oryginalnym protokołem i posiada więcej funkcji kamuflażowych (protokół i dezorientacja) niż oryginał.
W Internecie toczy się też wiele dyskusji na temat SSR, zarówno za, jak i przeciw, ale także dla zwykłych użytkowników. Niezależnie od tego, czy to SS, czy SSR, obecnie może pomóc ci normalnie przeskoczyć mur.
Jeśli chodzi o to, którą wersję klienta pobierzesz, wszystko zależy od tego, czy na serwerze zakupionego konta SS jest zainstalowany SS czy SSR. Najbardziej oryginalna funkcja SS może być używana niezależnie od pobranego klienta, ale jeśli chcesz korzystać z funkcji SSR (protokół i zamieszanie), musisz pobrać klienta SSR.
Ale nie martw się, wszystkie węzły, które udostępniamy, wspierają kompatybilność SS i SSR. Zaleca się stosowanie SSR. Szybciej, by uniknąć harmonizacji!
Jakiś czas temu było dużo szumu wokół Shadowsocks, a ostatnio widać, że wielu nowicjuszy zostało zainteresowanych tzw. "Shadowsocks Enhanced" (ShadowsocksR). Jako amatorski twórca implementacji Shadowsocks w C++/Qt, chciałbym krótko wyrazić swoją opinię na temat tych dwóch smażonych kurczaków.
ShadowsocksR
Nie wiem, czy twórca ma doświadczenie lub zespół, ale wiem, że autor zamknął oprogramowanie dla klienta C# Shadowsocks do jego dodatkowego rozwoju, naruszając GPL. Nie będziemy tu mówić o innych czynnikach, faktem jest, że GPL jest bardzo jasne i jasno, naruszenie przepisów to naruszenie. Jednak autor następnie udostępnił kodowi jako open source, co można uznać za koniec incydentu i nie ma potrzeby dalszego badania.
Sytuacja zmieniła się po tym, jak Clowwindy opróżnił swój skład kodów Shadowsocks. Poniżej znajduje się tylko lista faktów:
Autor ShadowsocksR powiedział, że chce zacząć od zera, by napisać nowe narzędzie proxy niezwiązane z shadowsocks i nie będzie już aktualizować ShadowsocksR
Dwa, trzy dni później nakazano usunięcie ShadowSocks, a oryginalny projekt Shadowsocks praktycznie zniknął
Autor ShadowsocksR powiedział, że oryginalny protokół shadowsocks był wadliwy (omówiony w następnej sekcji) i wrócił do skupienia
Autor ShadowsocksR założył grupę Google+ i zaktualizował kod związany z ShadowsocksR
Bezpieczeństwo Shadowsocks
Zacznijmy teraz od opisu twierdzenia autora ShadowsocksR, że wadą protokołu Shadowsocks jest to, że długość IV wynosi w większości przypadków 16 bajtów. Ta druga połowa jest poprawna, wiele algorytmów szyfrowania używa IV o długości 16 bajtów (szczególnie popularne AES i RC4-MD5), więc co z tego? Nie wprowadza to tzw. "wad" z następujących powodów:
IV każdego połączenia TCP na etapie uścisku ręki jest generowany losowo, a nie obliczany na podstawie hasła, więc IV jest nieprzewidywalny.
Bez klucza, nawet jeśli ta część IV zostanie przechwycona, szyfrogram nie może zostać odszyfrowany. Każde nowe połączenie TCP korzysta z losowo generowanego IV, czyli dane przechwycone z różnych połączeń TCP mają niewiele wspólnego. Deszyfrowanie szyfru wymaga zarówno poprawnego IV, jak i szyfru, a każde połączenie nie ma żadnych cech dotyczących szyfru.
Większość IV ma długość 16 bajtów, co jest możliwą kombinacją 256 do potęgi 16, i niemożliwe jest brutalne pęknięcie, gdy wszystkie IV są takie same, nie mówiąc już o dodaniu drugiego punktu.
Według podejścia ShadowsocksR dodanie tzw. nagłówka obfuskacji przed pierwszym połączeniem jest bezużyteczne, jego własne cechy są oczywiste i nie zmienia istoty późniejszego IV ani stałej długości. Ponieważ czwarty bajt pokazuje długość losowo wypełnionych danych, o ile pominiesz poprzedni stos podczas wykonywania tzw. "sondowania", nadal możesz przechwycić IV. I jak mówiłem kilka punktów temu, to bezużyteczne, jeśli trafisz na ten losowy IV. Jeśli jest używany do wykrywania, stałą pierwszą wersją logo jest nagi element wysyłany do identyfikacji.
Autor ShadowsocksR obecnie udostępnia skrypt aktywnego wykrywania, który pozwala wykryć, czy serwer używa shadowsocks, a według aktualnych raportów testowych online, wskaźnik powodzenia nie jest niski (ale nie 100%). W tym kontekście Clowwindy już wprowadziło automatyczne banowanie w oryginalnej wersji, automatycznie blokujące te złośliwe adresy IP. Właśnie dodałem łatkę do libQtShadowsocks i ta łatka blokuje wykrywanie tej metody, która zwraca losowe ciągi o losowej długości zgodnie z losowym prawdopodobieństwem.
Jednak nie oznacza to, że protokół Shadowsocks jest doskonały, lecz że "rozwiązanie" ShadowsocksR jest krzywe, ponieważ jego fokus jest krzywy. Mój osobisty pomysł to wykorzystanie kluczy publicznych i kluczy prywatnych do poprawy bezpieczeństwa, choć nie jest to zbyt przyjazne dla początkujących, ale bezpieczeństwo zostanie poprawione, a charakterystyka zmniejszona (nie trzeba wysyłać IV na etapie uścisku dłoni), a protokół shadowsocks musi rozwijać się w kierunku bezpieczeństwa CCA.
Aktualizacja 05-wrz 2015
Gdy błąd nagłówka (nie może zostać rozwiązany) zostanie znaleziony, do listy błędnego IV i IP zostanie dodany błędny IV i IP, jeśli IV już istnieje na liście nieudanych IV lub IP już na liście nieudanych IP, adres IP, który wysłał żądanie połączenia, zostanie dodany na czarną listę, a adres IP na czarnej liście bezpośrednio odrzuci połączenie. Aby uzyskać najnowsze informacje na temat antywykrywania, prosimy zająć się tym numerem, a ten artykuł nie zaktualizuje środków zaradczych przeciwko wykrywaniu.
Aktualizacja 06-wrz 2015
Ten artykuł chce po prostu powiedzieć, żebyś nie martwił się zbytnio o bezpieczeństwo Shadowsocks, obecny protokół nie ma jeszcze poważnych luk, a serwery głównych portów również są aktualizowane, aby naprawić potencjalne zagrożenia. Dobrze komunikowałem się też z autorem ShadowsocksR i minie jeszcze trochę czasu, zanim pojawi się biała lista.
Aktualizacja: 24-wrz 2015
Bezpieczeństwo Shadowsocks opisane w tym artykule odnosi się bardziej do bezpieczeństwa serwera, a obecny protokół niesie ryzyko narażenia serwera na wykrywanie siłą i zablokowania przez zapory sieciowe (choć koszt wykrycia jest bardzo wysoki). Nie należy się martwić o bezpieczeństwo przesyłanej treści, wszystkie są przemysłowe algorytmy szyfrowania o wysokiej wytrzymałości (z wyjątkiem RC4 i TABLE), a złamanie przesyłanej treści jest niemal niemożliwe.
Aktualizacja 18 listopada 2015
Shadowsocks poprawił swoje zabezpieczenia wobec CCA, dodając pojedynczą weryfikację, a główne porty już zakończyły swoje wsparcie. Warto podkreślić, że celem Shadowsocks nie jest 100% wolne od błędów czy 100% odporne na kule, lecz zapewnienie lekkiego i szybkiego połączenia, jednocześnie sprawiając, że główne metody ataku są zbyt kosztowne w implementacji.
|
Opublikowano 10.11.2017 12:41:35
|
|
|
