SS è l'originale, SSR è una versione di terze parti derivata dall'originale, compatibile con il protocollo originale, e ha alcune funzioni di mimetizzazione (protocollo e confusione) più diverse dell'originale.
C'è anche molta discussione sull'SSR su Internet, sia a favore che contro, ma anche per gli utenti comuni. Che sia SSR o SSR, può aiutarti a scavalcare il muro normalmente al momento.
Per quanto riguarda la versione del client che scaricare, dipende tutto dal fatto che SSR o SSR sia installato sul server dell'account SS che hai acquistato. La funzione SS più originale può essere utilizzata indipendentemente dal client scaricato, ma se vuoi usare le funzioni SSR (protocollo e confusione), devi scaricare il client SSR.
Ma non preoccuparti, tutti i nodi che forniamo supportano la compatibilità tra SS e SSR. Si consiglia di usare SSR. Più veloce per evitare di essere armonizzati!
Tempo fa si è parlato molto di Shadowsocks, e recentemente è chiaro che un gran numero di principianti è stato attratto dai cosiddetti "Shadowsocks Enhanced" (ShadowsocksR). Come sviluppatore dilettante che implementa Shadowsocks in C++/Qt, vorrei esprimere brevemente la mia opinione su questi due polli fritti.
ShadowsocksR
Non so se lo sviluppatore abbia un background o un team, ma quello che so è che l'autore ha effettivamente fatto un backsourcing del client C# di Shadowsocks per il suo sviluppo secondario, in violazione della GPL. Non parleremo di altri fattori qui, il fatto è che la GPL è molto chiara in bianco e nero, violare è violare. Ma l'autore ha poi reso open source la base di codice, il che può essere considerato la fine di un incidente, e non c'è bisogno di approfondire.
Le cose cambiarono dopo che Clowwindy svuotò il suo negozio di codice Shadowsocks. Di seguito sono riportati solo un elenco di fatti:
L'autore di ShadowsocksR ha detto di voler ricominciare da zero per scrivere un nuovo strumento proxy non collegato a shadowsocks, e non aggiornerà più ShadowsocksR
Due o tre giorni dopo, ShadowSocks fu ordinato di cancellare e il progetto originale di ShadowSocks praticamente scomparve
L'autore di ShadowsocksR ha detto che il protocollo originale di shadowsocks era difettoso (discusso nella sezione successiva) e è tornato a concentrarsi
L'autore di ShadowsocksR ha creato un gruppo Google+ e aggiornato il codice correlato a ShadowsocksR
Sicurezza dei Shadowsocks
Ora, iniziamo con la descrizione dell'affermazione dell'autore di ShadowsocksR secondo cui il difetto del protocollo di Shadowsocks è che la lunghezza dell'IV è di 16 byte nella maggior parte dei casi. La seconda metà è corretta, molti algoritmi di crittografia usano IV lunghi 16 byte (soprattutto i popolari AES e RC4-MD5), e allora? Questo non introduce i cosiddetti "difetti" per i seguenti motivi:
L'IV di ogni connessione TCP nella fase di handshake viene generato casualmente, non calcolato dalla password, quindi l'IV è imprevedibile.
Senza la chiave, anche se questa parte dell'IV viene intercettata, il testo cifrato non può essere decifrato. E ogni nuova connessione TCP utilizza un IV generato casualmente, cioè i dati intercettati da diverse connessioni TCP hanno poco in comune. Decifrare il testo cifrato richiede sia il IV corretto che il cifrario, e qualsiasi connessione non ha caratteristiche riguardo al cifrario.
La maggior parte degli IV è lunga 16 byte, che è una possibile combinazione di 256 a potenza di 16, ed è impossibile fare una brute force crack quando tutti gli IV sono uguali, figuriamoci aggiungere un secondo punto.
Secondo l'approccio di ShadowsocksR, è inutile aggiungere il cosiddetto header di offuscazione prima della prima connessione, le sue caratteristiche sono evidenti e non cambia affatto l'essenza del IV successivo o della lunghezza fissa. Poiché il quarto byte ti indica la lunghezza dei dati riempiti casualmente, finché salti la pila precedente durante la cosiddetta "sondaggio", puoi comunque intercettare IV. E come ho detto qualche punto fa, è inutile se ottieni questo IV casuale. Se viene usato per il rilevamento, la prima versione fissa del logo è la caratteristica nuda inviata per identificazione.
L'autore di ShadowsocksR attualmente fornisce uno script di rilevamento attivo che può essere utilizzato per rilevare se il server sta eseguendo shadowsocks e, secondo i rapporti di test online attuali, il tasso di successo non è basso (ma non del 100%). A tal proposito, Clowwindy ha già fornito una soluzione di divieto automatico nella versione originale, bloccando automaticamente questi IP dannosi. Ho appena aggiunto una patch a libQtShadowsocks e questa patch blocca il rilevamento di questo metodo, che restituisce stringhe casuali di lunghezza casuale in base alla probabilità casuale.
Tuttavia, questo non significa che il protocollo Shadowsocks sia perfetto, ma che la "soluzione" di ShadowsocksR sia storta perché il suo focus è storto. La mia idea personale è di usare chiavi pubbliche e private per migliorare la sicurezza, anche se non è molto amichevole per i principianti, ma la sicurezza sarà migliorata e le caratteristiche ridotte (non c'è bisogno di inviare IV nella fase di handshake), e il protocollo shadowsocks deve svilupparsi nella direzione della sicurezza CCA.
Aggiornato il 05-set-2015
Una volta trovato l'errore dell'intestazione (impossibile da risolvere), l'IV e l'IP sbagliati verranno aggiunti all'IV e alla lista IP falliti; se l'IV esiste già nella lista IV fallita, o l'IP già esiste nella lista IP fallita, l'IP che ha inviato la richiesta di connessione verrà aggiunto alla blacklist e l'IP nella blacklist rifiuterà direttamente la connessione. Per i dettagli più recenti sull'anti-rilevamento, si prega di fare riferimento a questo numero e questo articolo non aggiornerà le contromisure per l'anti-rilevamento.
Aggiornato il 06-set-2015
Questo articolo vuole solo dirvi di non preoccuparvi troppo della sicurezza di Shadowsocks, il protocollo attuale non ha ancora avuto vulnerabilità significative e anche i server delle porte principali sono in fase di aggiornamento per correggere potenziali minacce. Ho anche comunicato bene con l'autore di ShadowsocksR, e passerà un po' di tempo prima che arrivi la whitelist.
Aggiornato il 24-set-2015
La sicurezza Shadowsocks menzionata in questo articolo si riferisce più alla sicurezza del server, e il protocollo attuale comporta il rischio di esporre il server a una rilevazione di forza bruta e poi essere bloccato dai firewall (anche se il costo del rilevamento è molto elevato). La sicurezza dei contenuti trasmessi non è da preoccupare, tutti sono algoritmi di crittografia ad alta potenza di livello industriale (eccetto RC4 e TABLE), ed è quasi impossibile decifrare il contenuto trasmesso.
Aggiornato il 18-Nov-2015
Shadowsocks ha migliorato la sua sicurezza contro il CCA aggiungendo una sola verifica, e i principali porti hanno già completato il supporto. È importante ribadire che l'obiettivo di Shadowsocks non è essere 100% senza bug o 100% a prova di proiettile, ma garantire che la connessione sia leggera e veloce, rendendo i metodi di attacco mainstream troppo costosi da implementare.
|
Pubblicato su 10/11/2017 12:41:35
|
|
|
