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:
- 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.
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):
{
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-Authorizationcontieneusername:passwordcodificado en base64 (genera conecho -n "username:password" | base64). - El directorio
/srv/naive-fallbacksirve un sitio estático de señuelo para repeler escaneos. auto_https disable_redirectsevita 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
warnminimiza 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_concurrencysuperior 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
Aún no hay comentarios.