SS är originalet, SSR är en tredjepartsversion härledd från originalet, kompatibel med det ursprungliga protokollet och har fler kamouflagefunktioner (protokoll och förvirring) än originalet.
Det finns också mycket diskussion om SSR på internet, både för och emot, men för vanliga användare. Oavsett om det är SS eller SSR kan det hjälpa dig att klättra över muren på vanligt sätt just nu.
När det gäller vilken version av klienten du laddar ner beror helt på om SS eller SSR är installerad på servern för det SS-konto du köpte. Den mest originella SS-funktionen kan användas oavsett vilken klient som laddas ner, men om du vill använda SSR:s funktioner (protokoll och förvirring) måste du ladda ner SSR-klienten.
Men oroa dig inte, alla noder vi tillhandahåller stödjer SS- och SSR-kompatibilitet. Det rekommenderas att använda SSR. Snabbare för att undvika att harmoniseras!
Det var mycket oväsen om Shadowsocks för ett tag sedan, och på sistone är det tydligt att ett stort antal nybörjare har dragits till den så kallade "Shadowsocks Enhanced" (ShadowsocksR). Som amatörutvecklare av att implementera Shadowsocks i C++/Qt vill jag kort uttrycka min åsikt om dessa två friterade kycklingar.
ShadowsocksR
Jag vet inte om utvecklaren bakom det har en bakgrund eller ett team, men det jag vet är att dess författare stängde källkoden till Shadowsocks C#-klienten för dess sekundära utveckling i strid med GPL. Vi kommer inte att prata om andra faktorer här, faktum är att GPL är mycket tydlig svart på vitt, att bryta mot är att bryta mot reglerna. Men författaren öppnade sedan kodbasen, vilket kan ses som slutet på en incident, och det finns inget behov av att gå vidare med det.
Saker förändrades efter att Clowwindy tömde sin Shadowsocks-kodbutik. Följande är bara en lista med fakta:
ShadowsocksR-författaren har sagt att han vill börja om från början för att skriva ett nytt proxyverktyg som inte är relaterat till shadowsocks, och han kommer inte längre att uppdatera ShadowsocksR
Två eller tre dagar senare beordrades ShadowSocks att raderas, och det ursprungliga Shadowsocks-projektet försvann i princip
Författaren till ShadowsocksR sa att det ursprungliga Shadowsocks-protokollet var bristfälligt (diskuterat i nästa avsnitt) och återgick till fokus
ShadowsocksR-författaren har etablerat en Google+-grupp och uppdaterat den ShadowsocksR-relaterade koden
Shadowsocks säkerhet
Nu börjar vi med beskrivningen av ShadowsocksR-författarens påstående att Shadowsocks-protokollets brist är att IV:s längd i de flesta fall är 16 byte. Den senare halvan stämmer, många krypteringsalgoritmer använder IV:er som är 16 byte långa (särskilt den populära AES och RC4-MD5), så vadå? Detta introducerar inte så kallade "defekter" av följande skäl:
IV:n för varje TCP-anslutning vid handskakningssteget genereras slumpmässigt, inte beräknad från lösenordet, så IV:n är oförutsägbar.
Utan nyckeln, även om denna del av IV:n avlyssnas, kan chiffertexten inte dekrypteras. Och varje ny TCP-anslutning använder en slumpmässigt genererad IV, det vill säga att data som avlyssnas från olika TCP-anslutningar har lite gemensamt. Att dekryptera chiffertext kräver både korrekt IV och chiffer, och varje koppling har inga egenskaper hos chiffret.
De flesta IV:er är 16 byte långa, vilket är en möjlig kombination av 256 uppdelat 16-potens, och det är omöjligt att brute force-knäcka när alla IV:er är likadana, än mindre lägga till en andra punkt.
Enligt ShadowsocksR:s metod är det meningslöst att lägga till den så kallade obfuskationsheadern före den första anslutningen, dess egna egenskaper är uppenbara, och det förändrar inte essensen av den senare IV:n eller fast längd alls. Eftersom den fjärde byten visar längden på den slumpmässigt fyllda datan, kan du fortfarande intercepta IV så länge du hoppar över föregående hög när du utför den så kallade "probingen". Och som jag sa för några punkter sedan, det är värdelöst om du får denna slumpmässiga dropp. Om den används för detektering är den fasta första versionen av logotypen den nakna funktionen som skickas för identifiering.
Författaren till ShadowsocksR tillhandahåller för närvarande ett aktivt detekteringsskript som kan användas för att upptäcka om servern kör shadowsocks, och enligt de aktuella onlinetestrapporterna är framgångsgraden inte låg (men inte 100%). I detta avseende har Clowwindy redan gett en automatisk avstängningslösning i originalversionen, vilket automatiskt blockerar dessa skadliga IP-adresser. Jag har precis lagt till en patch i libQtShadowsocks och denna patch blockerar upptäckten av denna metod, som returnerar slumpmässiga strängar av slumpmässig längd enligt slumpmässig sannolikhet.
Detta betyder dock inte att Shadowsocks-protokollet är perfekt, utan att ShadowsocksR:s "lösning" är sned eftersom dess fokus är sned. Min personliga idé är att använda publika nycklar och privata nycklar för att förbättra säkerheten, även om det inte är särskilt vänligt för nybörjare, men säkerheten kommer att förbättras och egenskaperna kommer att minskas (ingen IV behövs vid handskakningsstadiet), och shadowsocks-protokollet behöver utvecklas i riktning mot CCA-säkerhet.
Uppdaterad 05-sep-2015
När headerfelet (som inte kan lösas) hittas, kommer fel IV och IP att läggas till i listan över misslyckade IV och IP, om IV:n redan finns i misslyckad IV-listan, eller om IP:n redan finns i den misslyckade IP-listan, kommer IP:n som skickade anslutningsförfrågan att läggas till svartlistan, och IP:n i svartlistan kommer direkt att avvisa anslutningen. För de senaste detaljerna om anti-detektering, vänligen se detta problem, och denna artikel uppdaterar inte motåtgärderna mot anti-detektering.
Uppdaterad 06-sep-2015
Den här artikeln vill bara säga att du inte behöver oroa dig för mycket för säkerheten i Shadowsocks, det nuvarande protokollet har ännu inte haft några större sårbarheter, och servrarna på huvudportarna uppdateras också för att åtgärda potentiella hot. Jag har också kommunicerat väl med författaren till ShadowsocksR, och det kommer att dröja innan vitlistan kommer.
Uppdaterad 24 sep 2015
Shadowsocks-säkerheten som nämns i denna artikel syftar mer på serverns säkerhet, och det nuvarande protokollet riskerar att utsätta servern för brute force-upptäckt och sedan blockeras av brandväggar (även om kostnaden för upptäckt är mycket hög). Säkerheten för det överförda innehållet är inget att oroa sig för, alla är industriella högstyrkekrypteringsalgoritmer (förutom RC4 och TABLE), och det är nästan omöjligt att knäcka det överförda innehållet.
Uppdaterad 18 nov 2015
Shadowsocks har förbättrat sin säkerhet mot CCA genom att lägga till en enda verifiering, och stora hamnar har redan slutfört sitt stöd. Det är viktigt att upprepa att målet med Shadowsocks inte är att vara 100 % buggfritt eller 100 % kulsäkert, utan att säkerställa att anslutningen är lättviktig och snabb samtidigt som de etablerade attackmetoderna blir för dyra att implementera.
|
Publicerad på 2017-11-10 12:41:35
|
|
|
