SS er den oprindelige, SSR er en tredjepartsversion afledt af originalen, kompatibel med den oprindelige protokol, og har nogle flere camouflagefunktioner (protokol og forvirring) end den oprindelige.
Der er også meget diskussion om SSR på internettet, både for og imod, men for almindelige brugere. Uanset om det er SS eller SSR, kan det hjælpe dig med at klatre over muren normalt i øjeblikket.
Hvilken version af klienten du downloader, afhænger helt af, om SS eller SSR er installeret på serveren for den SS-konto, du har købt. Den mest originale SS-funktion kan bruges uanset hvilken klient der downloades, men hvis du vil bruge SSR's funktioner (protokol og forvirring), skal du downloade SSR-klienten.
Men bare rolig, alle de noder vi tilbyder understøtter SS- og SSR-kompatibilitet. Det anbefales at bruge SSR. Hurtigere for at undgå at blive harmoniseret!
Der var meget støj omkring Shadowsocks for noget tid siden, og for nylig er det tydeligt, at et stort antal nybegyndere er blevet tiltrukket af den såkaldte "Shadowsocks Enhanced" (ShadowsocksR). Som amatørudvikler af implementering af Shadowsocks i C++/Qt, vil jeg gerne kort udtrykke min mening om disse to stegte kyllinger.
ShadowsocksR
Jeg ved ikke, om udvikleren bag det har en baggrund eller et team, men det jeg ved er, at dens forfatter lukkede Shadowsocks C#-klienten til dens sekundære udvikling i strid med GPL. Vi vil ikke tale om andre faktorer her, faktum er, at GPL er meget klart sort på hvidt, at overtræde er overtrædelse. Men forfatteren åbnede derefter kodebasen, hvilket kan betragtes som afslutningen på en hændelse, og der er ikke behov for at forfølge det yderligere.
Tingene ændrede sig, efter Clowwindy tømte sin Shadowsocks-kodebutik. Følgende er blot en liste over fakta:
Forfatteren til ShadowsocksR har sagt, at han ønsker at starte forfra for at skrive et nyt proxy-værktøj, der ikke er relateret til shadowsocks, og han vil ikke længere opdatere ShadowsocksR
To eller tre dage senere blev ShadowSocks beordret slettet, og det oprindelige Shadowsocks-projekt forsvandt stort set
Forfatteren af ShadowsocksR sagde, at den oprindelige shadowsocks-protokol var fejlbehæftet (diskuteret i næste afsnit) og vendte tilbage til fokus
Forfatteren til ShadowsocksR har oprettet en Google+ Group og opdateret den ShadowsocksR-relaterede kode
Shadowsocks-sikkerhed
Lad os nu starte med beskrivelsen af ShadowsocksR-forfatterens påstand om, at Shadowsocks-protokollens fejl er, at længden af IV'en i de fleste tilfælde er 16 bytes. Den sidste halvdel er korrekt, mange krypteringsalgoritmer bruger IV'er, der er 16 bytes lange (især den populære AES og RC4-MD5), og hvad så? Dette medfører ikke såkaldte "defekter" af følgende grunde:
IV'en for hver TCP-forbindelse ved håndtryksstadiet genereres tilfældigt, ikke beregnet ud fra adgangskoden, så IV'en er uforudsigelig.
Uden nøglen, selv hvis denne del af IV'en bliver opsnappet, kan chifferteksten ikke dekrypteres. Og hver ny TCP-forbindelse bruger en tilfældigt genereret IV, det vil sige, at dataene, der opsnappes fra forskellige TCP-forbindelser, har meget lidt til fælles. Dekryptering af chiffertekst kræver både den korrekte IV og chifferet, og enhver forbindelse har ingen karakteristika ved chifferet.
De fleste IV'er er 16 bytes lange, hvilket er en mulig kombination af 256 til en potens af 16, og det er umuligt at brute force crack, når alle IV'er er ens, for slet ikke at tale om at tilføje et ekstra punkt.
Ifølge ShadowsocksR's tilgang er det nytteløst at tilføje den såkaldte obfuskationsheader før den første forbindelse, dens egne karakteristika er åbenlyse, og det ændrer slet ikke essensen af den senere IV eller fast længde. Fordi den fjerde byte fortæller dig længden af de tilfældigt fyldte data, kan du stadig opsnappe IV, så længe du springer den forrige bunke over, når du udfører den såkaldte "probing". Og som jeg sagde for et par punkter siden, er det nytteløst, hvis du får denne tilfældige IV. Hvis det bruges til detektion, er den faste første version af logoet den nøgne funktion, der sendes til identifikation.
Forfatteren af ShadowsocksR leverer i øjeblikket et aktivt detektionsscript, der kan bruges til at opdage, om serveren kører shadowsocks, og ifølge de nuværende online testrapporter er succesraten ikke lav (men ikke 100%). I denne forbindelse har Clowwindy allerede givet en automatisk udelukkelsesløsning i den oprindelige version, som automatisk blokerer disse ondsindede IP'er. Jeg har lige tilføjet en patch til libQtShadowsocks, og denne patch blokerer for detektionen af denne metode, som returnerer tilfældige strenge af tilfældig længde i forhold til tilfældig sandsynlighed.
Det betyder dog ikke, at Shadowsocks-protokollen er perfekt, men at ShadowsocksR's "løsning" er skæv, fordi dens fokus er skæv. Min personlige idé er at bruge offentlige nøgler og private nøgler for at forbedre sikkerheden, selvom det ikke er særlig venligt for nybegyndere, men sikkerheden vil blive forbedret, og karakteristikaene vil blive reduceret (ingen behov for at sende IV'er ved håndtryksstadiet), og shadowsocks-protokollen skal udvikle sig i retning af CCA-sikkerhed.
Opdateret 05-sep-2015
Når header-fejlen (som ikke kan løses) findes, vil den forkerte IV og IP blive tilføjet til listen over fejlede IV og IP; hvis IV'en allerede findes i listen over fejlede IV'er, eller hvis IP'en allerede findes i den fejlede IP-liste, vil den IP, der sendte forbindelsesanmodningen, blive tilføjet til sortlisten, og IP'en på sortlisten vil direkte afvise forbindelsen. For de seneste detaljer om anti-detektion, se venligst dette problem, og denne artikel opdaterer ikke modforanstaltningerne mod anti-detektion.
Opdateret 06-sep-2015
Denne artikel vil bare fortælle dig, at du ikke skal bekymre dig for meget om sikkerheden i Shadowsocks; den nuværende protokol har endnu ikke haft større sårbarheder, og serverne på hovedportene bliver også opdateret for at løse potentielle trusler. Jeg har også kommunikeret godt med forfatteren af ShadowsocksR, og det vil vare et stykke tid, før whitelisten kommer.
Opdateret 24-sep-2015
Shadowsocks-sikkerheden, der nævnes i denne artikel, refererer mere til serverens sikkerhed, og den nuværende protokol indebærer risikoen for at udsætte serveren for brute force-detektion og derefter blive blokeret af firewalls (selvom detektionsomkostningerne er meget høje). Sikkerheden af det transmitterede indhold er ikke noget at bekymre sig om, da alle er industrielle krypteringsalgoritmer med høj styrke (undtagen RC4 og TABLE), og det er næsten umuligt at knække det transmitterede indhold.
Opdateret 18-nov-2015
Shadowsocks har forbedret sin sikkerhed mod CCA ved at tilføje en enkelt verifikation, og store havne har allerede afsluttet deres support. Det er vigtigt at gentage, at målet med Shadowsocks ikke er at være 100% fejlfrit eller 100% skudsikkert, men at sikre, at forbindelsen er let og hurtig, samtidig med at mainstream angrebsmetoder bliver for dyre at implementere.
|
Opslået på 10/11/2017 12.41.35
|
|
|
