Volver al inicio

Configuración de NaiveProxy en sing-box: una alternativa segura a VLESS

El artículo describe la configuración de NaiveProxy usando sing-box y Caddy. Se discuten en detalle los mecanismos de enmascaramiento a través de la pila Chromium, la corrección de la vulnerabilidad de padding y la configuración de terminación TLS. Se proporcionan recomendaciones prácticas para desarrolladores intermedios/senior.

NaiveProxy: instrucciones completas de configuración con pila Chromium
Advertisement 728x90

NaiveProxy: Una alternativa segura a VLESS basada en Chromium

Ante los intensos esfuerzos de bloqueo, el protocolo NaiveProxy ofrece un enfoque único de camuflaje de tráfico: aprovecha la pila de red original de Chromium. Te guiaremos en la configuración del cliente y el servidor con sing-box y Caddy, evitando los errores habituales.

Fundamentos del camuflaje de tráfico: ¿Por qué NaiveProxy supera a uTLS?

Los protocolos proxy estándar se disfrazan de tráfico HTTPS, pero el paquete inicial ClientHello sigue siendo vulnerable. Envía la versión TLS, la lista de cifrados y el dominio en texto plano. Las implementaciones basadas en Go (incluyendo Xray y sing-box) presentan una huella dactilar característica en el ClientHello propia del lenguaje, lo que las hace identificables incluso con uTLS. La biblioteca uTLS solo imita el comportamiento del navegador en ese primer paquete, sin replicar las sutilezas de la pila de red como el ritmo de transmisión de datos, las longitudes de frames y las peculiaridades de HTTP/2. NaiveProxy aborda esto de frente al incorporar un fragmento de Chromium que emula el tráfico del navegador con precisión absoluta.

Arquitectura de NaiveProxy: De Chromium a proxy

El creador del protocolo, klzgrad, redujo el código fuente de Chromium a solo el 0,3 % de su funcionalidad, conservando únicamente lo necesario para la red. Características clave:

Google AdInline article slot
  • Usa la pila nativa HTTP/2 de Chromium para multiplexación
  • Coincidencia perfecta del ClientHello y paquetes subsiguientes con el tráfico real de un navegador
  • Abandona cifrados personalizados en favor de mecanismos TLS estándar

Importante: Es totalmente compatible con proxies HTTP/2 estándar en ambas direcciones. Los clientes Naive funcionan con cualquier proxy HTTP/2, y los servidores Naive aceptan conexiones de clientes estándar. Pero el verdadero camuflaje solo se logra con la pila de red de Chromium, como en sing-box. Otros clientes (p. ej., los basados en Go) pueden conectarse a un servidor Naive, pero no ofrecen anonimato completo.

Padding: Tres capas de protección contra el análisis de tráfico

El protocolo emplea padding multinivel para frustrar el análisis de longitudes de paquetes:

  • Frames DATA: Los primeros 8 frames de cada stream agregan un encabezado (2 bytes para la longitud de datos + 1 byte para la longitud del padding), seguido de los datos originales y bytes de padding.
  • Solicitudes CONNECT: Encabezados de longitud aleatoria engrosan los tamaños de frames de forma arbitraria.
  • END_STREAM: Frames extra antes de cada RST_STREAM.

Las pruebas revelaron un fallo crítico en sing-box: en lugar de poner a cero el buffer al agregar padding, enviaba datos residuales de solicitudes previas. Esto filtraba información sensible (como nombres de dominio y encabezados). Se corrigió en las versiones 1.13.1+ tras fusionar dos PR que fuerzan la puesta a cero del buffer.

Google AdInline article slot

Configuración del cliente: Outbound de sing-box

Requiere sing-box 1.13+. Configuración del cliente:

{
  "type": "naive",
  "tag": "Proxy1",
  "server": "1.2.3.4",
  "server_port": 443,
  "username": "username",
  "password": "password",
  "insecure_concurrency": 1,
  "udp_over_tcp": {
    "enabled": true
  },
  "quic": false,
  "tls": {
    "enabled": true,
    "server_name": "s1.example.com"
  }
}

Parámetros clave:

  • insecure_concurrency: Mantén el valor en 1. Valores más altos facilitan el análisis del tráfico.
  • udp_over_tcp: Actívalo para soporte UDP.
  • server_name: Dominio configurado en Caddy. Debe coincidir con el server_name de la sección TLS.

Caddy como terminador TLS: Configuración y fallback

Caddy gestiona las conexiones TLS y enruta el tráfico al proxy o a un señuelo. Configuración (/etc/caddy/Caddyfile):

Google AdInline article slot
{
    email [email protected]
    auto_https disable_redirects
}

:443, https://s1.example.com {
    tls {
        issuer acme {
            disable_http_challenge
        }
    }

    route {
        @naive {
            method CONNECT
            header Proxy-Authorization "Basic dXNlcm5hbWU6cGFzc3dvcmQ="
        }

        handle @naive {
            reverse_proxy h2c://127.0.0.1:1080 {
                header_up Proxy-Authorization {header.Proxy-Authorization}
            }
        }

        handle {
            root * /srv/naive-fallback
            file_server
        }
    }
}

Puntos clave:

  • El encabezado Proxy-Authorization contiene username:password codificado en base64 (genera con echo -n "username:password" | base64).
  • El directorio /srv/naive-fallback sirve un sitio estático de señuelo para repeler escaneos.
  • auto_https disable_redirects evita redirecciones HTTP→HTTPS ya que el puerto 443 es solo HTTPS.

Lado del servidor: Inbound de sing-box e integración con Caddy

Configuración de sing-box en el servidor (/etc/sing-box/config.json):

{
  "log": {
    "level": "warn",
    "output": "/var/log/sing-box/sing-box.log"
  },
  "inbounds": [
    {
      "type": "naive",
      "tag": "naive-in",
      "network": "tcp",
      "listen": "127.0.0.1",
      "listen_port": 1080,
      "users": [
        {
          "username": "username",
          "password": "password"
        }
      ]
    }
  ],
  "outbounds": [
    {
      "type": "direct"
    }
  ]
}

Importante:

  • El servidor solo escucha en localhost:1080, ya que Caddy gestiona las conexiones externas.
  • El nivel de log warn minimiza la E/S en disco.
  • Las contraseñas deben coincidir exactamente con las del cliente y Caddy.

Puntos clave

  • Camuflaje completo requiere la pila de Chromium: Solo las implementaciones que usan el código de red original (como sing-box) coinciden perfectamente con el tráfico del navegador.
  • Concurrencia = riesgo: insecure_concurrency superior a 1 aumenta la vulnerabilidad al análisis de longitudes de paquetes.
  • Mantén los componentes actualizados: Usa sing-box 1.13.1+ para corregir fugas de datos en el padding.
  • Sitio señuelo es esencial: Un sitio estático en Caddy oculta el proxy de los escaneos.
  • La realidad no es infalible: Como muestra la historia de Reality, incluso soluciones ingeniosas pueden bloquearse por nuevas huellas (p. ej., conteos de conexiones).

— Editorial Team

Advertisement 728x90

Leer después