SS je originál, SSR je verzia tretej strany odvodená od originálu, kompatibilná s pôvodným protokolom a má viac maskovacích funkcií (protokol a zmätok) než originál.
Na internete sa tiež veľa diskutuje o SSR, či už za alebo proti, ale pre bežných používateľov. Či už ide o SS alebo SSR, môže vám to pomôcť preliezť múr normálne v súčasnosti.
Čo sa týka verzie klienta, ktorú si stiahnete, všetko závisí od toho, či je na serveri SS účtu nainštalované SS alebo SSR. Najoriginálnejšia funkcia SS môže byť použitá bez ohľadu na to, ktorý klient sa stiahne, ale ak chcete použiť funkcie SSR (protokol a zmätok), musíte stiahnuť SSR klienta.
Ale nebojte sa, všetky uzly, ktoré poskytujeme, podporujú kompatibilitu so SS a SSR. Odporúča sa používať SSR. Rýchlejšie, aby sa zabránilo harmonizácii!
Pred časom sa o Shadowsocks veľa hovorilo a nedávno je jasné, že veľké množstvo začiatočníkov pritiahlo takzvané "Shadowsocks Enhanced" (ShadowsocksR). Ako amatérsky vývojár implementácie Shadowsocks v C++/Qt by som rád stručne vyjadril svoj názor na tieto dve vyprážané kurčatá.
ShadowsocksR
Neviem, či má vývojár za tým skúsenosti alebo tím, ale viem, že autor uzavrel Shadowsocks C# klienta pre sekundárny vývoj, čím porušil GPL. Nebudeme tu hovoriť o ďalších faktoroch, faktom je, že GPL je jasne čierne na bielom, porušenie je porušenie. Autor však potom sprístupnil kódovú základňu ako open source, čo možno považovať za koniec incidentu, a nie je potrebné to ďalej riešiť.
Veci sa zmenili potom, čo Clowwindy vyprázdnil svoj kódový úložisko Shadowsocks. Nasleduje len zoznam faktov:
Autor ShadowsocksR povedal, že chce začať od nuly a napísať nový proxy nástroj, ktorý nebude súvisieť so shadowsocks a už nebude aktualizovať ShadowsocksR
O dva či tri dni neskôr bolo nariadené vymazať ShadowSocks a pôvodný projekt Shadowsocks prakticky zmizol
Autor ShadowsocksR povedal, že pôvodný protokol shadowsocks bol chybný (diskutované v ďalšej časti) a vrátil sa k zameraniu
Autor ShadowsocksR založil Google+ skupinu a aktualizoval kód súvisiaci so ShadowsocksR
Bezpečnosť Shadowsocks
Teraz začnime popisom tvrdenia autora ShadowsocksR, že chybou protokolu Shadowsocks je, že dĺžka IV je vo väčšine prípadov 16 bajtov. Druhá polovica je správna, mnohé šifrovacie algoritmy používajú IV s dĺžkou 16 bajtov (najmä populárne AES a RC4-MD5), a čo z toho? To neprináša takzvané "chyby" z nasledujúcich dôvodov:
IV každého TCP spojenia v štádiu handshake je generovaný náhodne, nie vypočítaný z hesla, takže IV je nepredvídateľný.
Bez kľúča, aj keď je táto časť IV zachytená, šifrovaný text nemožno dešifrovať. A každé nové TCP spojenie používa náhodne generovaný IV, teda dáta zachytené z rôznych TCP spojení majú málo spoločného. Dešifrovanie šifrovaného textu vyžaduje správne IV aj šifru a akékoľvek spojenie nemá žiadne charakteristiky šifry.
Väčšina IV má dĺžku 16 bajtov, čo je možná kombinácia 256 na mocninu 16, a je nemožné hrubou silou cracknúť, keď sú všetky IV rovnaké, nieto ešte pridať druhý bod.
Podľa prístupu ShadowsocksR je zbytočné pridávať tzv. obfuskáciu hlavičku pred prvé spojenie, jej vlastné charakteristiky sú zrejmé a vôbec nemení podstatu neskoršieho IV alebo pevnej dĺžky. Keďže štvrtý bajt vám ukáže dĺžku náhodne vyplnených dát, pokiaľ pri tzv. "sondovaní" preskočíte predchádzajúcu kopu, stále môžete IV zachytiť. A ako som povedal pred pár bodmi, je to zbytočné, ak dostaneš túto náhodnú IV. Ak sa používa na detekciu, pevná prvá verzia loga je nahý prvok zaslaný na identifikáciu.
Autor ShadowsocksR momentálne poskytuje aktívny detekčný skript, ktorý umožňuje zistiť, či server používa shadowsocks, a podľa aktuálnych online testovacích správ úspešnosť nie je nízka (ale nie 100%). V tomto ohľade Clowwindy už v pôvodnej verzii poskytol automatické banovanie, ktoré tieto škodlivé IP adresy automaticky blokuje. Práve som pridal patch do libQtShadowsocks a tento patch blokuje detekciu tejto metódy, ktorá vracia náhodné reťazce náhodnej dĺžky podľa náhodnej pravdepodobnosti.
To však neznamená, že protokol Shadowsocks je dokonalý, ale že "riešenie" ShadowsocksR je pokrivené, pretože jeho zameranie je pokrivené. Môj osobný nápad je použiť verejné kľúče a súkromné kľúče na zlepšenie bezpečnosti, hoci to nie je veľmi priateľské k začiatočníkom, ale bezpečnosť sa zlepší a charakteristiky sa znížia (nie je potrebné posielať IV v štádiu handshake) a protokol shadowsocks sa musí vyvíjať smerom k bezpečnosti CCA.
Aktualizované 5. septembra 2015
Keď sa chyba hlavičky (nedá sa vyriešiť) nájde, nesprávne IV a IP sa pridajú do zoznamu zlyhaných IV a IP, ak IV už existuje v zozname neúspešných IV, alebo IP už existuje v zozname zlyhaných IP, IP, ktorá odoslala požiadavku na spojenie, bude pridaná na čiernu listinu a IP na čiernej listine priamo odmietne spojenie. Pre najnovšie informácie o anti-detekcii sa prosím pozrite na tento problém a tento článok neaktualizuje opatrenia proti detekcii.
Aktualizované 06-sep-2015
Tento článok vám len chce povedať, aby ste sa príliš neobávali bezpečnosti Shadowsocks, aktuálny protokol zatiaľ nemal vážne zraniteľnosti a servery hlavných portov sa tiež aktualizujú na odstránenie potenciálnych hrozieb. Dobre som komunikoval aj s autorom ShadowsocksR a potrvá ešte nejaký čas, kým dorazí whitelist.
Aktualizované 24. septembra 2015
Bezpečnosť Shadowsocks spomenutá v tomto článku sa týka skôr bezpečnosti servera a súčasný protokol hrozí, že server bude vystavený hrubej sile detekcii a následne zablokovaný firewallmi (hoci náklady na detekciu sú veľmi vysoké). Bezpečnosť prenášaného obsahu nie je dôvodom na obavy, všetky sú priemyselné vysokovýkonné šifrovacie algoritmy (okrem RC4 a TABLE) a je takmer nemožné prelomiť prenášaný obsah.
Aktualizované 18. novembra 2015
Shadowsocks zlepšil svoju bezpečnosť proti CCA pridaním jediného overenia a hlavné porty už dokončili svoju podporu. Je dôležité zdôrazniť, že cieľom Shadowsocks nie je byť 100% bez chýb alebo 100% nepriestrelný, ale zabezpečiť, aby pripojenie bolo ľahké a rýchle, pričom bežné metódy útoku by boli príliš drahé na implementáciu.
|
Zverejnené 10. 11. 2017 12:41:35
|
|
|
