SS este originalul, SSR este o versiune terță derivată din original, compatibilă cu protocolul original și are unele funcții de camuflaj (protocol și confuzie) mai multe decât originalul.
Există, de asemenea, multă discuție despre SSR pe Internet, atât pentru, cât și contra, dar și pentru utilizatorii obișnuiți. Fie că este SSR sau SSR, te poate ajuta să escalazi zidul normal în prezent.
În ceea ce privește versiunea clientului pe care o descarci, totul depinde dacă SSR sau SSR este instalat pe serverul contului SS pe care l-ai cumpărat. Cea mai originală funcție SS poate fi folosită indiferent de clientul descărcat, dar dacă vrei să folosești funcțiile SSR (protocol și confuzie), trebuie să descarci clientul SSR.
Dar nu-ți face griji, toate nodurile pe care le oferim suportă compatibilitatea SSR și SSR. Se recomandă să folosești SSR. Mai repede ca să nu fii armonizată!
S-a vorbit mult despre Shadowsocks acum ceva timp, iar recent este clar că un număr mare de începători au fost atrași de așa-numitele "Shadowsocks Îmbunătățite" (ShadowsocksR). Ca dezvoltator amator care implementează Shadowsocks în C++/Qt, aș dori să-mi exprim pe scurt opinia despre aceste două pui prăjite.
ShadowsocksR
Nu știu dacă dezvoltatorul are experiență sau echipă, dar ce știu este că autorul său a făcut o sursă apropiată a clientului Shadowsocks C# pentru dezvoltarea sa secundară, încălcând GPL-ul. Nu vom vorbi despre alți factori aici, de fapt GPL este foarte clar în alb și negru, încălcarea înseamnă încălcare. Dar autorul a deschis apoi codul, ceea ce poate fi considerat sfârșitul unui incident, și nu este nevoie să se continue acest lucru.
Lucrurile s-au schimbat după ce Clowwindy și-a golit magazinul de coduri Shadowsocks. Următoarele sunt doar o listă de fapte:
Autorul ShadowsocksR a spus că vrea să o ia de la zero pentru a scrie un nou instrument proxy care să nu aibă legătură cu shadowsocksR și nu va mai actualiza ShadowsocksR
Două sau trei zile mai târziu, ShadowSocks a fost ordonat să fie șters, iar proiectul original ShadowSocks a dispărut practic
Autorul ShadowsocksR a spus că protocolul original shadowsocks era defectuos (discutat în secțiunea următoare) și a revenit în centrul atenției
Autorul ShadowsocksR a creat un grup Google+ și a actualizat codul legat de ShadowsocksR
Securitatea Shadowsocks
Acum, să începem cu descrierea afirmației autorului ShadowsocksR, conform căreia defectul protocolului Shadowsocks este că lungimea IV-ului este de 16 octeți în majoritatea cazurilor. A doua jumătate este corectă, mulți algoritmi de criptare folosesc IV-uri care au 16 octeți (în special popularele AES și RC4-MD5), și ce dacă? Aceasta nu introduce așa-numitele "defecte" din următoarele motive:
IV-ul fiecărei conexiuni TCP în etapa de handshake este generat aleatoriu, nu calculat din parolă, deci IV-ul este imprevizibil.
Fără cheie, chiar dacă această parte a IV-ului este interceptată, textul cifrat nu poate fi decriptat. Și fiecare nouă conexiune TCP folosește un IV generat aleatoriu, adică datele interceptate de la diferite conexiuni TCP au puțin în comun. Decriptarea textului cifrat necesită atât IV-ul corect, cât și cifrul, iar orice conexiune nu are caracteristici legate de cifru.
Majoritatea IV-urilor au 16 octeți, ceea ce este o combinație posibilă de 256 la puterea de 16, și este imposibil să faci o spargere prin forță brută când toate IV-urile sunt la fel, cu atât mai puțin să adaugi un al doilea punct.
Conform abordării ShadowsocksR, este inutil să adaugi așa-numitul antet de obfuscație înainte de prima conexiune, caracteristicile sale sunt evidente și nu schimbă deloc esența IV-ului ulterior sau a lungimii fixe. Pentru că al patrulea octet îți arată lungimea datelor completate aleatoriu, atâta timp cât sari peste grămada anterioară când efectuezi așa-numita "sondare", poți totuși intercepta IV. Și, așa cum am spus acum câteva puncte, este inutil dacă primești acest IV aleatoriu. Dacă este folosit pentru detectare, prima versiune fixă a logo-ului este funcția de "nud" trimisă pentru identificare.
Autorul ShadowsocksR oferă în prezent un script activ de detecție care poate fi folosit pentru a detecta dacă serverul rulează shadowsocks, iar conform rapoartelor actuale de testare online, rata de succes nu este scăzută (dar nici 100%). În această privință, Clowwindy a oferit deja o soluție de interdicție automată în versiunea originală, blocând automat aceste IP-uri malițioase. Tocmai am adăugat un patch în libQtShadowsocks și acest patch blochează detectarea acestei metode, care returnează șiruri aleatorii de lungimi aleatorii în funcție de probabilitatea aleatorie.
Totuși, asta nu înseamnă că protocolul Shadowsocks este perfect, ci că "soluția" ShadowsocksR este strâmbă pentru că focalizarea sa este strâmbă. Ideea mea personală este să folosesc chei publice și chei private pentru a îmbunătăți securitatea, deși nu este foarte prietenos cu începătorii, dar securitatea va fi îmbunătățită, iar caracteristicile vor fi reduse (nu este nevoie să se trimită IV-uri în faza de strângere de mână), iar protocolul shadowsocks trebuie să se dezvolte în direcția securității CCA.
Actualizat la 05-sept-2015
Odată ce eroarea de antet (care nu poate fi rezolvată) este găsită, IV-ul și IP-ul greșit vor fi adăugate în lista IV-urilor și IP eșuate, dacă IV-ul există deja în lista IV-urilor eșuate sau IP-ul există deja în lista IP eșuată, IP-ul care a trimis cererea de conexiune va fi adăugat pe lista neagră, iar IP-ul din lista neagră va respinge direct conexiunea. Pentru cele mai recente detalii despre anti-detecție, vă rugăm să consultați această problemă, iar acest articol nu va actualiza contramăsurile pentru anti-detecție.
Actualizat la 06 septembrie 2015
Acest articol vrea doar să vă spună să nu vă faceți prea multe griji pentru securitatea Shadowsocks, protocolul actual nu a avut încă vulnerabilități majore, iar serverele porturilor principale sunt de asemenea actualizate pentru a corecta potențiale amenințări. Am comunicat bine și cu autorul ShadowsocksR, și va mai dura ceva până va ajunge lista albă.
Actualizat la 24 septembrie 2015
Securitatea Shadowsocks menționată în acest articol se referă mai mult la securitatea serverului, iar protocolul actual riscă să expună serverul la detectarea prin forță brută și apoi să fie blocat de firewall-uri (deși costul detectării este foarte ridicat). Securitatea conținutului transmis nu este de îngrijorat, toate fiind algoritmi industriali de criptare de înaltă putere (cu excepția RC4 și TABLE), iar conținutul transmis este aproape imposibil.
Actualizat la 18 noiembrie 2015
Shadowsocks și-a îmbunătățit securitatea împotriva CCA prin adăugarea unei singure verificare, iar portările majore și-au finalizat deja suportul. Este important de reiterat că scopul Shadowsocks nu este să fie 100% fără bug-uri sau 100% antiglonț, ci să asigure conexiunea ușoară și rapidă, făcând metodele de atac mainstream prea costisitoare de implementat.
|
Postat pe 10.11.2017 12:41:35
|
|
|
