O protocolo SingLink agora é de código aberto

Hoje a SingLinkLabs, a equipe por trás do SingLinkVPN, publicou no GitHub o código-fonte completo do protocolo SingLink, sob a licença Apache-2.0. A partir de agora, qualquer pessoa pode ler a especificação, executar o código, revisar a segurança e construir em cima dele.

Quando lançamos o plano de código aberto do SingLinkVPN, dissemos que um protocolo VPN e um cliente VPN viriam em etapas. Esta é essa etapa. O protocolo é lançado junto com o protótipo de primeira geração do app SingLinkVPN, que roda sobre ele. Veja o protótipo do app SingLinkVPN agora é de código aberto.

Repositório: SingLinkLabs / singlink-protocol · Versão: 1.0.0-draft (nome na rede SingLink/1, rascunho da especificação 2) · Licença: Apache-2.0 · Linguagem: Go, apenas a biblioteca padrão

O que está sendo publicado

• A especificação. O SPEC.md descreve o formato de transmissão byte a byte, para que o protocolo possa ser implementado de forma independente.
• A biblioteca do protocolo em Go. Ela usa apenas a criptografia da biblioteca padrão do Go, sem dependências de terceiros.
• Uma ferramenta de linha de comando para gerar chaves, emitir passes de acesso, criar links de conexão, executar um nó e um cliente e iniciar uma demonstração em uma única máquina.
• Um proxy local para apps (SOCKS5 e HTTP) e uma interface de biblioteca em C (libsinglink), para que apps em qualquer plataforma possam incorporar o protocolo.
• Exemplos de implantação: uma configuração de nó de exemplo e um arquivo de serviço systemd reforçado.
• A revisão de segurança interna, com cada constatação e cada correção: SECURITY-AUDIT.md.

SingLink 2.0 e o protocolo aberto SingLink são protocolos diferentes

Os apps oficiais do SingLinkVPN rodam em nossos protocolos de produção, incluindo o SingLink 2.0. O código-fonte principal do SingLink 2.0 não faz parte deste lançamento e continua fechado.

O protocolo SingLink publicado hoje (o protocolo aberto SingLink, quando é preciso diferenciá-lo do SingLink 2.0) é um protocolo separado, que a SingLinkLabs projetou do zero para desenvolvimento aberto. Os apps oficiais não o utilizam hoje. Nada muda para quem já usa o serviço: os mesmos apps, a mesma conta e as mesmas conexões.

Por que estamos abrindo o código

• Promessas de segurança devem ser verificáveis. É fácil dizer que há troca de chaves pós-quântica, vinculação ao dispositivo e resistência a sondagens. Com o código e a especificação públicos, qualquer pessoa pode conferir.
• Mais olhos encontram problemas mais cedo. Pesquisadores e engenheiros de fora vão perceber falhas que passam despercebidas por uma equipe interna.
• Outros podem construir em cima dele. Desenvolvedores podem testá-lo, incorporá-lo aos próprios projetos e propor melhorias.
• Cumprimos o nosso plano. Publicar um protocolo era uma das etapas que prometemos.

Como funciona, em linguagem simples

A ideia em uma frase: visto de fora, o usuário está simplesmente acessando um site HTTPS comum. Escondido lá dentro há um pedido de acesso criptografado, e o servidor só retransmite o tráfego de quem tem um passe válido.

O projeto usa três chaves. Pense na segurança de um prédio comercial:

• Chave do nó, a fechadura da porta. Cada servidor tem a sua. Só esse servidor consegue abrir o pedido de um usuário, o que também comprova que o usuário chegou ao servidor verdadeiro.
• Chave do emissor, o carimbo do RH. Ela fica no back-end de contas, que carimba cada passe de acesso com o plano, a data de validade, o limite de velocidade e o limite de dispositivos.
• Chave do dispositivo, a impressão digital do usuário. Ela fica no celular ou no computador do usuário e assina cada conexão, comprovando que o passe está sendo usado pelo seu legítimo dono.

Para conferir um passe por conta própria, o servidor só precisa saber como é o carimbo. É por isso que os nós não têm banco de dados de usuários nem armazenam dados de usuários.

O que acontece em uma conexão

1. O app abre o que parece ser uma conexão HTTPS comum com um site.
2. O primeiro pacote leva uma chave de uso único para esta conexão, um texto cifrado pós-quântico e uma seção lacrada com o destino, o passe de acesso, até os primeiros 8 KB de dados reais e uma assinatura do dispositivo sobre todo o pedido. Nenhuma viagem de ida e volta extra é necessária.
3. O servidor confere tudo: se consegue descriptografar o pedido, se o carimbo é autêntico, se a assinatura do dispositivo confere, se o horário está correto e se o pedido não é uma repetição nem está expirado ou revogado.
4. Só se todas as verificações passarem ele responde e começa a retransmitir. Se qualquer uma falhar, a conexão é entregue intacta a um site real. Quem sonda o servidor só vê um site comum, sem diferença no tempo de resposta.
5. Os dois lados combinam suas chaves de uso único para gerar as chaves de sessão desta conexão. Os dados são criptografados em blocos, os primeiros blocos recebem preenchimento e as chaves são trocadas automaticamente após um volume de uso definido.

Propriedades de segurança

• Duas camadas de criptografia. HTTPS por fora e a camada AES-256-GCM do próprio protocolo por dentro, de modo que nem mesmo uma CDN que termina o HTTPS consegue ver o conteúdo.
• Proteção pós-quântica. A troca de chaves combina o clássico X25519 com o ML-KEM-768 (FIPS 203). Um atacante teria de quebrar os dois.
• Sigilo futuro (forward secrecy). Cada conexão usa chaves de uso único, então um servidor comprometido mais tarde não consegue descriptografar o tráfego anterior. A exceção é o primeiro pacote (veja as limitações abaixo).
• Vinculação ao dispositivo. Um passe de acesso copiado de algum lugar é inútil sem a chave do dispositivo para o qual foi emitido.
• Proteção contra repetição. Reenviar um pacote capturado não funciona, nem mesmo depois de reiniciar o servidor.
• Resistência a sondagens. Pedidos expirados, revogados, repetidos ou forjados recebem o mesmo tratamento: são entregues ao site real.
• Controle central. Quando uma conta ou um dispositivo é revogado, as conexões ativas dele em todos os servidores são encerradas em cerca de 10 segundos.
• Servidores reforçados. Limites de conexão por servidor e por IP, um orçamento de CPU para handshakes e uma lista de bloqueio completa para endereços privados e de uso especial.

De onde vêm as ideias

O protocolo SingLink aprende com projetos consagrados: conexões com um único pedido, do VLESS e do Trojan; a entrega de conexões que falham a um site real, do Trojan e do obfs4; o padrão de handshake Noise NK; a derivação de chaves e o tratamento de 0-RTT do TLS 1.3; a troca de chaves pós-quântica híbrida do rascunho de padrão X-Wing; a criptografia em blocos do Shadowsocks AEAD; tokens assinados, do JWT e do PASETO; tokens vinculados ao dispositivo, do OAuth DPoP; o HAProxy PROXY protocol; e a proteção contra repetição e sobrecarga do WireGuard.

São apenas ideias de projeto. Todo o código foi escrito do zero. Nenhum código do Xray, V2Ray, sing-box ou WireGuard foi incluído.

Situação atual e limitações conhecidas

• É um rascunho. A versão é 1.0.0-draft, e o formato de transmissão ainda pode mudar.
• Até agora, apenas uma revisão de segurança interna. Dois revisores examinaram separadamente o projeto criptográfico e a implementação e registraram 31 constatações: 2 de gravidade alta, 14 de gravidade média e o restante de gravidade baixa ou informativas. Nenhuma comprometia a confidencialidade ou a autenticação do tráfego dos usuários. Todas as constatações de gravidade alta e média foram corrigidas ou mitigadas, cada uma com um teste de regressão, e todos os parsers são cobertos por testes de fuzzing.
• Ainda sem auditoria independente. Recomendamos não depender do protocolo para usos de alto risco até que ele passe por uma auditoria independente, que planejamos fazer antes de declará-lo estável.
• O primeiro pacote não tem sigilo futuro. Ele é protegido pela chave de longo prazo do servidor, por isso as chaves dos servidores devem ser trocadas regularmente. A rotação de chaves é suportada.
• Não testado em campo na China continental. A impressão digital TLS e o tamanho do primeiro pacote ainda são distinguíveis. Para usuários na China continental, os apps oficiais do SingLinkVPN continuam usando nossos protocolos de produção atuais.
• Um servidor precisa de domínio próprio, de um certificado aceito pelos navegadores e de um site real por trás.

Experimente e participe

Com Go 1.24 ou mais recente, make test executa a suíte de testes, make cli compila a ferramenta de linha de comando e singlink demo inicia um servidor e um cliente locais em uma única máquina. O README do repositório explica como executar um servidor.

Perguntas, relatos de bugs e pull requests são bem-vindos no GitHub. Relate vulnerabilidades de segurança de forma privada, e não em uma issue pública. O processo está descrito no SECURITY.md.

Licença e marcas

O código é licenciado sob a Apache-2.0: você pode usá-lo, modificá-lo e redistribuí-lo, inclusive para fins comerciais, nos termos da licença. Os nomes "SingLink" e "SingLinkVPN" e o logotipo são marcas da SingLinkLabs, e a licença não concede permissão para usá-los além de indicar a origem do trabalho. Versões modificadas e forks devem ser publicados com nome e ícone próprios.

Leia também

• O protótipo do app SingLinkVPN agora é de código aberto, e o código dele no GitHub
• Projetos de código aberto da SingLinkLabs
• Whitepaper técnico do SingLink 2.0, o protocolo de produção dos apps oficiais