mitm-proxy-ja3-ja4

English | Русский

Un proxy MITM HTTP construido con Rust, tokio y btls.

Este proyecto ha sido completamente reescrito para aprovechar btls (BoringSSL) y así obtener capacidades avanzadas de fingerprinting TLS. La capa de fingerprinting TLS (JA3/JA4) ahora es totalmente falsificable — los cipher suites, las curvas, los algoritmos de firma, ALPN, el límite de tamaño de registro, la compresión de certificados, GREASE, la permutación/ordenación de extensiones, el stapling OCSP, Certificate Transparency (SCT), los session tickets, ALPS y Encrypted Client Hello (ECH, resuelto en vivo mediante DoH, con fallback a GREASE) están todos controlados por un perfil YAML. El fingerprinting HTTP/2 (Akamai) y la ordenación/reescritura de cabeceras HTTP/1.1 también son totalmente configurables. El fingerprinting TCP (L4) también está activo: los paquetes SYN de las conexiones upstream se reescriben en NFQUEUE (TTL, tamaño de ventana, MSS, escala de ventana, flag DF, timestamps, orden exacto de las opciones TCP, marcas por dominio) con gestión automática de iptables.

Configuración de la falsificación de fingerprint TLS

TLS

Configuración de la falsificación de fingerprint HTTP/2

HTTP/2

Configuración de la falsificación de fingerprint TCP

TCP

Características (implementación actual)

• MITM (Man-in-the-Middle) — Interceptación HTTPS transparente. Utiliza rcgen para emitir y firmar certificados dinámicamente sobre la marcha, almacenándolos en caché mediante moka por rendimiento.

• Integración con BoringSSL — Utiliza btls y tokio-btls para la gestión del handshake TLS y la interceptación MITM.

• Falsificación de fingerprint TLS (JA3/JA4) — completa. La conexión TLS upstream se construye íntegramente a partir de un perfil YAML pasado mediante -c / --config <path> (véase config.yaml para el formato):

  • Cipher suites, en estricto orden definido por el llamador.
  • Curvas elípticas.
  • Algoritmos de firma.
  • Negociación ALPN basada en el protocolo realmente seleccionado por el servidor upstream.
  • Límite de tamaño de registro.
  • Compresión de certificados (brotli, zlib, zstd) con soporte real de descompresión.
  • GREASE.
  • Orden exacto de las extensiones TLS en el ClientHello, o permutación aleatoria al estilo Chrome.
  • Conmutadores de stapling OCSP, Certificate Transparency (SCT), session ticket y ALPS (Application-Layer Protocol Settings).
  • Encrypted Client Hello (ECH) — la configuración ECH real se resuelve en vivo mediante DoH (búsqueda de registros HTTPS/SVCB) para cada host upstream, usando el mismo perfil de fingerprint TLS/HTTP2 para la propia petición DoH; recurre a ECH GREASE (o a nada) cuando no se encuentra configuración, de forma configurable independientemente — véase TLS.md para más detalles.

• Negociación ALPN con prioridad al upstream — El proxy establece y negocia TLS con el servidor upstream antes de completar el handshake TLS del lado del navegador. El ALPN seleccionado por el servidor upstream se usa entonces para configurar el acceptor TLS del lado del cliente, evitando que el navegador seleccione un protocolo que la conexión upstream no soporta.

• Falsificación de fingerprint HTTP/2 (Akamai) — Fingerprinting HTTP/2 totalmente configurable mediante el perfil YAML:

  • Valores de SETTINGS de HTTP/2 y orden exacto de SETTINGS.
  • Actualizaciones de la ventana de control de flujo a nivel de conexión.
  • Stream ID inicial configurable con cálculo automático cuando se configuran frames de prioridad.
  • Frames de prioridad HTTP/2 y prioridad de cabeceras de petición.
  • Ubicación configurable de END_STREAM para peticiones vacías.
  • Ordenación de pseudo-cabeceras.
  • Ordenación de cabeceras HTTP.
  • Reemplazo, adición y eliminación de cabeceras HTTP.
  • Reenvío en streaming de cuerpos de petición y respuesta sin almacenar el cuerpo completo en búfer.
  • Soporte de trailers HTTP/2.

• Falsificación de cabeceras HTTP/1.1 — Orden y contenido de cabeceras configurables para conexiones upstream HTTP/1.1 simples (cuando ALPN no negocia h2), replicando la misma semántica de sobrescritura/eliminación usada para HTTP/2.

• Falsificación de fingerprint TCP (L4) — completa. Las conexiones upstream salientes se fingerprintan a nivel de paquete mediante NFQUEUE de Linux (src/tcp_fingerprint/):

  • Reescritura de SYN: TTL, tamaño de ventana, flag DF, valores MSS / window-scale, activación/desactivación de timestamp, orden exacto de las opciones TCP (o parcheo de valores in situ cuando no se establece un orden), con recálculo de checksum.
  • Parcheo de la cola de flujos establecidos solo para TTL/DF (con soporte de hop limit de IPv6); cada paquete recibe un veredicto Accept por defecto para que las colas nunca se bloqueen.
  • Enrutamiento basado en SO_MARK hacia perfiles TCP por dominio, gestión automática de iptables (insertadas en la parte superior por encima de herramientas como zapret/nfqws, deduplicadas, eliminadas al apagar con Ctrl+C) con la seguridad de --queue-bypass.
  • Véase TCP.md y el bloque tcp en config.yaml.

• Soporte de proxy HTTP upstream — Puede redirigir conexiones a través de un proxy HTTP upstream mediante el método CONNECT.

• Enrutamiento de perfiles por dominio — Pasa -d / --domain <path> con un mapa de patrones de dominio a superposiciones parciales de perfil (véase domain.yaml). Cada conexión se empareja por SNI (exacto → *.root → *.label.* → label.* → perfil base) y se sirve con su propia configuración de TCP/TLS/HTTP2/HTTP1/upstream, precompilada una vez al inicio. Solo es necesario especificar los campos que difieren del perfil base; todo lo demás se hereda.

• Asíncrono — Construido sobre tokio para E/S asíncrona no bloqueante de alto rendimiento.

Requisitos

• Rust (edición 2021)
• Linux (necesario para las funciones NFQUEUE L4)
• Root o cap_net_admin,cap_net_raw=+eip (para SO_MARK, enlace de NFQUEUE e iptables automáticas; sin ello, establece "auto_iptables": false en el bloque tcp y aplica las reglas de mangle a mano — véase TCP.md)
• Firefox con Multi-Account Containers (muy recomendado para aprovechar múltiples huellas digitales simultáneamente)

Registro

El proxy utiliza tracing con filtrado por módulo mediante RUST_LOG.

Ejemplos:

RUST_LOG='H2=error' cargo run --release -- -c profile.yaml
RUST_LOG='TCP=debug,H2=error,TLS=warn' cargo run --release -- -c profile.yaml
RUST_LOG='CA=info,TLS=warn,H2=error' cargo run --release -- -c profile.yaml

Las etiquetas admitidas son los mismos nombres de módulo usados en el código: TCP, HTTP, H1, H2, TLS, CA, ECH, CFG, IPT, NFQUEUE, Runtime.

Las líneas de registro incluyen una marca de tiempo por defecto, de modo que las sesiones de depuración son más fáciles de correlacionar.

Instalación y uso

1. Compilación

git clone https://github.com/3Radiance/mitm-proxy-ja3-ja4.git
cd mitm-proxy-ja3-ja4
cargo build --release

2. Ejecutar

Todas las configuraciones — puerto, proxy upstream y rutas de archivos CA — se encuentran en el archivo de configuración YAML que se pasa mediante -c / --config <path>. No existen flags de CLI --port / --upstream.

config: 
  port: 9090
  upstream_proxy: "127.0.0.1:10808"
  cert: "/path/to/ca.crt"
  key: "/path/to/ca.key"

Para ejecutar sin un proxy upstream, establezca upstream_proxy: null.