El protocolo SingLink ya es de código abierto

Hoy SingLinkLabs, el equipo detrás de SingLinkVPN, ha publicado en GitHub el código fuente completo del protocolo SingLink bajo la licencia Apache-2.0. Desde ahora, cualquiera puede leer la especificación, ejecutar el código, revisar su seguridad y construir sobre él.

Cuando presentamos el plan de código abierto de SingLinkVPN, dijimos que un protocolo VPN y un cliente VPN llegarían por etapas. Este es ese paso. El protocolo se publica junto con el prototipo de primera generación de la app SingLinkVPN, que funciona sobre él: consulta el prototipo de la app SingLinkVPN ya es de código abierto.

Repositorio: SingLinkLabs / singlink-protocol · Versión: 1.0.0-draft (nombre en la red SingLink/1, borrador de especificación 2) · Licencia: Apache-2.0 · Lenguaje: Go, solo con la biblioteca estándar

Qué se publica

• La especificación. SPEC.md describe el formato de transmisión byte a byte, para que el protocolo pueda implementarse de forma independiente.
• La biblioteca del protocolo en Go. Solo usa la criptografía de la biblioteca estándar de Go, sin dependencias de terceros.
• Una herramienta de línea de comandos para generar claves, emitir pases de acceso, crear enlaces de conexión, ejecutar un nodo y un cliente, e iniciar una demostración en una sola máquina.
• Un proxy local para apps (SOCKS5 y HTTP) y una interfaz de biblioteca en C (libsinglink), para que las apps de cualquier plataforma puedan integrar el protocolo.
• Ejemplos de despliegue: una configuración de nodo de ejemplo y un archivo de servicio systemd reforzado.
• La revisión de seguridad interna, con cada hallazgo y cada corrección: SECURITY-AUDIT.md.

SingLink 2.0 y el protocolo abierto SingLink son protocolos distintos

Las apps oficiales de SingLinkVPN funcionan con nuestros protocolos de producción, entre ellos SingLink 2.0. El código fuente principal de SingLink 2.0 no forma parte de esta publicación y sigue siendo cerrado.

El protocolo SingLink que publicamos hoy (el protocolo abierto SingLink, cuando hay que distinguirlo de SingLink 2.0) es un protocolo independiente que SingLinkLabs diseñó desde cero para un desarrollo abierto. Las apps oficiales no lo usan actualmente. Para los usuarios actuales no cambia nada: las mismas apps, la misma cuenta y las mismas conexiones.

Por qué lo publicamos como código abierto

• Las afirmaciones de seguridad deben poder comprobarse. Es fácil afirmar que hay intercambio de claves poscuántico, vinculación al dispositivo y resistencia al sondeo. Con el código y la especificación públicos, cualquiera puede verificarlo.
• Más ojos encuentran antes los problemas. Investigadores e ingenieros externos verán fallos que a un equipo interno se le escapan.
• Otros pueden construir sobre él. Los desarrolladores pueden probarlo, integrarlo en sus propios proyectos y proponer mejoras.
• Cumplimos nuestro plan. Publicar un protocolo era una de las etapas que prometimos.

Cómo funciona, en palabras sencillas

La idea en una frase: desde fuera, el usuario simplemente está visitando un sitio web HTTPS corriente. Dentro va oculta una solicitud de acceso cifrada, y el servidor solo retransmite tráfico para quien tenga un pase válido.

El diseño usa tres claves. Piensa en la seguridad de un edificio de oficinas:

• Clave de nodo, la cerradura de la puerta. Cada servidor tiene la suya. Solo ese servidor puede abrir la solicitud de un usuario, lo que además demuestra que el usuario llegó al servidor auténtico.
• Clave del emisor, el sello del departamento de Recursos Humanos. Se queda en el backend de cuentas, que sella cada pase de acceso con el plan, la fecha de caducidad, el límite de velocidad y el límite de dispositivos.
• Clave del dispositivo, la huella dactilar del usuario. Se queda en el teléfono o el ordenador del usuario y firma cada conexión, lo que demuestra que el pase lo está usando su legítimo titular.

A un servidor le basta con saber cómo es el sello para comprobar un pase por su cuenta. Por eso los nodos no tienen base de datos de usuarios ni guardan datos de los usuarios.

Qué ocurre durante una conexión

1. La app abre lo que parece una conexión HTTPS corriente a un sitio web.
2. Su primer paquete lleva una clave de un solo uso para esta conexión, un texto cifrado poscuántico y una sección sellada con el destino, el pase de acceso, hasta los primeros 8 KB de datos reales y una firma del dispositivo sobre toda la solicitud. No hace falta ningún viaje de ida y vuelta adicional.
3. El servidor lo comprueba todo: que puede descifrar la solicitud, que el sello es auténtico, que la firma del dispositivo coincide, que la hora es correcta y que la solicitud no es una repetición ni ha caducado ni ha sido revocada.
4. Solo si se superan todas las comprobaciones responde y empieza a retransmitir. Si alguna falla, la conexión se entrega intacta a un sitio web real. Quien sondee el servidor solo verá un sitio web corriente, sin ninguna diferencia en los tiempos de respuesta.
5. Ambos lados combinan sus claves de un solo uso para obtener las claves de sesión de esta conexión. Los datos se cifran por bloques, los primeros bloques llevan relleno y las claves se sustituyen automáticamente tras una cantidad de uso determinada.

Propiedades de seguridad

• Dos capas de cifrado. HTTPS por fuera y, por dentro, la capa AES-256-GCM propia del protocolo, de modo que ni siquiera una CDN que termine el HTTPS puede ver el contenido.
• Protección poscuántica. El intercambio de claves combina el clásico X25519 con ML-KEM-768 (FIPS 203). Un atacante tendría que romper ambos.
• Confidencialidad directa (forward secrecy). Cada conexión usa claves de un solo uso, así que un servidor comprometido más adelante no puede descifrar tráfico anterior. La excepción es el primer paquete (consulta las limitaciones más abajo).
• Vinculación al dispositivo. Un pase de acceso copiado de algún sitio no sirve de nada sin la clave del dispositivo para el que se emitió.
• Protección contra repeticiones. Reenviar un paquete capturado no funciona, ni siquiera después de reiniciar el servidor.
• Resistencia al sondeo. Las solicitudes caducadas, revocadas, repetidas o falsificadas reciben el mismo trato: se entregan al sitio web real.
• Control centralizado. Cuando se revoca una cuenta o un dispositivo, sus conexiones activas en todos los servidores se cierran en unos 10 segundos.
• Servidores reforzados. Límites de conexiones por servidor y por IP, un presupuesto de CPU para los handshakes y una lista de bloqueo completa para direcciones privadas y de uso especial.

De dónde vienen las ideas

El protocolo SingLink aprende de diseños consolidados: las conexiones de una sola solicitud de VLESS y Trojan, la entrega de conexiones fallidas a un sitio web real de Trojan y obfs4, el patrón de handshake Noise NK, la derivación de claves y el manejo de 0-RTT de TLS 1.3, el intercambio de claves poscuántico híbrido del borrador de estándar X-Wing, el cifrado por bloques de Shadowsocks AEAD, los tokens firmados de JWT y PASETO, los tokens vinculados al dispositivo de OAuth DPoP, el HAProxy PROXY protocol y la protección contra repeticiones y sobrecarga de WireGuard.

Son solo ideas de diseño. Todo el código se escribió desde cero. No incluye código de Xray, V2Ray, sing-box ni WireGuard.

Estado actual y limitaciones conocidas

• Es un borrador. La versión es 1.0.0-draft y el formato de transmisión todavía puede cambiar.
• Por ahora, solo una revisión de seguridad interna. Dos revisores examinaron por separado el diseño criptográfico y la implementación, y registraron 31 hallazgos: 2 de gravedad alta, 14 de gravedad media y el resto de gravedad baja o informativos. Ninguno rompía la confidencialidad ni la autenticación del tráfico de los usuarios. Todos los hallazgos de gravedad alta y media están corregidos o mitigados, cada uno con una prueba de regresión, y todos los analizadores están cubiertos por pruebas de fuzzing.
• Todavía sin auditoría externa. Recomendamos no confiar en el protocolo para usos de alto riesgo hasta que haya pasado una auditoría independiente, que tenemos prevista antes de declararlo estable.
• El primer paquete no tiene confidencialidad directa. Está protegido por la clave a largo plazo del servidor, así que conviene rotar periódicamente las claves de los servidores. Se admite la rotación de claves.
• Sin pruebas reales en China continental. Su huella TLS y el tamaño del primer paquete todavía se pueden distinguir. Para los usuarios en China continental, las apps oficiales de SingLinkVPN siguen usando nuestros protocolos de producción actuales.
• Un servidor necesita su propio dominio, un certificado que acepten los navegadores y un sitio web real detrás.

Pruébalo y participa

Con Go 1.24 o posterior, make test ejecuta el conjunto de pruebas, make cli compila la herramienta de línea de comandos y singlink demo inicia un servidor y un cliente locales en una sola máquina. El README del repositorio explica cómo ejecutar un servidor.

Las preguntas, los informes de errores y los pull requests son bienvenidos en GitHub. Informa de las vulnerabilidades de seguridad de forma privada, no en una issue pública: el proceso está en SECURITY.md.

Licencia y marcas

El código se distribuye bajo la licencia Apache-2.0: puedes usarlo, modificarlo y redistribuirlo, también con fines comerciales, según los términos de la licencia. Los nombres «SingLink» y «SingLinkVPN» y el logotipo son marcas de SingLinkLabs, y la licencia no concede permiso para usarlos más allá de indicar de dónde procede el trabajo. Las versiones modificadas y los forks deberían publicarse con su propio nombre e icono.

Más información

• El prototipo de la app SingLinkVPN ya es de código abierto, y su código en GitHub
• Proyectos de código abierto de SingLinkLabs
• Documento técnico de SingLink 2.0, el protocolo de producción de las apps oficiales