SS je izvirnik, SSR je različica tretje osebe, izpeljana iz izvirnika, združljiva z izvirnim protokolom in ima nekaj več funkcij prikrivanja (protokol in zmeda) kot izvirnik.
Na internetu je tudi veliko razprav o SSR, tako za kot proti, a za običajne uporabnike. Ne glede na to, ali gre za SS ali SSR, vam lahko trenutno pomaga normalno splezati čez zid.
Kar zadeva različico odjemalca, ki jo preneseš, je vse odvisno od tega, ali je na strežniku SS računa nameščen SSR ali SSR. Najbolj izvirna funkcija SS se lahko uporablja ne glede na to, kateri odjemalec je prenesen, vendar če želite uporabljati funkcije SSR (protokol in zmeda), morate prenesti odjemalca SSR.
A brez skrbi, vsa vozlišča, ki jih ponujamo, podpirajo združljivost s SS in SSR. Priporočljivo je uporabljati SSR. Hitreje, da se prepreči usklajevanje!
Pred časom je bilo veliko govora o Shadowsocks, v zadnjem času pa je jasno, da je veliko začetnikov pritegnilo t. i. "Shadowsocks Enhanced" (ShadowsocksR). Kot amaterski razvijalec implementacije Shadowsocks v C++/Qt bi rad na kratko izrazil svoje mnenje o teh dveh ocvrtih piščancih.
ShadowsocksR
Ne vem, ali ima razvijalec za tem kakšno ozadje ali ekipo, vem pa, da je avtor za sekundarni razvoj zaprl Shadowsocks C# odjemalca v nasprotju z GPL. O drugih dejavnikih tukaj ne bomo govorili, dejstvo je, da je GPL zelo jasno in črno na belem, kršitev je kršitev. A avtor je nato kodno bazo razširil kot odprtokodno, kar lahko štejemo za konec incidenta, zato ni potrebe, da bi to nadaljevali.
Stvari so se spremenile, potem ko je Clowwindy izpraznil svojo Shadowsocks kodo. Spodaj je le seznam dejstev:
Avtor ShadowsocksR je povedal, da želi začeti znova in napisati novo proxy orodje, ki ni povezano s shadowsocks in ne bo več posodabljal ShadowsocksR
Dva ali tri dni kasneje je bilo naročeno izbrisati ShadowSocks, prvotni projekt Shadowsocks pa je praktično izginil
Avtor ShadowsocksR je dejal, da je bil izvirni protokol Shadowsocks pomanjkljiv (obravnavano v naslednjem poglavju) in se vrnil k osredotočenosti
Avtor ShadowsocksR je vzpostavil Google+ skupino in posodobil kodo, povezano s ShadowsocksR,
Varnost Shadowsocks
Začnimo zdaj z opisom trditve avtorja ShadowsocksR, da je napaka protokola Shadowsocks v tem, da je dolžina IV v večini primerov 16 bajtov. Druga polovica je pravilna, mnogi šifrirni algoritmi uporabljajo IV-je, dolge 16 bajtov (še posebej priljubljeni AES in RC4-MD5), kaj potem? To ne povzroča tako imenovanih "napak" iz naslednjih razlogov:
IV vsake TCP povezave v fazi rokovanja je naključno generiran, ne izračunan iz gesla, zato je IV nepredvidljiv.
Brez ključa, tudi če je ta del IV prestrežen, šifriranega besedila ni mogoče dešifrirati. Vsaka nova TCP povezava uporablja naključno generiran IV, torej podatki, prestreženi iz različnih TCP povezav, imajo malo skupnega. Dešifriranje šifriranega besedila zahteva tako pravilen IV kot šifro, povezava pa nima nobenih značilnosti glede šifre.
Večina IV-jev je dolga 16 bajtov, kar je možna kombinacija 256 na potenco 16, in nemogoče je z grobo silo narediti crack, ko so vsi IV-ji enaki, kaj šele dodati še eno točko.
Po pristopu ShadowsocksR je nesmiselno dodajati t.i. obfuskacijsko glavo pred prvo povezavo, saj so njegove lastne značilnosti očitne in ne spremeni bistva kasnejšega IV ali fiksne dolžine. Ker četrti bajt pove dolžino naključno zapolnjenih podatkov, lahko IV, dokler preskočite prejšnji kup pri izvajanju t.i. "sondiranja", še vedno prestrežete IV. In kot sem rekel pred nekaj točkami, je neuporabno, če dobiš ta naključni IV. Če se uporablja za zaznavanje, je fiksna prva različica logotipa gola značilnost, poslana v identifikacijo.
Avtor ShadowsocksR trenutno zagotavlja skripto za aktivno zaznavanje, ki omogoča zaznavanje, ali strežnik izvaja shadowsocks, in po trenutnih spletnih testnih poročilih uspešnost ni nizka (a ne 100%). V zvezi s tem je Clowwindy že v izvirni različici ponudil rešitev za samodejno prepoved, ki samodejno blokira te zlonamerne IP-je. Pravkar sem dodal popravek za libQtShadowsocks in ta popravek blokira zaznavanje te metode, ki vrača naključne nize naključne dolžine glede na naključno verjetnost.
Vendar to ne pomeni, da je protokol Shadowsocks popoln, temveč da je ShadowsocksR-jeva "rešitev" postrani, ker je njen fokus postrani. Moja osebna ideja je uporaba javnih ključev in zasebnih ključev za izboljšanje varnosti, čeprav ni ravno prijazna do začetnikov, vendar bo varnost izboljšana, lastnosti pa zmanjšane (ni potrebe po pošiljanju IV-jev v fazi rokovanja), protokol shadowsocks pa se mora razviti v smeri varnosti CCA.
Posodobljeno 05. sep 2015
Ko je napaka v glavi (ki je ni mogoče rešiti) najdena, se napačen IV in IP doda na seznam neuspešnih IV in IP, če IV že obstaja na seznamu neuspešnih IV ali IP že obstaja na seznamu neuspešnih IP, bo IP, ki je poslal zahtevo za povezavo, dodan na črni seznam, IP na črnem seznamu pa bo neposredno zavrnil povezavo. Za najnovejše podrobnosti o preprečevanju zaznavanja si oglejte to številko, ta članek pa ne bo posodobil ukrepov za preprečevanje zaznavanja.
Posodobljeno 06. sep. 2015
Ta članek vam želi le povedati, da se ne obremenjujete preveč z varnostjo Shadowsocks, trenutni protokol še nima večjih ranljivosti, strežniki glavnih vrat pa se prav tako posodabljajo za odpravo morebitnih groženj. Dobro sem komuniciral tudi z avtorjem ShadowsocksR, in še nekaj časa bo minilo, preden bo bela lista prispela.
Posodobljeno 24. septembra 2015
Varnost Shadowsocks, omenjena v tem članku, se bolj nanaša na varnost strežnika, trenutni protokol pa nosi tveganje, da strežnik izpostavi zaznavanju z grobo silo in ga nato blokirajo požarni zidovi (čeprav je strošek zaznavanja zelo visok). Varnost prenesene vsebine ni razloga za skrb, saj so vsi industrijski visokozmogljivi šifrirni algoritmi (razen RC4 in TABLE), in skoraj nemogoče je razbiti preneseno vsebino.
Posodobljeno 18. novembra 2015
Shadowsocks je izboljšal svojo varnost pred CCA z dodajanjem ene same verifikacije, večje porte pa so že zaključile svojo podporo. Pomembno je ponovno poudariti, da cilj Shadowsocks ni biti 100 % brez hroščev ali 100 % neprebojen, temveč zagotoviti, da je povezava lahka in hitra, hkrati pa je uporaba glavnih metod napadov predraga.
|
Objavljeno na 10. 11. 2017 12:41:35
|
|
|
