SS est l’original, SSR est une version tierce dérivée de l’original, compatible avec le protocole original, et possède certaines fonctions de camouflage supplémentaires (protocole et confusion) que l’original.
Il y a aussi beaucoup de discussions sur les SSR sur Internet, pour et contre, mais aussi pour les utilisateurs ordinaires. Que ce soit SSR ou SSR, cela peut vous aider à escalader le mur normalement actuellement.
Quant à la version du client que vous téléchargez, tout dépend si SSR ou SSR est installé sur le serveur du compte SS que vous avez acheté. La fonction SS la plus originale peut être utilisée quel que soit le client téléchargé, mais si vous souhaitez utiliser les fonctions SSR (protocole et confusion), vous devez télécharger le client SSR.
Mais ne vous inquiétez pas, tous les nœuds que nous fournissons supportent la compatibilité SS et SSR. Il est recommandé d’utiliser SSR. Plus vite pour éviter d’être harmonisé !
Il y a eu beaucoup de bruit à propos de Shadowsocks il y a quelque temps, et récemment il est clair qu’un grand nombre de novices ont été attirés par les soi-disant « Shadowsocks Enhanced » (ShadowsocksR). En tant que développeur amateur implémentant Shadowsocks en C++/Qt, j’aimerais exprimer brièvement mon opinion sur ces deux poulets frits.
ShadowsocksR
Je ne sais pas si le développeur derrière a un parcours ou une équipe, mais ce que je sais, c’est que son auteur a effectivement fait un code sourcier pour le client Shadowsocks C# pour son développement secondaire, en violation de la GPL. Nous ne parlerons pas ici d’autres facteurs, le fait est que la GPL est très claire en noir sur blanc : violer est violer. Mais l’auteur a ensuite rendu la base de code en open source, ce qui peut être considéré comme la fin d’un incident, et il n’est pas nécessaire d’aller plus loin.
Les choses ont changé après que Clowwindy ait vidé son magasin de codes Shadowsocks. Voici une liste de faits :
L’auteur de ShadowsocksR a déclaré qu’il voulait repartir de zéro pour écrire un nouvel outil proxy qui n’est pas lié à shadowsocks, et ne mettra plus à jour ShadowsocksR
Deux ou trois jours plus tard, ShadowSocks a été ordonné de supprimer ShadowSocks, et le projet original ShadowSocks a pratiquement disparu
L’auteur de ShadowsocksR a déclaré que le protocole original des shadowsocks était défectueux (discuté dans la section suivante) et est revenu au focus
L’auteur de ShadowsocksR a créé un groupe Google+ et mis à jour le code lié à ShadowsocksR
Sécurité des Shadowsocks
Commençons maintenant par la description de l’affirmation de l’auteur de ShadowsocksR selon laquelle la faille du protocole Shadowsocks est que la longueur de l’IV est de 16 octets dans la plupart des cas. La seconde moitié est correcte, beaucoup d’algorithmes de chiffrement utilisent des IV de 16 octets (notamment les populaires AES et RC4-MD5), et alors ? Cela n’introduit pas les soi-disant « défauts » pour les raisons suivantes :
L’IV de chaque connexion TCP à l’étape de la poignée de main est généré aléatoirement, non calculé à partir du mot de passe, donc l’IV est imprévisible.
Sans la clé, même si cette partie de l’IV est interceptée, le texte chiffré ne peut pas être déchiffré. Et chaque nouvelle connexion TCP utilise un IV généré aléatoirement, c’est-à-dire que les données interceptées par différentes connexions TCP ont peu de points communs. Le déchiffrement du texte chiffré nécessite à la fois le bon IV et le chiffre, et toute connexion n’a aucune caractéristique du chiffre.
La plupart des IV font 16 octets, ce qui est une combinaison possible de 256 pour la puissance de 16, et il est impossible de craquer par force brute quand tous les IV sont identiques, sans parler d’ajouter un second point.
Selon l’approche de ShadowsocksR, il est inutile d’ajouter le soi-disant en-tête d’obfuscation avant la première connexion, ses propres caractéristiques sont évidentes, et cela ne change pas du tout l’essence du IV ultérieur ni la longueur fixe. Parce que le quatrième octet indique la longueur des données remplies aléatoirement, tant que vous sautez la pile précédente lors de la soi-disant « sonde », vous pouvez toujours intercepter IV. Et comme je l’ai dit il y a quelques points, c’est inutile si tu obtiens cette IV aléatoire. Si elle est utilisée pour la détection, la première version fixe du logo est la fonction nu envoyée pour identification.
L’auteur de ShadowsocksR fournit actuellement un script de détection active qui peut être utilisé pour détecter si le serveur exécute des shadowsocks, et selon les rapports de test en ligne actuels, le taux de réussite n’est pas faible (mais pas de 100 %). À cet égard, Clowwindy a déjà proposé une solution d’interdiction automatique dans la version originale, bloquant automatiquement ces IP malveillantes. Je viens d’ajouter un patch à libQtShadowsocks et ce patch bloque la détection de cette méthode, qui renvoie des chaînes aléatoires de longueurs aléatoires selon la probabilité aléatoire.
Cependant, cela ne signifie pas que le protocole Shadowsocks est parfait, mais que la « solution » de ShadowsocksR est tordue car son focus est tordu. Mon idée personnelle est d’utiliser des clés publiques et privées pour améliorer la sécurité, même si ce n’est pas très convivial pour les débutants, mais la sécurité sera améliorée, les caractéristiques seront réduites (pas besoin d’envoyer de perfusions au stade de la poignée de main), et le protocole shadowsocks doit évoluer dans la direction de la sécurité CCA.
Mis à jour le 5 sept-2015
Une fois l’erreur d’en-tête (impossible à résoudre possible) détectée, le mauvais IV et IP sera ajouté à la liste IV et IP défaillants ; si l’IV existe déjà dans la liste IV échouée, ou si l’IP existe déjà dans la liste IP échouée, l’IP qui a envoyé la requête de connexion sera ajoutée à la liste noire, et l’IP de la liste noire rejettera directement la connexion. Pour les dernières informations sur l’anti-détection, veuillez consulter ce numéro, et cet article ne mettra pas à jour les contre-mesures pour l’anti-détection.
Mis à jour le 06 sept. 2015
Cet article veut simplement vous dire de ne pas trop vous inquiéter pour la sécurité de Shadowsocks, le protocole actuel n’a pas encore présenté de vulnérabilités majeures, et les serveurs des ports principaux sont également mis à jour pour corriger les menaces potentielles. J’ai aussi bien communiqué avec l’auteur de ShadowsocksR, et il faudra un certain temps avant que la liste blanche n’arrive.
Mis à jour le 24 sept. 2015
La sécurité Shadowsocks mentionnée dans cet article concerne davantage la sécurité du serveur, et le protocole actuel comporte le risque d’exposer le serveur à une détection brutale puis d’être bloqué par des pare-feux (bien que le coût de la détection soit très élevé). La sécurité du contenu transmis n’est pas à craindre, tous étant des algorithmes de chiffrement industriels de haute puissance (sauf RC4 et TABLE), et il est presque impossible de craquer le contenu transmis.
Mis à jour le 18 novembre 2015
Shadowsocks a amélioré sa sécurité contre la CCA en ajoutant une vérification unique, et les principaux ports ont déjà terminé leur prise en charge. Il est important de rappeler que l’objectif de Shadowsocks n’est pas d’être 100 % sans bugs ni 100 % à l’épreuve des balles, mais de garantir que la connexion soit légère et rapide tout en rendant les méthodes d’attaque grand public trop coûteuses à mettre en œuvre.
|
Publié sur 10/11/2017 12:41:35
|
|
|
