mitm-proxy-ja3-ja4

English | Русский

Um proxy MITM HTTP construído com Rust, tokio e btls.

Este projeto foi completamente reescrito para aproveitar o btls (BoringSSL) para capacidades avançadas de fingerprinting TLS. A camada de fingerprinting TLS (JA3/JA4) agora é totalmente falsificável — cipher suites, curvas, algoritmos de assinatura, ALPN, limite de tamanho de registro, compressão de certificado, GREASE, permutação/ordenação de extensões, OCSP stapling, Certificate Transparency (SCT), session tickets, ALPS e Encrypted Client Hello (ECH, resolvido em tempo real via DoH, com fallback para GREASE) são todos controlados por um perfil YAML. O fingerprinting HTTP/2 (Akamai) e a ordenação/reescrita de cabeçalhos HTTP/1.1 também são totalmente configuráveis. O fingerprinting TCP (L4) também está ativo: os pacotes SYN das conexões upstream são reescritos no NFQUEUE (TTL, tamanho da janela, MSS, escala de janela, flag DF, timestamps, ordem exata das opções TCP, marcas por domínio) com gerenciamento automático do iptables.

Configuração de Falsificação de Fingerprint TLS

TLS

Configuração de Falsificação de Fingerprint HTTP/2

HTTP/2

Configuração de Falsificação de Fingerprint TCP

TCP

Recursos (Implementação Atual)

• MITM (Man-in-the-Middle) — Interceptação HTTPS transparente. Utiliza rcgen para emitir e assinar certificados dinamicamente em tempo real, armazenando-os em cache via moka para desempenho.

• Integração com BoringSSL — Utiliza btls e tokio-btls para o tratamento do handshake TLS e interceptação MITM.

• Falsificação de Fingerprint TLS (JA3/JA4) — completa. A conexão TLS upstream é construída inteiramente a partir de um perfil YAML passado via -c / --config <path> (consulte config.yaml para o formato):

  • Cipher suites, em ordem estrita definida pelo chamador.
  • Curvas elípticas.
  • Algoritmos de assinatura.
  • Negociação ALPN baseada no protocolo efetivamente selecionado pelo servidor upstream.
  • Limite de tamanho de registro.
  • Compressão de certificado (brotli, zlib, zstd) com suporte real a descompressão.
  • GREASE.
  • Ordenação exata das extensões TLS no ClientHello, ou permutação aleatória no estilo Chrome.
  • Alternâncias de OCSP stapling, Certificate Transparency (SCT), session ticket e ALPS (Application-Layer Protocol Settings).
  • Encrypted Client Hello (ECH) — a configuração ECH real é resolvida em tempo real via DoH (consulta de registro HTTPS/SVCB) para cada host upstream, usando o mesmo perfil de fingerprint TLS/HTTP2 para a própria requisição DoH; recorre ao ECH GREASE (ou nada) quando nenhuma configuração é encontrada, configurável de forma independente — consulte TLS.md para detalhes.

• Negociação ALPN com Prioridade no Upstream — O proxy estabelece e negocia TLS com o servidor upstream antes de concluir o handshake TLS do lado do navegador. O ALPN selecionado pelo servidor upstream é então usado para configurar o acceptor TLS do lado do cliente, impedindo que o navegador selecione um protocolo que a conexão upstream não suporta.

• Falsificação de Fingerprint HTTP/2 (Akamai) — Fingerprinting HTTP/2 totalmente configurável através do perfil YAML:

  • Valores de SETTINGS HTTP/2 e ordenação exata dos SETTINGS.
  • Atualizações da janela de controle de fluxo em nível de conexão.
  • ID de stream inicial configurável com cálculo automático quando frames de prioridade estão configurados.
  • Frames de prioridade HTTP/2 e prioridade de cabeçalho de requisição.
  • Posicionamento configurável de END_STREAM para requisições vazias.
  • Ordenação de pseudo-cabeçalhos.
  • Ordenação de cabeçalhos HTTP.
  • Substituição, adição e remoção de cabeçalhos HTTP.
  • Encaminhamento de corpo de requisição e resposta em streaming sem armazenar o corpo completo em buffer.
  • Suporte a trailers HTTP/2.

• Falsificação de Cabeçalhos HTTP/1.1 — Ordem e conteúdo de cabeçalhos configuráveis para conexões upstream HTTP/1.1 simples (quando o ALPN não negocia h2), espelhando a mesma semântica de substituição/remoção usada para HTTP/2.

• Falsificação de Fingerprint TCP (L4) — completa. As conexões upstream de saída recebem fingerprint em nível de pacote via Linux NFQUEUE (src/tcp_fingerprint/):

  • Reescrita de SYN: TTL, tamanho da janela, flag DF, valores de MSS / window-scale, alternância de timestamp, ordem exata das opções TCP (ou patch de valores no local quando nenhuma ordem é definida), com recálculo de checksum.
  • Patch de fila de fluxos estabelecidos apenas para TTL/DF (hop limit de IPv6 suportado); cada pacote recebe um veredito Accept por padrão, para que as filas nunca travem.
  • Roteamento baseado em SO_MARK para perfis TCP por domínio, gerenciamento automático de iptables (inserido no topo acima de ferramentas como zapret/nfqws, deduplicado, removido no encerramento com Ctrl+C) com segurança via --queue-bypass.
  • Consulte TCP.md e o bloco tcp em config.yaml.

• Suporte a Proxy HTTP Upstream — Pode encaminhar conexões através de um proxy HTTP upstream via o método CONNECT.

• Roteamento de Perfil por Domínio — Passe -d / --domain <path> com um mapa de padrões de domínio para sobreposições parciais de perfil (consulte domain.yaml). Cada conexão é correspondida por SNI (exato → *.root → *.label.* → label.* → perfil base) e servida com suas próprias configurações de TCP/TLS/HTTP2/HTTP1/upstream, pré-construídas uma vez na inicialização. Apenas os campos que diferem do perfil base precisam ser especificados; todo o resto é herdado.

• Assíncrono — Construído sobre tokio para I/O assíncrono não bloqueante de alto desempenho.

Requisitos

• Rust (edição 2021)
• Linux (necessário para os recursos NFQUEUE L4)
• Root ou cap_net_admin,cap_net_raw=+eip (para SO_MARK, bind de NFQUEUE e iptables automático; sem isso, defina "auto_iptables": false no bloco tcp e aplique as regras de mangle manualmente — consulte TCP.md)
• Firefox com Multi-Account Containers (altamente recomendado para aproveitar múltiplos fingerprints simultaneamente)

Logging

O proxy usa tracing com filtragem por módulo via RUST_LOG.

Exemplos:

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

As tags suportadas são os mesmos nomes de módulo usados no código: TCP, HTTP, H1, H2, TLS, CA, ECH, CFG, IPT, NFQUEUE, Runtime.

As linhas de log incluem um timestamp por padrão, para que as sessões de depuração sejam mais fáceis de correlacionar.

Instalação e Uso

1. Compilação

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

2. Executar

Todas as configurações — porta, proxy upstream e caminhos dos arquivos de CA — ficam no arquivo de configuração YAML passado via -c / --config <path>. Não existem 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 executar sem um proxy upstream, defina upstream_proxy: null.

cargo run --release -- --config profile.yaml
# or
cargo run --release -- -c profile.yaml