SS je originál, SSR je verze třetí strany odvozená od originálu, kompatibilní s původním protokolem a má více maskovacích funkcí (protokol a zmatení) než originál.
Na internetu se také hodně diskutuje o SSR, a to jak pro, tak proti, ale pro běžné uživatele. Ať už jde o SS nebo SSR, může vám to pomoci přelézt zeď normálně v současnosti.
Co se týče verze klienta, kterou stáhnete, záleží na tom, zda je na serveru SS účtu, který jste si zakoupili, nainstalováno SSR nebo SSR. Nejoriginálnější funkce SS lze použít bez ohledu na to, který klient je stažen, ale pokud chcete používat funkce SSR (protokol a zmatení), musíte stáhnout SSR klienta.
Ale nebojte se, všechny uzly, které poskytujeme, podporují kompatibilitu SS a SSR. Doporučuje se používat SSR. Rychleji, aby se zabránilo harmonizaci!
Před časem bylo kolem Shadowsocks hodně rozruchu a v poslední době je jasné, že velké množství začátečníků bylo přitahováno takzvanými "Shadowsocks Enhanced" (ShadowsocksR). Jako amatérský vývojář implementace Shadowsocks v C++/Qt bych rád krátce vyjádřil svůj názor na tato dvě smažená kuřata.
ShadowsocksR
Nevím, jestli má vývojář za tím zkušenosti nebo tým, ale vím, že autor uzavřel Shadowsocks C# klienta pro sekundární vývoj v rozporu s GPL. Nebudeme zde mluvit o dalších faktorech, faktem je, že GPL je jasně a černobílá, porušení je porušení. Autor však pak zpřístupnil kódovou základnu jako opensource, což lze považovat za konec incidentu, a není třeba ji dále rozvíjet.
Situace se změnila poté, co Clowwindy vyprázdnilo svůj úložiště kódů Shadowsocks. Následuje pouze seznam faktů:
Autor ShadowsocksR uvedl, že chce začít od nuly a napsat nový proxy nástroj, který nebude souviset se shadowsocks, a už nebude aktualizovat ShadowsocksR
O dva nebo tři dny později bylo nařízeno smazat ShadowSocks a původní projekt ShadowSocks prakticky zmizel
Autor ShadowsocksR uvedl, že původní protokol shadowsocks byl chybný (o čem bude diskutováno v další části) a vrátil se k zaměření
Autor ShadowsocksR založil skupinu Google+ a aktualizoval kód související se ShadowsocksR
Bezpečnost Shadowsocks
Nyní začněme popisem tvrzení autora ShadowsocksR, že chybou protokolu Shadowsocks je, že délka IV je ve většině případů 16 bajtů. Druhá polovina je správná, mnoho šifrovacích algoritmů používá IV dlouhé 16 bajtů (zejména populární AES a RC4-MD5), a co na tom? To nepřináší takzvané "vady" z následujících důvodů:
IV každého TCP spojení ve fázi handshake je generován náhodně, nikoli vypočítán z hesla, takže IV je nepředvídatelný.
Bez klíče, i když je tato část IV zachycena, šifrovaný text nelze dešifrovat. A každé nové TCP spojení používá náhodně generovaný IV, tedy data zachycená z různých TCP spojení mají málo společného. Dešifrování šifrovaného textu vyžaduje jak správné IV, tak šifru, a jakékoli spojení nemá žádné charakteristiky šifry.
Většina IV je dlouhá 16 bajtů, což je možná kombinace 256 na mocninu 16, a není možné hrubou silou crackovat, když jsou všechna IV stejná, natož přidat druhý bod.
Podle přístupu ShadowsocksR je zbytečné přidávat tzv. obfuskační hlavičku před prvním spojením, její vlastní charakteristiky jsou zřejmé a vůbec to nemění podstatu pozdějšího IV nebo pevné délky. Protože čtvrtý bajt vám ukáže délku náhodně vyplněných dat, pokud při provádění tzv. "soningu" přeskočíte předchozí hromádku, stále můžete IV zachytit. A jak jsem říkal před pár body, je to k ničemu, pokud dostanete tuto náhodnou infuzi. Pokud je použito k detekci, pevná první verze loga je nahý prvek zaslaný k identifikaci.
Autor ShadowsocksR v současnosti poskytuje skript pro aktivní detekci, který lze použít k detekci, zda server používá shadowsocks, a podle aktuálních online testovacích zpráv není úspěšnost nízká (ale ani 100 %). V tomto ohledu Clowwindy již v původní verzi nabídl automatické banování, které tyto škodlivé IP adresy automaticky blokuje. Právě jsem přidal patch do libQtShadowsocks a tento patch blokuje detekci této metody, která vrací náhodné řetězce náhodné délky podle náhodné pravděpodobnosti.
To však neznamená, že protokol Shadowsocks je dokonalý, ale že "řešení" ShadowsocksR je pokřivené, protože jeho zaměření je pokřivené. Můj osobní nápad je použít veřejné klíče a soukromé klíče ke zlepšení bezpečnosti, i když to není příliš přátelské pro začátečníky, ale bezpečnost se zlepší a charakteristiky se sníží (není třeba posílat IV ve fázi podání ruky) a protokol shadowsocks se musí vyvíjet směrem k bezpečnosti CCA.
Aktualizováno 05. září 2015
Jakmile je chyba hlavičky (nelze ji vyřešit) nalezena, nesprávný IV a IP se přidá do seznamu neúspěšných IV a IP, pokud IV již existuje v seznamu neúspěšných IV, nebo IP již existuje v seznamu neúspěšných IP, IP, která odeslala požadavek na připojení, bude přidána na černou listinu a IP na černé listině připojení přímo odmítne. Pro nejnovější informace o anti-detekci se prosím podívejte na tento problém, tento článek neaktualizuje opatření proti detekci.
Aktualizováno 06. září 2015
Tento článek vám jen chce říct, abyste se příliš nebáli bezpečnosti Shadowsocks, současný protokol zatím neměl zásadní zranitelnosti a servery hlavních portů jsou také aktualizovány kvůli odstranění potenciálních hrozeb. Dobře jsem komunikoval i s autorem ShadowsocksR a potrvá ještě nějakou dobu, než dorazí whitelist.
Aktualizováno 24. září 2015
Bezpečnost Shadowsocks zmíněná v tomto článku se spíše týká bezpečnosti serveru a současný protokol hrozí, že server bude vystaven hrubé detekci a následně bude blokován firewally (i když náklady na detekci jsou velmi vysoké). Bezpečnost přenášeného obsahu není třeba řešit, všechny jsou průmyslově výkonné šifrovací algoritmy (kromě RC4 a TABLE) a je téměř nemožné prolomit přenášený obsah.
Aktualizováno 18. listopadu 2015
Shadowsocks zlepšil svou bezpečnost proti CCA přidáním jediného ověření a hlavní porty již svou podporu dokončily. Je důležité znovu zdůraznit, že cílem Shadowsocks není být 100% bez chyb nebo 100% neprůstřelných, ale zajistit, aby připojení bylo lehké a rychlé, zatímco běžné metody útoku by byly příliš drahé na implementaci.
|
Zveřejněno 10.11.2017 12:41:35
|
|
|
