Az SS az eredeti, az SSR pedig egy harmadik féltől származó verzió, amely az eredetiből származik, kompatibilis az eredeti protokollral, és több álcázási funkcióval rendelkezik (protokoll és zavar), mint az eredeti.
Az interneten sok szó van az SSR-ről is, mind mellette, mind ellene, de a hétköznapi felhasználók számára. Akár SS, akár SSR, jelenleg is segíthet átmászni a falon.
Ami azt illeti, hogy melyik kliens verziót töltöd le, az attól függ, hogy SS vagy SSR telepítve van-e a megvásárolt SS fiók szerverére. A legeredetibb SS funkciót bármilyen klienst is letöltheted, de ha az SSR funkcióit (protokoll és zavar) szeretnéd használni, le kell töltened az SSR klienst.
De ne aggódj, minden csomópont, amit biztosítunk, támogatja az SS és az SSR kompatibilitást. Ajánlott az SSR használata. Gyorsabban, hogy elkerülje a harmóniát!
Néhány ideje sok zaj volt a Shadowsocks-ról, és mostanában nyilvánvalóvá vált, hogy sok kezdő vonzó volt az úgynevezett "Shadowsocks Enhanced" (ShadowsocksR) iránt. Mint amatőr fejlesztő, aki C++/Qt-ben valósítja meg a Shadowsocks-ot, szeretném röviden kifejezni a véleményemet erről a két sült csirkéről.
ShadowsocksR
Nem tudom, hogy a mögötte álló fejlesztőnek van-e háttére vagy csapata, de azt tudom, hogy a szerző a Shadowsocks C# kliensét zárt forráskóddal a másodlagos fejlesztéshez, megsértve a GPL-t. Itt nem beszélünk más tényezőkről, a tény az, hogy a GPL nagyon világos, fekete-fehérben, a megsértés jogsértés. De a szerző ezután megnyitotta a kódbázist, ami egy incidens végének tekinthető, és nincs szükség további folytatásra.
A dolgok megváltoztak, miután Clowwindy kiürítette a Shadowsocks kódtárolóját. Az alábbiakban csak a tények listája található:
A ShadowsocksR szerzője azt mondta, hogy az elején szeretne elindítani egy új proxy eszközt, amely nem kapcsolódik a shadowsocks-hoz, és többé nem frissíti a ShadowsocksR-t
Két-három nappal később elrendelték a ShadowSocks törlését, és az eredeti Shadowsocks projekt gyakorlatilag eltűnt
A ShadowsocksR szerzője azt mondta, hogy az eredeti shadowsocks protokoll hibás volt (a következő részben tárgyalják), és visszatért a fókuszba
A ShadowsocksR szerzője létrehozott egy Google+ csoportot, és frissítette a ShadowsocksR-hez kapcsolódó kódot
Shadowsocks biztonsági szolgálata
Most kezdjük azzal, hogy a ShadowsocksR szerzője azt állítja, hogy a Shadowsocks protokoll hibája az, hogy az IV hossza a legtöbb esetben 16 bájt. A második fele helyes, sok titkosítási algoritmus 16 bájtos IV-eket használ (különösen a népszerű AES és RC4-MD5), és akkor mi van? Ez nem vezet be úgynevezett "hibákat" az alábbi okok miatt:
A kézfogás szakaszában minden TCP kapcsolat IV-je véletlenszerűen generálódik, nem a jelszóból számítva, így az IV kiszámíthatatlan.
Kulcs nélkül, még ha ez az IV része is elfogódik, a titkosított szöveg nem lehet visszafejteni. És minden új TCP kapcsolat véletlenszerűen generált IV-t használ, vagyis a különböző TCP kapcsolatokból elfogott adatoknak kevés közös vonása van. A titkosított szöveg dekódolásához mind a megfelelő IV, mind a titkosító kód szükséges, és bármilyen kapcsolatnak nincs jellemzője a titkosításra.
A legtöbb IV 16 bájt hosszú, ami akár 256 és 16 hatvány kombinációja, és lehetetlen brute force crack-et használni, ha minden IV ugyanaz, nemhogy hozzáadni egy második pontot.
A ShadowsocksR megközelítése szerint értelmetlen az úgynevezett rejtett fejlécet az első kapcsolat előtt hozzáadni, a saját jellemzői nyilvánvalóak, és egyáltalán nem változtatja meg a későbbi IV vagy fix hossz lényegét. Mivel a negyedik bájt megmutatja a véletlenszerűen kitöltött adatok hosszát, amennyiben kihagyod az előző halmot az úgynevezett "probing" közben, akkor is elfoghatod az IV-t. És ahogy pár ponttal korábban mondtam, haszontalan, ha véletlenszerű infúziót kapsz. Ha felismerésre használják, a logó rögzített első változata a meztelen funkció, amelyet azonosításra küldenek.
A ShadowsocksR szerzője jelenleg egy aktív észlelési szkriptet biztosít, amellyel kimutathatja, hogy a szerver shadowsock-okat futtat-e, és a jelenlegi online tesztjelentések szerint a sikerességi arány nem alacsony (de nem 100%). Ebben a tekintetben a Clowwindy már automatikus tiltási megoldást adott az eredeti verzióban, automatikusan blokkolva ezeket a rosszindulatú IP-ket. Most tettem fel egy javítást a libQtShadowsocks-hoz, és ez a patch blokkolja ennek a módszernek a felismerését, amely véletlenszerű hosszúságú véletlenszerű sorozatokat ad vissza a véletlen valószínűség alapján.
Ez azonban nem jelenti azt, hogy a Shadowsocks protokoll tökéletes, hanem hogy a ShadowsocksR "megoldása" torp, mert a fókusza torz. Személyes ötletem, hogy nyilvános és privát kulcsokat használjak a biztonság javítására, bár ez nem túl barát a kezdőknek, de a biztonság javul, és a jellemzők csökkenni fognak (nem kell IV-t küldeni a kézfogás szakaszában), és a shadowsocks protokollnak a CCA biztonság irányába kell fejlődnie.
Frissítve: 2015. szeptember 5.
Ha megtalálják a fejléchibát (nem oldható), a rossz IV és IP kerül a sikertelen IV és IP listára, ha az IV már létezik a sikertelen IV listában, vagy az IP már létezik a sikertelen IP listában, az IP kerül a feketelistára, és a feketelistán szereplő IP közvetlenül elutasítja a kapcsolatot. A legfrissebb részletekért az anti-detection oldalára kérjük, látogasson el erre a számra, és ez a cikk nem frissíti az anti-detection elleni intézkedéseket.
Frissítve: 2015. szeptember 6.
Ez a cikk csak azt szeretné mondani, hogy ne aggódj túl sokat a Shadowsocks biztonsága miatt, a jelenlegi protokoll még nem mutatott jelentős sebezhetőséget, és a fő portok szervereit is frissítik, hogy kijavítsák a lehetséges fenyegetéseket. Jól kommunikáltam a ShadowsocksR szerzőjével is, és még egy ideig megérkezik a fehérlista.
Frissítve: 2015. szeptember 24.
A cikkben említett Shadowsocks biztonság inkább a szerver biztonságára utal, és a jelenlegi protokoll veszélye van annak, hogy a szervert brute force detektálásnak teszi ki, majd tűzfalak blokkolják (bár az észlelés költsége nagyon magas). Az átküldött tartalom biztonsága nem aggódik, hiszen mind ipari szintű, nagy erősségű titkosítási algoritmusok (kivéve az RC4-et és a TABLE-t), és szinte lehetetlen feltörni az átküldött tartalmat.
Frissítve: 2015. november 18.
A Shadowsocks egyetlen ellenőrzéssel javította a CCA elleni biztonságát, és a főbb portok már befejezték a támogatásukat. Fontos hangsúlyozni, hogy a Shadowsocks célja nem az, hogy 100%-ban hibamentes vagy 100%-ban golyóálló, hanem hogy a kapcsolat könnyűek és gyors legyenek, miközben a mainstream támadási módszerek túl drága lettek a megvalósításhoz.
|
Közzétéve 2017. 11. 10. 12:41:35
|
|
|
