obscura/research/mitm-approachesobscura/research/mitm-approaches

Resumen

Obscura requiere un proxy MitM (Man-in-the-Middle) para interceptar y modificar tráfico HTTPS. Este documento evalúa las opciones disponibles.

Enfoques

Enfoque 1: Librería Go mitmproxy

Librería: github.com/elazarl/goproxy

Pros:

• Madura, bien probada
• Maneja túneles CONNECT automáticamente
• Soporta modificación de respuestas
• MITM con generación de certificados sobre la marcha

Contras:

• El soporte HTTP/2 es limitado
• Árbol de dependencias grande
• No diseñado para proxy transparente

Enfoque 2: Proxy Rust Personalizado con tokio + rustls

Pros:

• Control total sobre la pila TLS
• Rendimiento (abstracciones de costo cero)
• tokio-rustls para terminación TLS
• Hyper para HTTP/1 y HTTP/2
• Puede integrar utls para falsificación de fingerprint TLS

Contras:

• Mayor esfuerzo de desarrollo
• Debe manejar la generación de certificados manualmente
• Se requiere análisis a nivel de trama HTTP/2

Enfoque 3: Squid + Modificación Externa

Pros:

• Proxy probado en batalla
• SSL Bump para MITM
• ICAP/eCAP para modificación de contenido

Contras:

• Configuración compleja
• Versiones EOL aún en uso
• No diseñado para inyección JS
• Imagen de contenedor pesada

Enfoque 4: Envoy Proxy con Filtro Wasm

Pros:

• Alto rendimiento
• Proxy L4/L7
• Filtros WebAssembly (Wasm) para modificación
• HTTP/2 y HTTP/3 nativos

Contras:

• Configuración compleja
• Sobrecarga de desarrollo de filtros Wasm
• No diseñado para inyección JS del lado del cliente
• Excesivo para despliegue a pequeña escala

Enfoque 5: Intercepción Personalizada a Nivel TCP

Intercepción de socket raw + terminación TLS:

1. Usar iptables TPROXY para redirigir tráfico
2. Lectura de socket TCP raw
3. Handshake TLS manual (mediante rustls/crypto/tls)
4. Análisis HTTP/1.1 o HTTP/2
5. Modificación de headers + inyección JS
6. Reenvío al upstream

Pros:

• Máximo control
• Sin dependencia de frameworks de proxy
• Puede manejar todos los casos extremos

Contras:

• Máximo esfuerzo de desarrollo
• Debe implementar manejo de HTTP/2 y HTTP/3
• Debe manejar correctamente el connection pooling

Recomendación

Para Obscura, una implementación Rust personalizada (Enfoque 2) es la mejor compensación:

• El goproxy de Go carece de HTTP/2 y falsificación TLS
• Rust proporciona control granular sobre TLS (integración utls)
• El rendimiento importa para una puerta de enlace de red
• Las garantías de seguridad de Rust reducen errores del proxy

Generación de Certificados

Para MITM, el proxy debe generar certificados TLS sobre la marcha:

1. Un certificado CA se genera en el primer inicio
2. Para cada nuevo dominio, un certificado hoja es firmado por la CA
3. El cliente debe confiar en el certificado CA

CA de Obscura (clave privada)
   *.example.com (hoja, generado en la primera solicitud)
   *.anotherexample.com (hoja, generado en la primera solicitud)

Almacenamiento de Certificados

/var/lib/obscura/certs/
 ca.pem          # Certificado CA (público)
 ca-key.pem      # Clave privada CA
 cache/          # Certificados hoja generados
    example.com.pem
    ...
 serial          # Contador de serie de certificados

Limitaciones

• HPKP (HTTP Public Key Pinning): Ahora obsoleto en Chrome, pero algunos sitios aún lo usan
• Precarga HSTS: Los sitios en la lista de precarga HSTS (ej., google.com, stripe.com) rechazarán certificados MITM. Deben ser interceptados a nivel DNS/red primero.
• Transparencia de Certificados: Algunos sitios requieren registros CT. El proxy debe incrustar SCTs.
• HTTP/3 (QUIC): Se ejecuta sobre UDP y está cifrado de extremo a extremo. Debe bloquearse a nivel de red.

Conclusiones

• Rust con tokio-rustls + hyper es la pila de proxy recomendada
• La falsificación de fingerprint TLS requiere integración utls
• Los sitios con HSTS precargado deben manejarse a nivel DNS/red
• HTTP/3 debe bloquearse (QUIC evita el proxy)