Das SingLink-Protokoll ist jetzt Open Source

Heute hat SingLinkLabs, das Team hinter SingLinkVPN, den vollständigen Quellcode des SingLink-Protokolls unter der Apache-2.0-Lizenz auf GitHub veröffentlicht. Ab sofort kann jeder die Spezifikation lesen, den Code ausführen, seine Sicherheit prüfen und darauf aufbauen.

Als wir den Open-Source-Plan von SingLinkVPN vorgestellt haben, kündigten wir an, dass ein VPN-Protokoll und ein VPN-Client schrittweise folgen würden. Das ist dieser Schritt. Das Protokoll erscheint zusammen mit dem Prototyp der ersten Generation der SingLinkVPN-App, der darauf aufbaut – siehe Der Prototyp der SingLinkVPN-App ist jetzt Open Source.

Repository: SingLinkLabs / singlink-protocol · Version: 1.0.0-draft (Wire-Name SingLink/1, Spezifikationsentwurf 2) · Lizenz: Apache-2.0 · Sprache: Go, ausschließlich Standardbibliothek

Was veröffentlicht wird

• Die Spezifikation. SPEC.md beschreibt das Übertragungsformat Byte für Byte, sodass sich das Protokoll unabhängig implementieren lässt.
• Die Protokollbibliothek in Go. Sie nutzt ausschließlich die Kryptografie der Go-Standardbibliothek, ohne Abhängigkeiten von Drittanbietern.
• Ein Kommandozeilenwerkzeug, mit dem du Schlüssel erzeugst, Zugangspässe ausstellst, Verbindungslinks erstellst, einen Knoten und einen Client betreibst und eine Demo auf einem einzigen Rechner startest.
• Ein lokaler Proxy für Apps (SOCKS5 und HTTP) sowie eine C-Bibliotheksschnittstelle (libsinglink), damit Apps auf jeder Plattform das Protokoll einbetten können.
• Beispiele für das Deployment: eine Beispielkonfiguration für einen Knoten und eine gehärtete systemd-Servicedatei.
• Die interne Sicherheitsprüfung mit allen Befunden und Korrekturen: SECURITY-AUDIT.md.

SingLink 2.0 und das offene SingLink-Protokoll sind zwei verschiedene Protokolle

Die offiziellen SingLinkVPN-Apps laufen über unsere Produktionsprotokolle, darunter SingLink 2.0. Der Kern-Quellcode von SingLink 2.0 ist nicht Teil dieser Veröffentlichung und bleibt geschlossen.

Das heute veröffentlichte SingLink-Protokoll – das offene SingLink-Protokoll, wenn es von SingLink 2.0 unterschieden werden muss – ist ein eigenständiges Protokoll, das SingLinkLabs von Grund auf für die offene Entwicklung entworfen hat. Die offiziellen Apps verwenden es derzeit nicht. Für bestehende Nutzer ändert sich nichts: dieselben Apps, dasselbe Konto und dieselben Verbindungen.

Warum wir es als Open Source veröffentlichen

• Sicherheitsversprechen sollten überprüfbar sein. Post-Quanten-Schlüsselaustausch, Gerätebindung und Schutz vor Sondierung sind schnell behauptet. Mit öffentlichem Code und öffentlicher Spezifikation kann jeder sie nachprüfen.
• Mehr Augen finden Probleme früher. Externe Forscher und Ingenieure sehen Probleme, die einem internen Team entgehen.
• Andere können darauf aufbauen. Entwickler können es testen, in eigene Projekte einbetten und Verbesserungen vorschlagen.
• Wir halten Wort. Die Veröffentlichung eines Protokolls war eine der Etappen, die wir versprochen haben.

So funktioniert es, einfach erklärt

Die Idee in einem Satz: Von außen sieht es so aus, als würde der Nutzer einfach eine gewöhnliche HTTPS-Website besuchen. Darin verborgen steckt eine verschlüsselte Zugangsanfrage, und der Server leitet Datenverkehr nur für jemanden weiter, der einen gültigen Pass besitzt.

Das Design verwendet drei Schlüssel. Stell dir die Sicherheit eines Bürogebäudes vor:

• Knotenschlüssel, das Türschloss. Jeder Server hat seinen eigenen. Nur dieser Server kann die Anfrage eines Nutzers öffnen – das beweist zugleich, dass der Nutzer den echten Server erreicht hat.
• Ausstellerschlüssel, der Stempel der Personalabteilung. Er bleibt im Konto-Backend, das jeden Zugangspass mit Tarif, Ablaufdatum, Geschwindigkeitslimit und Gerätelimit abstempelt.
• Geräteschlüssel, der Fingerabdruck des Nutzers. Er bleibt auf dem Smartphone oder Computer des Nutzers und signiert jede Verbindung. So ist belegt, dass der Pass von seinem rechtmäßigen Inhaber verwendet wird.

Ein Server muss nur wissen, wie der Stempel aussieht, um einen Pass selbstständig zu prüfen. Deshalb führen Knoten keine Nutzerdatenbank und speichern keine Nutzerdaten.

Was bei einer Verbindung passiert

1. Die App baut eine Verbindung auf, die wie eine gewöhnliche HTTPS-Verbindung zu einer Website aussieht.
2. Ihr erstes Paket enthält einen Einmalschlüssel für diese Verbindung, einen Post-Quanten-Chiffretext und einen versiegelten Abschnitt mit dem Ziel, dem Zugangspass, bis zu den ersten 8 KB echter Daten und einer Gerätesignatur über die gesamte Anfrage. Ein zusätzlicher Roundtrip ist nicht nötig.
3. Der Server prüft alles: ob er die Anfrage entschlüsseln kann, ob der Stempel echt ist, ob die Gerätesignatur passt, ob die Zeit stimmt und ob die Anfrage weder eine Wiederholung noch abgelaufen oder widerrufen ist.
4. Nur wenn jede Prüfung bestanden ist, antwortet er und beginnt mit der Weiterleitung. Schlägt eine Prüfung fehl, wird die Verbindung unverändert an eine echte Website übergeben. Wer den Server sondiert, sieht immer nur eine gewöhnliche Website, ohne Unterschied im Timing.
5. Beide Seiten kombinieren ihre Einmalschlüssel zu den Sitzungsschlüsseln dieser Verbindung. Die Daten werden in Blöcken verschlüsselt, die ersten Blöcke werden aufgefüllt, und die Schlüssel werden nach einer festgelegten Nutzungsmenge automatisch ersetzt.

Sicherheitseigenschaften

• Zwei Verschlüsselungsebenen. Außen HTTPS, innen die eigene AES-256-GCM-Schicht des Protokolls – so kann selbst ein CDN, das HTTPS terminiert, den Inhalt nicht sehen.
• Post-Quanten-Schutz. Der Schlüsselaustausch kombiniert klassisches X25519 mit ML-KEM-768 (FIPS 203). Ein Angreifer müsste beides brechen.
• Forward Secrecy. Jede Verbindung nutzt Einmalschlüssel, sodass ein später kompromittierter Server früheren Datenverkehr nicht entschlüsseln kann. Die Ausnahme ist das erste Paket (siehe Einschränkungen unten).
• Gerätebindung. Ein irgendwo kopierter Zugangspass ist ohne den Geräteschlüssel, für den er ausgestellt wurde, nutzlos.
• Schutz vor Replay-Angriffen. Ein mitgeschnittenes Paket erneut zu senden funktioniert nicht, auch nicht nach einem Serverneustart.
• Resistenz gegen Sondierung. Abgelaufene, widerrufene, wiederholte oder gefälschte Anfragen werden alle gleich behandelt: Sie werden an die echte Website übergeben.
• Zentrale Kontrolle. Wird ein Konto oder ein Gerät widerrufen, werden seine aktiven Verbindungen auf allen Servern innerhalb von etwa 10 Sekunden getrennt.
• Gehärtete Server. Verbindungslimits pro Server und pro IP, ein CPU-Budget für Handshakes und eine vollständige Sperrliste für private Adressen und Adressen für besondere Zwecke.

Woher die Ideen stammen

Das SingLink-Protokoll lernt von bewährten Designs: Verbindungen mit einer einzigen Anfrage von VLESS und Trojan, die Übergabe fehlgeschlagener Verbindungen an eine echte Website von Trojan und obfs4, das Handshake-Muster Noise NK, Schlüsselableitung und 0-RTT-Behandlung von TLS 1.3, hybrider Post-Quanten-Schlüsselaustausch aus dem Standardentwurf X-Wing, blockweise Verschlüsselung von Shadowsocks AEAD, signierte Tokens von JWT und PASETO, gerätegebundene Tokens von OAuth DPoP, das HAProxy PROXY protocol sowie Replay- und Lastschutz von WireGuard.

Es handelt sich ausschließlich um Designideen. Der gesamte Code wurde von Grund auf neu geschrieben. Er enthält keinen Code aus Xray, V2Ray, sing-box oder WireGuard.

Aktueller Stand und bekannte Einschränkungen

• Es ist ein Entwurf. Die Version ist 1.0.0-draft, und das Übertragungsformat kann sich noch ändern.
• Bisher nur eine interne Sicherheitsprüfung. Zwei Prüfer haben das kryptografische Design und die Implementierung getrennt untersucht und 31 Befunde festgehalten: 2 mit hohem, 14 mit mittlerem und der Rest mit niedrigem Schweregrad oder rein informativ. Keiner davon hebelte die Vertraulichkeit oder Authentifizierung des Nutzerverkehrs aus. Alle Befunde mit hohem und mittlerem Schweregrad sind behoben oder entschärft, jeweils mit einem Regressionstest, und jeder Parser ist durch Fuzz-Tests abgedeckt.
• Noch kein Audit durch Dritte. Wir empfehlen, sich bei risikoreichen Einsätzen nicht auf das Protokoll zu verlassen, bis es unabhängig auditiert wurde. Ein solches Audit planen wir, bevor wir es als stabil bezeichnen.
• Das erste Paket hat keine Forward Secrecy. Es ist durch den langfristigen Schlüssel des Servers geschützt, daher sollten Serverschlüssel regelmäßig rotiert werden. Schlüsselrotation wird unterstützt.
• In Festlandchina nicht praxiserprobt. Sein TLS-Fingerabdruck und die Größe des ersten Pakets sind noch unterscheidbar. Für Nutzer in Festlandchina verwenden die offiziellen SingLinkVPN-Apps weiterhin unsere bestehenden Produktionsprotokolle.
• Ein Server braucht eine eigene Domain, ein Zertifikat, das Browser akzeptieren, und eine echte Website dahinter.

Ausprobieren und mitmachen

Mit Go 1.24 oder neuer führt make test die Testsuite aus, make cli baut das Kommandozeilenwerkzeug, und singlink demo startet einen lokalen Server und Client auf einem einzigen Rechner. Die README im Repository erklärt, wie man einen Server betreibt.

Fragen, Fehlerberichte und Pull Requests sind auf GitHub willkommen. Bitte melde Sicherheitslücken vertraulich und nicht in einem öffentlichen Issue – das Verfahren ist in SECURITY.md beschrieben.

Lizenz und Marken

Der Code steht unter der Apache-2.0-Lizenz: Du darfst ihn gemäß den Lizenzbedingungen nutzen, verändern und weitergeben, auch kommerziell. Die Namen „SingLink“ und „SingLinkVPN“ sowie das Logo sind Marken von SingLinkLabs, und die Lizenz gewährt kein Recht, sie über die Angabe der Herkunft des Werks hinaus zu verwenden. Angepasste Versionen und Forks sollten unter eigenem Namen und mit eigenem Icon veröffentlicht werden.

Weiterlesen

• Der Prototyp der SingLinkVPN-App ist jetzt Open Source – und sein Code auf GitHub
• Open-Source-Projekte von SingLinkLabs
• Technisches Whitepaper zu SingLink 2.0, das Produktionsprotokoll der offiziellen Apps