Sortie de outline-ss-server 1.4, implémentation du proxy Shadowsocks à partir du projet Outline

Le serveur proxy outline-ss-server 1.4 a été publié, utilisant le protocole Shadowsocks pour masquer la nature du trafic, contourner les pare-feu et tromper les systèmes d'inspection des paquets. Le serveur est développé par le projet Outline, qui fournit en outre une liaison d'applications clientes et une interface de contrôle qui vous permet de déployer rapidement des serveurs Shadowsocks multi-utilisateurs basés sur un serveur outline-ss dans des environnements de cloud public ou sur votre propre équipement, gérez-les via une interface web et organisez les accès des utilisateurs par clés . Le code est développé et maintenu par Jigsaw, une division de Google créée pour développer des outils permettant de contourner la censure et d'organiser le libre échange d'informations.

Outline-ss-server est écrit en Go et distribué sous la licence Apache 2.0. Le code du serveur proxy go-shadowsocks2, créé par la communauté des développeurs Shadowsocks, est utilisé comme base. Récemment, l'activité principale du projet Shadowsocks s'est concentrée sur le développement d'un nouveau serveur en langage Rust, et l'implémentation de Go n'a pas été mise à jour depuis plus d'un an et est sensiblement en retard sur les fonctionnalités.

Les différences entre outline-ss-server et go-shadowsocks2 se résument à la prise en charge de la connexion de plusieurs utilisateurs via un seul port réseau, la possibilité d'ouvrir plusieurs ports réseau pour recevoir des connexions, la prise en charge du redémarrage à chaud et les mises à jour de configuration sans interrompre les connexions, la surveillance intégrée et des outils de modification de trafic basés sur la plateforme prometheus .io.

Sortie de outline-ss-server 1.4, implémentation du proxy Shadowsocks à partir du projet Outline

L'outline-ss-server ajoute également une protection contre les requêtes de sonde et les attaques de relecture du trafic. Une attaque via des demandes de vérification vise à déterminer la présence d'un proxy, par exemple, un attaquant peut envoyer des ensembles de données de différentes tailles au serveur Shadowsocks cible et analyser la quantité de données que le serveur lira avant de déterminer une erreur et de fermer la connexion. Une attaque par relecture est basée sur le détournement d'une session entre un client et un serveur, puis sur la tentative de renvoi des données détournées pour déterminer si un proxy existe.

Pour se protéger contre les attaques via des demandes de vérification, le serveur outline-ss-server, lorsque des données incorrectes arrivent, ne met pas fin à la connexion et n'affiche pas d'erreur, mais continue à recevoir des informations, agissant comme une sorte de trou noir. Pour se protéger contre la relecture, les données reçues du client sont en outre vérifiées pour les répétitions par des sommes de contrôle stockées pour les quelques milliers de dernières séquences de poignée de main (maximum 40 20, la taille est définie au démarrage du serveur et consomme 32 octets de mémoire par séquence). Pour bloquer les réponses répétées du serveur, toutes les séquences de prise de contact du serveur utilisent des codes d'authentification HMAC avec des balises XNUMX bits.

En termes de niveau de masquage du trafic, le protocole Shadowsocks dans l'implémentation outline-ss-server est proche du transport enfichable Obfs4 dans le réseau Tor anonyme. Le protocole a été créé pour contourner le système de censure du trafic chinois (le "Grand pare-feu de Chine") et vous permet de masquer assez efficacement le trafic transmis via un autre serveur (le trafic est difficile à identifier en raison de l'attachement d'une graine aléatoire et de la simulation d'un flux continu).

SOCKS5 est utilisé comme protocole pour les demandes de proxy - un proxy avec prise en charge de SOCKS5 est lancé sur le système local, qui tunnelise le trafic vers un serveur distant à partir duquel les demandes sont réellement exécutées. Le trafic entre le client et le serveur est placé dans un tunnel crypté (le cryptage authentifié AEAD_CHACHA20_POLY1305, AEAD_AES_128_GCM et AEAD_AES_256_GCM est pris en charge), cachant le fait de la création dont est la tâche principale de Shadowsocks. Les tunnels TCP et UDP sont pris en charge, ainsi que la création de tunnels arbitraires, non limités à SOCKS5, grâce à l'utilisation de plug-ins, rappelant les transports enfichables dans Tor.

Source: opennet.ru

Ajouter un commentaire