SS er originalen, SSR er en tredjepartsversjon avledet fra originalen, kompatibel med den opprinnelige protokollen, og har noen flere kamuflasjefunksjoner (protokoll og forvirring) enn originalen.
Det er også mye diskusjon om SSR på Internett, både for og imot, men for vanlige brukere. Enten det er SS eller SSR, kan det hjelpe deg å klatre over muren normalt nå.
Når det gjelder hvilken versjon av klienten du laster ned, avhenger alt av om SS eller SSR er installert på serveren til SS-kontoen du kjøpte. Den mest originale SS-funksjonen kan brukes uansett hvilken klient som lastes ned, men hvis du vil bruke SSRs funksjoner (protokoll og forvirring), må du laste ned SSR-klienten.
Men ikke bekymre deg, alle nodene vi tilbyr støtter SS- og SSR-kompatibilitet. Det anbefales å bruke SSR. Raskere for å unngå å bli harmonisert!
Det var mye oppstyr rundt Shadowsocks for en tid tilbake, og nylig er det tydelig at mange nybegynnere har blitt tiltrukket av den såkalte "Shadowsocks Enhanced" (ShadowsocksR). Som en amatørutvikler som implementerer Shadowsocks i C++/Qt, vil jeg kort uttrykke min mening om disse to friterte kyllingene.
ShadowsocksR
Jeg vet ikke om utvikleren bak det har bakgrunn eller et team, men det jeg vet er at forfatteren faktisk lukket Shadowsocks C#-klienten for sin sekundærutvikling i strid med GPL. Vi skal ikke snakke om andre faktorer her, faktum er at GPL er veldig tydelig svart på hvitt, brudd er brudd. Men forfatteren åpnet deretter kodebasen, noe som kan betraktes som slutten på en hendelse, og det er ikke nødvendig å forfølge det videre.
Ting endret seg etter at Clowwindy tømte sin Shadowsocks-kodebutikk. Følgende er bare en liste med fakta:
Forfatteren av ShadowsocksR har sagt at han ønsker å starte helt fra bunnen av for å lage et nytt proxy-verktøy som ikke er relatert til shadowsocks, og at han ikke lenger vil oppdatere ShadowsocksR
To eller tre dager senere ble ShadowSocks beordret slettet, og det opprinnelige Shadowsocks-prosjektet forsvant i praksis
Forfatteren av ShadowsocksR sa at den opprinnelige shadowsocks-protokollen var mangelfull (diskutert i neste avsnitt) og vendte tilbake til fokus
Forfatteren av ShadowsocksR har opprettet en Google+ Group og oppdatert koden relatert til ShadowsocksR
Shadowsocks-sikkerhet
La oss nå begynne med beskrivelsen av ShadowsocksR-forfatterens påstand om at Shadowsocks-protokollens feil er at lengden på IV-en i de fleste tilfeller er 16 byte. Den siste delen er korrekt, mange krypteringsalgoritmer bruker IV-er som er 16 byte lange (spesielt den populære AES og RC4-MD5), og hva så? Dette introduserer ikke såkalte «defekter» av følgende grunner:
IV-en til hver TCP-tilkobling i håndtrykksfasen genereres tilfeldig, ikke beregnet fra passordet, så IV-en er uforutsigbar.
Uten nøkkelen, selv om denne delen av IV-en blir avlyttet, kan ikke chifferteksten dekrypteres. Og hver ny TCP-tilkobling bruker en tilfeldig generert IV, det vil si at dataene som blir avlyttet fra ulike TCP-tilkoblinger har lite til felles. Dekryptering av chiffertekst krever både korrekt IV og chifferet, og enhver forbindelse har ingen kjennetegn ved chifferet.
De fleste IV-er er 16 byte lange, noe som er en mulig kombinasjon av 256 til en potens av 16, og det er umulig å brute force crack når alle IV-er er like, for ikke å snakke om å legge til et ekstra punkt.
Ifølge ShadowsocksRs tilnærming er det nytteløst å legge til den såkalte obfusker-headeren før den første tilkoblingen, dens egne egenskaper er åpenbare, og det endrer ikke essensen til den senere IV eller fast lengde i det minste. Fordi den fjerde byten forteller deg lengden på de tilfeldig fylte dataene, kan du fortsatt avskjære IV så lenge du hopper over forrige bunke når du utfører den såkalte "probingen". Og som jeg sa for noen punkter siden, er det nytteløst hvis du får denne tilfeldige IV-en. Hvis den brukes til deteksjon, er den faste første versjonen av logoen naken-funksjonen sendt for identifikasjon.
Forfatteren av ShadowsocksR tilbyr for øyeblikket et aktivt deteksjonsskript som kan brukes til å oppdage om serveren kjører shadowsocks, og ifølge de nåværende nettbaserte testrapportene er suksessraten ikke lav (men ikke 100 %). I denne sammenhengen har Clowwindy allerede gitt en automatisk utestengelsesløsning i den opprinnelige versjonen, som automatisk blokkerer disse ondsinnede IP-adressene. Jeg har nettopp lagt til en patch i libQtShadowsocks, og denne patchen blokkerer oppdagelsen av denne metoden, som returnerer tilfeldige strenger av tilfeldig lengde i henhold til tilfeldig sannsynlighet.
Dette betyr imidlertid ikke at Shadowsocks-protokollen er perfekt, men at ShadowsocksRs "løsning" er skjev fordi fokuset er skjevt. Min personlige idé er å bruke offentlige nøkler og private nøkler for å forbedre sikkerheten, selv om det ikke er særlig vennlig for nybegynnere, men sikkerheten vil bli forbedret, og egenskapene vil bli redusert (ingen behov for å sende IV-er i håndtrykksfasen), og shadowsocks-protokollen må utvikles i retning av CCA-sikkerhet.
Oppdatert 05-sep-2015
Når header-feilen (som ikke kan løses) er funnet, vil feil IV og IP bli lagt til i listen over mislykkede IV og IP; hvis IV-en allerede finnes i listen over mislykkede IV-er, eller IP-en allerede finnes i listen over mislykkede IP-er, vil IP-en som sendte tilkoblingsforespørselen bli lagt til svartelisten, og IP-en i svartelisten vil direkte avvise tilkoblingen. For de siste detaljene om anti-deteksjon, vennligst se dette problemet, og denne artikkelen vil ikke oppdatere mottiltakene for anti-deteksjon.
Oppdatert 06.sep-2015
Denne artikkelen vil bare si at du ikke trenger å bekymre deg for mye for sikkerheten til Shadowsocks, den nåværende protokollen har ennå ikke hatt store sårbarheter, og serverne til hovedportene blir også oppdatert for å fikse potensielle trusler. Jeg har også kommunisert godt med forfatteren av ShadowsocksR, og det vil ta en stund før hvitelisten kommer.
Oppdatert 24. september 2015
Shadowsocks-sikkerheten som nevnes i denne artikkelen refererer mer til serverens sikkerhet, og den nåværende protokollen har risiko for å utsette serveren for brute force-deteksjon og deretter bli blokkert av brannmurer (selv om kostnaden for deteksjon er svært høy). Sikkerheten til det overførte innholdet er ikke noe å bekymre seg for, alle er industrielle krypteringsalgoritmer med høy styrke (bortsett fra RC4 og TABLE), og det er nesten umulig å knekke det overførte innholdet.
Oppdatert 18. november 2015
Shadowsocks har forbedret sin sikkerhet mot CCA ved å legge til én enkelt verifisering, og store havner har allerede fullført sin støtte. Det er viktig å understreke at målet med Shadowsocks ikke er å være 100 % feilfritt eller 100 % skuddsikkert, men å sikre at forbindelsen er lett og rask, samtidig som vanlige angrepsmetoder blir for dyre å implementere.
|
Publisert på 10.11.2017 12:41:35
|
|
|
