TLS, HTTP/2 및 TCP 핑거프린트 스푸핑을 지원하는 구성 가능한 Rust HTTP MITM 프록시입니다.
Rust, tokio, btls로 구축된 HTTP MITM 프록시입니다.
이 프로젝트는 고급 TLS 핑거프린팅 기능을 활용하기 위해 btls(BoringSSL)를 사용하도록 완전히 재작성되었습니다. TLS 핑거프린팅 계층(JA3/JA4)은 이제 완전히 스푸핑 가능합니다 — 암호화 스위트, 커브, 서명 알고리즘, ALPN, 레코드 크기 제한, 인증서 압축, GREASE, 확장 순열/순서, OCSP 스테이플링, 인증서 투명성(SCT), 세션 티켓, ALPS, 그리고 암호화된 클라이언트 헬로(ECH, DoH를 통해 실시간으로 확인하며 GREASE 폴백 지원)는 모두 YAML 프로필에 의해 제어됩니다. HTTP/2 핑거프린팅(Akamai)과 HTTP/1.1 헤더 순서/재작성 또한 완전히 구성 가능합니다. TCP(L4) 핑거프린팅도 실시간으로 동작합니다: 업스트림 연결의 SYN 패킷이 NFQUEUE에서 재작성되며(TTL, 윈도우 크기, MSS, 윈도우 스케일, DF 플래그, 타임스탬프, 정확한 TCP 옵션 순서, 도메인별 마크), iptables 관리가 자동으로 이루어집니다.
MITM (중간자 공격) — 투명한 HTTPS 가로채기. rcgen을 사용하여 인증서를 동적으로 발급하고 서명하며, 성능을 위해 moka를 통해 캐싱합니다.
BoringSSL 통합 — TLS 핸드셰이크 처리 및 MITM 가로채기를 위해 btls와 tokio-btls를 사용합니다.
TLS 핑거프린트 스푸핑 (JA3/JA4) — 완료. 업스트림 TLS 연결은 -c / --config <path>를 통해 전달되는 YAML 프로필로부터 전적으로 구축됩니다(형식은 config.yaml 참조):
brotli, zlib, zstd).TLS.md 참조.업스트림 우선 ALPN 협상 — 프록시는 브라우저 측 TLS 핸드셰이크를 완료하기 전에 업스트림 서버와 TLS를 설정하고 협상합니다. 그런 다음 업스트림 서버가 선택한 ALPN을 사용하여 클라이언트 측 TLS 수락자를 구성함으로써, 브라우저가 업스트림 연결에서 지원하지 않는 프로토콜을 선택하는 것을 방지합니다.
HTTP/2 핑거프린트 스푸핑 (Akamai) — YAML 프로필을 통한 완전한 구성 가능한 HTTP/2 핑거프린팅:
END_STREAM 배치.HTTP/1.1 헤더 스푸핑 — 일반 HTTP/1.1 업스트림 연결(ALPN이 h2를 협상하지 않을 때)에 대한 구성 가능한 헤더 순서 및 내용으로, HTTP/2에 사용되는 것과 동일한 재정의/제거 의미를 반영합니다.
TCP 핑거프린트 스푸핑 (L4) — 완료. 나가는 업스트림 연결은 Linux NFQUEUE(src/tcp_fingerprint/)를 통해 패킷 수준에서 핑거프린팅됩니다:
Accept 판정을 받으므로 큐가 절대 정체되지 않음.SO_MARK 기반 라우팅으로 도메인별 TCP 프로필 적용, 자동 iptables 관리(zapret/nfqws 같은 도구 위에 최상단 삽입, 중복 제거, Ctrl+C 종료 시 제거) 및 --queue-bypass 안전장치.TCP.md와 config.yaml의 tcp 블록을 참고.업스트림 HTTP 프록시 지원 — CONNECT 메서드를 통해 업스트림 HTTP 프록시로 연결을 프록시할 수 있음.
도메인별 프로필 라우팅 — 도메인 패턴과 부분 프로필 오버레이의 맵을 담은 -d / --domain <path>를 전달( domain.yaml 참고). 각 연결은 SNI로 매칭되며(정확히 일치 → *.root → *.label.* → label.* → 기본 프로필), 시작 시 한 번 미리 빌드된 자체 TCP/TLS/HTTP2/HTTP1/업스트림 설정으로 처리됨. 기본 프로필과 다른 필드만 지정하면 되고, 나머지는 모두 상속됨.
비동기 — 고성능 비블로킹 비동기 I/O를 위해 tokio 기반으로 구축됨.
cap_net_admin,cap_net_raw=+eip (SO_MARK, NFQUEUE 바인드, 자동 iptables에 필요. 없을 경우 tcp 블록에서 "auto_iptables": false로 설정하고 mangle 규칙을 수동으로 적용 — TCP.md 참고)프록시는 RUST_LOG를 통한 모듈별 필터링과 함께 tracing을 사용함.
예시:
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
지원되는 태그는 코드에서 사용되는 것과 동일한 모듈 이름입니다: TCP, HTTP, H1, H2, TLS, CA, ECH, CFG, IPT, NFQUEUE, Runtime.
로그 줄에는 기본적으로 타임스탬프가 포함되므로 디버깅 세션을 더 쉽게 연관 지을 수 있습니다.
git clone https://github.com/3Radiance/mitm-proxy-ja3-ja4.git
cd mitm-proxy-ja3-ja4
cargo build --release
포트, 업스트림 프록시, CA 파일 경로 등 모든 설정은 -c / --config <path>로 전달되는 YAML 구성 파일에 있습니다. --port / --upstream CLI 플래그는 없습니다.
config:
port: 9090
upstream_proxy: "127.0.0.1:10808"
cert: "/path/to/ca.crt"
key: "/path/to/ca.key"
업스트림 프록시 없이 실행하려면 upstream_proxy: null로 설정하세요.
cargo run --release -- --config profile.yaml
# or
cargo run --release -- -c profile.yaml
첫 실행 시 cert/key가 아직 존재하지 않으면, 프록시는 설정된 경로에 CA 파일을 생성합니다:
ca.crt — 루트 CA 인증서입니다. 웹사이트를 식별하려면 Firefox/브라우저에 이 인증서를 가져와 신뢰하도록 설정해야 합니다.ca.key — CA의 개인 키입니다.cargo run --release -- -c profile.yaml -d domain.yaml
domain.yaml은 도메인 패턴을 부분 오버레이에 매핑합니다. 즉, 기본 프로필과 다른 필드만 포함합니다:
"browserleaks.com":
config:
upstream_proxy: null
tls:
enable_ech: false
"*.google.com":
tls:
enable_ech: true
"tls.peet.ws":
tcp:
mark: "0x11"
ttl: 100
window_size: 64130
mss: 1400
window_scale: 7
dont_fragment: true
timestamp: false
tcp_options_order:
- mss
- sack_perm
- wscale
- nop
"mail.google.*":
tls:
curves:
- X25519
- P-256
연결별 매칭 순서(SNI 기준, 대소문자 구분 없음): 정확히 일치 → *.root → *.label.* → label.* → 기본 프로필. 키가 없거나(upstream_proxy를 제외한 어디서든 null인 경우 포함) "기본 프로필에서 상속"을 의미하는 반면, "upstream_proxy": null은 해당 도메인에 대해 직접 연결을 명시적으로 강제합니다. TCP 필드(mark 포함)도 같은 방식으로 기본 프로필을 상속합니다. 즉, "mark": null은 해당 도메인의 mark를 해제합니다. 참고: 기본 프로필이 upstream_proxy를 설정하면 SO_MARK가 전혀 적용되지 않고 TCP 계층이 우회됩니다(TCP.md 참조).
src/main.rs: -c / --config <path> 파싱에 clap을 사용하는 CLI 진입점입니다. YAML 구성에는 프록시 포트, 업스트림 프록시, CA 경로, TLS 지문 프로필, HTTP/2 지문 프로필이 포함됩니다.src/config.rs: 모든 지문 계층에 대한 YAML 구성 모델 및 파서입니다. TLS 설정, ECH/DoH 옵션, HTTP/2 SETTINGS, 스트림 우선순위, 헤더 순서, HTTP 헤더 재정의, 의사 헤더 순서 및 기타 프로필별 옵션을 처리합니다.
src/domain.rs: 도메인별 프로필 오버레이(-d / --domain)입니다. 부분 재정의는 시작 시 한 번 기본 프로필 위에 깊은 병합(deep-merge)되며, 연결별 조회는 재할당 없이 저렴한 Arc 복제입니다.
src/proxy/tcp.rs: TCP 연결 처리, 초기 HTTP CONNECT 파싱, 업스트림 TCP 연결 설정(프로필이 mark를 설정한 경우 SO_MARK를 통해 소켓에 마킹), SNI 추출, 도메인별 프로필 라우팅(SNI 매칭, 기본 프로필로 폴백), 업스트림 TLS 협상, 그리고 결과 TLS 연결을 클라이언트로 브리징합니다.
src/proxy/http.rs: httparse를 사용한 최소한의 HTTP/1.x 요청/응답 파싱으로, CONNECT 메서드 검증과 대상 host:port 추출을 포함합니다.
src/tls_fingerprint/cert.rs: rcgen과 btls::x509를 사용한 즉석 인증서 생성으로, 로컬 CA에 의해 서명되고 moka 캐시에 캐싱됩니다.
src/tls_fingerprint/tls.rs: btls / tokio-btls TLS 수락자 및 커넥터 구성, 업스트림 TLS 협상, 클라이언트 측 TLS 핸드셰이크 처리, ALPN 협상입니다.
src/tls_fingerprint/helpers.rs: 암호화 스위트, 곡선, 서명 알고리즘, ALPN, 확장 순서/순열, 레코드 크기 제한, 인증서 압축, GREASE, OCSP 스테이플링, SCT, 세션 티켓, ALPS를 위한 개별 TLS 지문 구성 헬퍼입니다.
src/tls_fingerprint/compression.rs: Brotli, zlib, zstd에 대한 인증서 압축 구현입니다.
src/tls_fingerprint/ech.rs: DoH를 통한 실시간 ECH 구성 확인(HTTPS/SVCB 레코드 조회, DoH 요청 자체에 구성된 TLS/HTTP2 지문 재사용)으로, 호스트에 게시된 구성이 없을 때 GREASE 폴백을 사용합니다.
src/h2_fingerprint/h2.rs: HTTP/2 연결 진입점 및 연결 수준 요청 처리입니다. 클라이언트 측 HTTP/2 연결을 구성된 업스트림 HTTP/2 연결과 조정합니다.
src/h2_fingerprint/request.rs: 수신 HTTP/2 요청 처리, 요청 구성, 의사 헤더 순서, HTTP 헤더 조작, 업스트림 스트림 생성, 요청/응답 전달 조정입니다.
src/h2_fingerprint/request_body.rs: 스트리밍 HTTP/2 요청 본문 전달, 흐름 제어 처리, END_STREAM 배치, 요청 트레일러입니다.
src/h2_fingerprint/response.rs: HTTP/2 응답 전달, 응답 본문 스트리밍, 흐름 제어 처리, END_STREAM 처리, 응답 트레일러입니다.
src/h2_fingerprint/upstream.rs: 활성 지문 프로필에 따른 업스트림 HTTP/2 클라이언트 연결의 생성 및 구성입니다.