Today SingLinkLabs, the team behind SingLinkVPN, published the full source code of the SingLink Protocol on GitHub under the Apache-2.0 license. Anyone can now read the specification, run the code, review its security and build on it.

When we launched the SingLinkVPN open-source plan, we said a VPN protocol and a VPN client would follow in stages. This is that step. The protocol is released together with the first-generation prototype of the SingLinkVPN app, which runs on it — see the SingLinkVPN app prototype is now open source.

Repository: SingLinkLabs / singlink-protocol · Version: 1.0.0-draft (wire name SingLink/1, specification draft 2) · License: Apache-2.0 · Language: Go, standard library only

What is being released

  • The specification. SPEC.md describes the wire format byte by byte, so the protocol can be implemented independently.

  • The protocol library in Go. It uses only the cryptography in the Go standard library, with no third-party dependencies.

  • A command-line tool to generate keys, issue access passes, create connection links, run a node and a client, and start a one-machine demo.

  • A local proxy for apps (SOCKS5 and HTTP) and a C library interface (libsinglink), so apps on any platform can embed the protocol.

  • Deployment examples: a sample node configuration and a hardened systemd service file.

  • The internal security review, with every finding and fix: SECURITY-AUDIT.md.

The official SingLinkVPN apps run on our production protocols, including SingLink 2.0. The core source code of SingLink 2.0 is not part of this release and remains closed.

The SingLink Protocol published today — the SingLink Open Protocol, when it needs to be told apart from SingLink 2.0 — is a separate protocol that SingLinkLabs designed from scratch for open development. The official apps do not use it today. Nothing changes for existing users: the same apps, the same account and the same connections.

Why we are open-sourcing it

  • Security claims should be checkable. Post-quantum key exchange, device binding and probe resistance are easy to claim. With the code and the specification public, anyone can verify them.

  • More eyes find problems sooner. Outside researchers and engineers will see issues that an internal team misses.

  • Others can build on it. Developers can test it, embed it in their own projects and propose improvements.

  • It follows through on our plan. Publishing a protocol was one of the stages we promised.

How it works, in plain language

The idea in one sentence: from the outside, the user is simply visiting an ordinary HTTPS website. Hidden inside is an encrypted access request, and the server only relays traffic for someone holding a valid pass.

The design uses three keys. Think of the security of an office building:

  • Node key, the door lock. Every server has its own. Only that server can open a user's request, which also proves the user reached the real server.

  • Issuer key, the HR department's stamp. It stays with the account backend, which stamps each access pass with the plan, expiry date, speed limit and device limit.

  • Device key, the user's fingerprint. It stays on the user's phone or computer and signs every connection, proving that the pass is being used by its rightful owner.

A server only needs to know what the stamp looks like to check a pass on its own. That is why nodes keep no user database and store no user data.

What happens during one connection

  1. The app opens what looks like an ordinary HTTPS connection to a website.

  2. Its first packet carries a one-time key for this connection, a post-quantum ciphertext, and a sealed section with the destination, the access pass, up to the first 8 KB of real data and a device signature over the whole request. No extra round trip is needed.

  3. The server checks everything: that it can decrypt the request, that the stamp is genuine, that the device signature matches, that the time is right, and that the request is not a replay and not expired or revoked.

  4. Only if every check passes does it answer and start relaying. If any check fails, the connection is handed untouched to a real website. Someone probing the server only ever sees an ordinary website, with no difference in timing.

  5. Both sides combine their one-time keys into this connection's session keys. Data is encrypted in chunks, the first chunks are padded, and keys are replaced automatically after a set amount of use.

Security properties

  • Two layers of encryption. HTTPS on the outside plus the protocol's own AES-256-GCM layer inside, so even a CDN that terminates HTTPS cannot see the content.

  • Post-quantum protection. The key exchange combines classical X25519 with ML-KEM-768 (FIPS 203). An attacker would have to break both.

  • Forward secrecy. Each connection uses one-time keys, so a server compromised later cannot decrypt past traffic. The exception is the first packet (see the limits below).

  • Device binding. An access pass copied from somewhere is useless without the device key it was issued for.

  • Replay protection. Re-sending a captured packet does not work, even after a server restart.

  • Probe resistance. Expired, revoked, replayed or forged requests all receive the same treatment: they are handed to the real website.

  • Central control. When an account or a device is revoked, its live connections on every server are closed within about 10 seconds.

  • Hardened servers. Connection limits per server and per IP, a CPU budget for handshakes, and a complete block list for private and special-purpose addresses.

Where the ideas come from

The SingLink Protocol learns from well-established designs: single-request connections from VLESS and Trojan, handing failed connections to a real website from Trojan and obfs4, the Noise NK handshake pattern, key derivation and 0-RTT handling from TLS 1.3, hybrid post-quantum key exchange from the X-Wing draft standard, chunked encryption from Shadowsocks AEAD, signed tokens from JWT and PASETO, device-bound tokens from OAuth DPoP, the HAProxy PROXY protocol, and replay and load protection from WireGuard.

These are design ideas only. All code was written from scratch. No code from Xray, V2Ray, sing-box or WireGuard is included.

Current status and known limits

  • It is a draft. The version is 1.0.0-draft and the wire format may still change.

  • Only an internal security review so far. Two reviewers examined the cryptographic design and the implementation separately and recorded 31 findings: 2 High, 14 Medium, and the rest Low or informational. None broke the confidentiality or authentication of user traffic. All High and Medium findings are fixed or mitigated, each with a regression test, and every parser is covered by fuzz tests.

  • No third-party audit yet. We recommend not relying on the protocol for high-risk use until it has had an independent audit, which we plan before calling it stable.

  • The first packet is not forward-secret. It is protected by the server's long-term key, so server keys should be rotated regularly. Key rotation is supported.

  • Not field-tested in mainland China. Its TLS fingerprint and first-packet size are still distinguishable. For users in mainland China, the official SingLinkVPN apps keep using our existing production protocols.

  • A server needs its own domain, a certificate that browsers accept, and a real website behind it.

Try it and get involved

With Go 1.24 or later, make test runs the test suite, make cli builds the command-line tool, and singlink demo starts a local server and client on one machine. The README in the repository explains how to run a server.

Questions, bug reports and pull requests are welcome on GitHub. Please report security vulnerabilities privately, not in a public issue — the process is in SECURITY.md.

License and trademarks

The code is licensed under Apache-2.0: you may use, modify and redistribute it, including commercially, under the terms of the license. The names "SingLink" and "SingLinkVPN" and the logo are trademarks of SingLinkLabs, and the license does not grant permission to use them beyond describing where the work comes from. Modified versions and forks should be published under their own name and icon.

Further reading