Le protocole SingLink est désormais open source

Aujourd’hui, SingLinkLabs, l’équipe derrière SingLinkVPN, a publié sur GitHub l’intégralité du code source du protocole SingLink, sous licence Apache-2.0. Chacun peut désormais lire la spécification, exécuter le code, en examiner la sécurité et s’en servir comme base.

Lorsque nous avons lancé le plan open source de SingLinkVPN, nous avions annoncé qu’un protocole VPN et un client VPN suivraient par étapes. Voici cette étape. Le protocole est publié en même temps que le prototype de première génération de l’application SingLinkVPN, qui repose sur lui : voir le prototype de l’application SingLinkVPN est désormais open source.

Dépôt : SingLinkLabs / singlink-protocol · Version : 1.0.0-draft (nom sur le réseau SingLink/1, brouillon de spécification 2) · Licence : Apache-2.0 · Langage : Go, bibliothèque standard uniquement

Ce qui est publié

• La spécification. SPEC.md décrit le format de transmission octet par octet, afin que le protocole puisse être implémenté de façon indépendante.
• La bibliothèque du protocole en Go. Elle n’utilise que la cryptographie de la bibliothèque standard de Go, sans aucune dépendance tierce.
• Un outil en ligne de commande pour générer des clés, émettre des passes d’accès, créer des liens de connexion, faire tourner un nœud et un client, et lancer une démonstration sur une seule machine.
• Un proxy local pour les applications (SOCKS5 et HTTP) et une interface de bibliothèque C (libsinglink), pour que les applications de n’importe quelle plateforme puissent intégrer le protocole.
• Des exemples de déploiement : une configuration de nœud type et un fichier de service systemd renforcé.
• L’audit de sécurité interne, avec chaque constat et chaque correctif : SECURITY-AUDIT.md.

SingLink 2.0 et le protocole ouvert SingLink sont deux protocoles différents

Les applications officielles SingLinkVPN fonctionnent avec nos protocoles de production, dont SingLink 2.0. Le code source principal de SingLink 2.0 ne fait pas partie de cette publication et reste fermé.

Le protocole SingLink publié aujourd’hui (le protocole ouvert SingLink, lorsqu’il faut le distinguer de SingLink 2.0) est un protocole distinct, conçu de zéro par SingLinkLabs pour un développement ouvert. Les applications officielles ne l’utilisent pas aujourd’hui. Rien ne change pour les utilisateurs actuels : mêmes applications, même compte, mêmes connexions.

Pourquoi nous le publions en open source

• Les promesses de sécurité doivent être vérifiables. Échange de clés post-quantique, liaison à l’appareil, résistance au sondage : il est facile de l’affirmer. Avec le code et la spécification publics, chacun peut le vérifier.
• Plus de regards, des problèmes repérés plus tôt. Des chercheurs et ingénieurs extérieurs verront des problèmes qui échappent à une équipe interne.
• D’autres peuvent bâtir dessus. Les développeurs peuvent le tester, l’intégrer à leurs propres projets et proposer des améliorations.
• Nous tenons notre plan. Publier un protocole faisait partie des étapes promises.

Comment ça marche, en termes simples

L’idée en une phrase : vu de l’extérieur, l’utilisateur visite simplement un site HTTPS ordinaire. À l’intérieur se cache une demande d’accès chiffrée, et le serveur ne relaie le trafic que pour la personne qui détient un passe valide.

La conception repose sur trois clés. Imaginez la sécurité d’un immeuble de bureaux :

• La clé de nœud, la serrure de la porte. Chaque serveur a la sienne. Seul ce serveur peut ouvrir la demande d’un utilisateur, ce qui prouve aussi que l’utilisateur a bien atteint le vrai serveur.
• La clé d’émetteur, le tampon du service RH. Elle reste sur le back-end des comptes, qui tamponne chaque passe d’accès avec la formule, la date d’expiration, la limite de débit et la limite d’appareils.
• La clé d’appareil, l’empreinte digitale de l’utilisateur. Elle reste sur le téléphone ou l’ordinateur de l’utilisateur et signe chaque connexion, prouvant que le passe est utilisé par son titulaire légitime.

Il suffit à un serveur de savoir à quoi ressemble le tampon pour vérifier un passe de lui-même. C’est pourquoi les nœuds n’ont aucune base de données d’utilisateurs et ne stockent aucune donnée utilisateur.

Ce qui se passe lors d’une connexion

1. L’application ouvre ce qui ressemble à une connexion HTTPS ordinaire vers un site web.
2. Son premier paquet contient une clé à usage unique pour cette connexion, un chiffré post-quantique et une section scellée renfermant la destination, le passe d’accès, jusqu’aux 8 premiers Ko de données réelles et une signature de l’appareil couvrant toute la demande. Aucun aller-retour supplémentaire n’est nécessaire.
3. Le serveur vérifie tout : qu’il peut déchiffrer la demande, que le tampon est authentique, que la signature de l’appareil correspond, que l’heure est correcte, et que la demande n’est ni rejouée, ni expirée, ni révoquée.
4. Ce n’est que si toutes les vérifications réussissent qu’il répond et commence à relayer. Si l’une d’elles échoue, la connexion est transmise intacte à un vrai site web. Quiconque sonde le serveur ne voit jamais qu’un site web ordinaire, sans aucune différence de temps de réponse.
5. Les deux côtés combinent leurs clés à usage unique pour obtenir les clés de session de cette connexion. Les données sont chiffrées par blocs, les premiers blocs sont complétés par du bourrage, et les clés sont remplacées automatiquement après un volume d’utilisation défini.

Propriétés de sécurité

• Deux couches de chiffrement. HTTPS à l’extérieur, plus la couche AES-256-GCM propre au protocole à l’intérieur : même un CDN qui termine le HTTPS ne peut pas voir le contenu.
• Protection post-quantique. L’échange de clés combine le classique X25519 et ML-KEM-768 (FIPS 203). Un attaquant devrait casser les deux.
• Confidentialité persistante. Chaque connexion utilise des clés à usage unique : un serveur compromis plus tard ne peut pas déchiffrer le trafic passé. L’exception est le premier paquet (voir les limites ci-dessous).
• Liaison à l’appareil. Un passe d’accès copié ailleurs est inutile sans la clé de l’appareil pour lequel il a été émis.
• Protection contre le rejeu. Renvoyer un paquet capturé ne fonctionne pas, même après un redémarrage du serveur.
• Résistance au sondage. Les demandes expirées, révoquées, rejouées ou falsifiées reçoivent toutes le même traitement : elles sont transmises au vrai site web.
• Contrôle centralisé. Lorsqu’un compte ou un appareil est révoqué, ses connexions actives sur tous les serveurs sont fermées en 10 secondes environ.
• Serveurs renforcés. Limites de connexions par serveur et par IP, budget CPU pour les poignées de main, et liste de blocage complète des adresses privées et à usage spécial.

D’où viennent les idées

Le protocole SingLink s’inspire de conceptions éprouvées : les connexions en une seule requête de VLESS et Trojan, le renvoi des connexions échouées vers un vrai site web de Trojan et obfs4, le schéma de poignée de main Noise NK, la dérivation de clés et la gestion du 0-RTT de TLS 1.3, l’échange de clés post-quantique hybride du projet de norme X-Wing, le chiffrement par blocs de Shadowsocks AEAD, les jetons signés de JWT et PASETO, les jetons liés à l’appareil d’OAuth DPoP, le HAProxy PROXY protocol, ainsi que la protection contre le rejeu et la surcharge de WireGuard.

Il ne s’agit que d’idées de conception. Tout le code a été écrit de zéro. Il ne contient aucun code de Xray, V2Ray, sing-box ou WireGuard.

État actuel et limites connues

• C’est un brouillon. La version est 1.0.0-draft et le format de transmission peut encore changer.
• Seulement un audit de sécurité interne pour l’instant. Deux examinateurs ont étudié séparément la conception cryptographique et l’implémentation, et ont consigné 31 constats : 2 de gravité élevée, 14 de gravité moyenne, et le reste de gravité faible ou à titre informatif. Aucun ne compromettait la confidentialité ou l’authentification du trafic des utilisateurs. Tous les constats de gravité élevée et moyenne sont corrigés ou atténués, chacun avec un test de non-régression, et chaque analyseur est couvert par des tests de fuzzing.
• Pas encore d’audit tiers. Nous recommandons de ne pas compter sur le protocole pour des usages à haut risque tant qu’il n’a pas fait l’objet d’un audit indépendant, que nous prévoyons avant de le déclarer stable.
• Le premier paquet n’offre pas de confidentialité persistante. Il est protégé par la clé à long terme du serveur ; les clés des serveurs doivent donc être renouvelées régulièrement. La rotation des clés est prise en charge.
• Pas testé sur le terrain en Chine continentale. Son empreinte TLS et la taille de son premier paquet restent identifiables. Pour les utilisateurs en Chine continentale, les applications officielles SingLinkVPN continuent d’utiliser nos protocoles de production existants.
• Un serveur a besoin de son propre domaine, d’un certificat accepté par les navigateurs et d’un vrai site web derrière lui.

L’essayer et participer

Avec Go 1.24 ou une version ultérieure, make test lance la suite de tests, make cli compile l’outil en ligne de commande, et singlink demo démarre un serveur et un client locaux sur une seule machine. Le README du dépôt explique comment faire tourner un serveur.

Questions, rapports de bugs et pull requests sont les bienvenus sur GitHub. Merci de signaler les vulnérabilités de sécurité en privé, et non dans une issue publique : la procédure est décrite dans SECURITY.md.

Licence et marques

Le code est distribué sous licence Apache-2.0 : vous pouvez l’utiliser, le modifier et le redistribuer, y compris à des fins commerciales, selon les termes de la licence. Les noms « SingLink » et « SingLinkVPN » ainsi que le logo sont des marques de SingLinkLabs, et la licence n’autorise pas leur utilisation au-delà de la mention de l’origine du travail. Les versions modifiées et les forks devraient être publiés sous leur propre nom et avec leur propre icône.

Pour aller plus loin

• Le prototype de l’application SingLinkVPN est désormais open source, et son code sur GitHub
• Les projets open source de SingLinkLabs
• Livre blanc technique de SingLink 2.0, le protocole de production des applications officielles