SS ist das Original, SSR ist eine Drittanbieterversion, die vom Original abgeleitet ist, mit dem Originalprotokoll kompatibel ist und mehr Tarnfunktionen (Protokoll und Verwirrung) besitzt als das Original.
Es gibt auch viele Diskussionen über SSR im Internet, sowohl für als auch dagegen, aber für gewöhnliche Nutzer. Ob es SS oder SSR ist, es kann dir derzeit helfen, normal über die Mauer zu klettern.
Welche Version des Clients du herunterlädst, hängt ganz davon ab, ob SS oder SSR auf dem Server des SS-Kontos installiert ist, das du gekauft hast. Die originellste SS-Funktion kann unabhängig vom heruntergeladenen Client verwendet werden, aber wenn du die Funktionen von SSR (Protokoll und Verwirrung) nutzen willst, musst du den SSR-Client herunterladen.
Aber keine Sorge, alle von uns bereitgestellten Knoten unterstützen SS- und SSR-Kompatibilität. Es wird empfohlen, SSR zu verwenden. Schneller, um nicht harmonisiert zu werden!
Vor einiger Zeit gab es viel Rummel um Shadowsocks, und in letzter Zeit ist klar, dass eine große Anzahl von Anfängern vom sogenannten "Shadowsocks Enhanced" (ShadowsocksR) angezogen wurde. Als Amateurentwickler der Implementierung von Shadowsocks in C++/Qt möchte ich kurz meine Meinung zu diesen beiden frittierten Hühnern äußern.
ShadowsocksR
Ich weiß nicht, ob der Entwickler dahinter einen Hintergrund oder ein Team hat, aber was ich weiß, ist, dass der Autor den Shadowsocks C#-Client für die Sekundärentwicklung in Close Source verwendet hat und damit gegen die GPL verstößt. Wir werden hier nicht über andere Faktoren sprechen, Tatsache ist, dass die GPL ganz klar und klar ist: Verstoßen ist Verstoß. Der Autor hat dann jedoch den Code als Open Source veröffentlicht, was als das Ende eines Vorfalls angesehen werden kann, und es besteht keine Notwendigkeit, das weiter zu verfolgen.
Die Dinge änderten sich, nachdem Clowwindy seinen Shadowsocks-Codeladen leerte. Im Folgenden sind nur eine Liste von Fakten:
Der Autor von ShadowsocksR hat gesagt, dass er von vorne anfangen möchte, um ein neues Proxy-Tool zu schreiben, das nichts mit Shadowsocks zu tun hat, und ShadowsocksR nicht mehr aktualisieren wird
Zwei oder drei Tage später wurde die Löschung von ShadowSocks angeordnet, und das ursprüngliche Shadowsocks-Projekt verschwand im Grunde
Der Autor von ShadowsocksR sagte, dass das ursprüngliche Shadowsocks-Protokoll fehlerhaft war (im nächsten Abschnitt besprochen) und kehrte wieder in den Fokus zurück
Der Autor von ShadowsocksR hat eine Google+-Gruppe gegründet und den ShadowsocksR-bezogenen Code aktualisiert
Shadowsocks-Sicherheit
Beginnen wir nun mit der Beschreibung der Behauptung des ShadowsocksR-Autors, dass der Fehler des Shadowsocks-Protokolls darin besteht, dass die Länge des IV in den meisten Fällen 16 Bytes beträgt. Der zweite Teil ist korrekt, viele Verschlüsselungsalgorithmen verwenden IVs, die 16 Bytes lang sind (insbesondere das beliebte AES und RC4-MD5), na und? Dies führt aus folgenden Gründen nicht zu sogenannten "Defekten":
Der IV jeder TCP-Verbindung in der Handshake-Phase wird zufällig generiert und nicht aus dem Passwort berechnet, sodass der IV unvorhersehbar ist.
Ohne den Schlüssel kann der Chiffretext selbst dann nicht entschlüsselt werden, wenn dieser Teil des IV abgefangen wird. Und jede neue TCP-Verbindung verwendet eine zufällig generierte IV, das heißt, die von verschiedenen TCP-Verbindungen abgefangenen Daten haben wenig gemeinsam. Das Entschlüsseln von Chiffretext erfordert sowohl den korrekten IV als auch die Chiffre, und jede Verbindung weist keine Merkmale der Chiffre auf.
Die meisten IVs sind 16 Bytes lang, was eine mögliche Kombination von 256 zu einer Potenz von 16 ist, und es ist unmöglich, einen Brute-Force-Crack zu machen, wenn alle IVs gleich sind, geschweige denn einen zweiten Punkt hinzuzufügen.
Nach dem Ansatz von ShadowsocksR ist es nutzlos, den sogenannten Verschleierungskopf vor der ersten Verbindung hinzuzufügen, dessen eigene Eigenschaften offensichtlich sind, und das ändert weder das Wesen des späteren IV noch der festen Länge. Da das vierte Byte dir die Länge der zufällig gefüllten Daten anzeigt, kannst du IV trotzdem abfangen, solange du den vorherigen Stapel beim sogenannten "Probing" überspringst. Und wie ich vor ein paar Punkten sagte, ist es nutzlos, wenn man diese zufällige Infusion bekommt. Wenn es zur Erkennung verwendet wird, ist die feste erste Version des Logos das zur Identifikation gesendete Nacktmerkmal.
Der Autor von ShadowsocksR stellt derzeit ein aktives Erkennungsskript bereit, mit dem erkannt werden kann, ob der Server Shadowsocks ausführt, und laut aktuellen Online-Testberichten ist die Erfolgsquote nicht niedrig (aber nicht 100 %). In diesem Zusammenhang hat Clowwindy bereits in der Originalversion eine automatische Sperrlösung eingeführt, die diese bösartigen IPs automatisch blockiert. Ich habe gerade einen Patch zu libQtShadowsocks hinzugefügt und dieser Patch blockiert die Erkennung dieser Methode, die zufällige Strings zufälliger Länge entsprechend der zufälligen Wahrscheinlichkeit zurückgibt.
Das bedeutet jedoch nicht, dass das Shadowsocks-Protokoll perfekt ist, sondern dass die "Lösung" von ShadowsocksR schief ist, weil sein Fokus schief ist. Meine persönliche Idee ist, öffentliche und private Schlüssel zu verwenden, um die Sicherheit zu verbessern, auch wenn es für Anfänger nicht sehr freundlich ist, aber die Sicherheit wird verbessert und die Eigenschaften werden reduziert (keine IVs in der Handshake-Phase mehr senden), und das Shadowsocks-Protokoll muss sich in Richtung CCA-Sicherheit entwickeln.
Aktualisiert am 05. September 2015
Sobald der Headerfehler (der nicht behoben werden kann) gefunden wird, werden die falsche IV und IP zur Liste der fehlgeschlagenen IV und IPs hinzugefügt; wenn die IV bereits in der Liste der fehlgeschlagenen IVs existiert oder die IP bereits in der Liste der fehlgeschlagenen IPs existiert, wird die IP, die die Verbindungsanfrage gesendet hat, auf die schwarze Liste gesetzt und die IP in der schwarzen Liste lehnt die Verbindung direkt ab. Für die neuesten Details zur Anti-Erkennung siehe bitte dieses Problem, und dieser Artikel aktualisiert die Gegenmaßnahmen zur Anti-Erkennung nicht.
Aktualisiert am 06. September 2015
Dieser Artikel möchte dir nur sagen, dass du dir nicht zu viele Sorgen um die Sicherheit von Shadowsocks machen solltest, das aktuelle Protokoll hat bisher keine größeren Schwachstellen und die Server der Hauptports werden ebenfalls aktualisiert, um potenzielle Bedrohungen zu beheben. Ich habe auch gut mit dem Autor von ShadowsocksR kommuniziert, und es wird noch eine Weile dauern, bis die Whitelist erscheint.
Aktualisiert am 24. September 2015
Die in diesem Artikel erwähnte Shadowsocks-Sicherheit bezieht sich eher auf die Sicherheit des Servers, und das aktuelle Protokoll birgt das Risiko, den Server einer Brute-Force-Erkennung auszusetzen und dann von Firewalls blockiert zu werden (obwohl die Kosten für die Erkennung sehr hoch sind). Die Sicherheit des übertragenen Inhalts ist nicht zu befürchten, da es sich alle um industrielle, hochstarke Verschlüsselungsalgorithmen handelt (außer RC4 und TABLE), und es ist nahezu unmöglich, den übertragenen Inhalt zu knacken.
Aktualisiert am 18. November 2015
Shadowsocks hat seine Sicherheit gegen CCA durch eine einzige Verifikation verbessert, und große Ports haben ihre Unterstützung bereits abgeschlossen. Es ist wichtig zu betonen, dass das Ziel von Shadowsocks nicht darin besteht, 100 % fehlerfrei oder 100 % kugelsicher zu sein, sondern sicherzustellen, dass die Verbindung leicht und schnell ist, während gängige Angriffsmethoden zu teuer in der Implementierung sind.
|
Veröffentlicht am 10.11.2017 12:41:35
|
|
|
