3radiance/mitm-proxy-ja3-ja4
TLS、HTTP/2、TCPフィンガープリントの偽装に対応した、設定可能なRust製HTTP MITMプロキシ。
Rust、tokio、btls で構築された HTTP MITM プロキシ。
このプロジェクトは、高度な TLS フィンガープリンティング機能を活用するために btls（BoringSSL）を利用するよう完全に書き直されました。TLS フィンガープリンティング層（JA3/JA4）は完全に偽装可能になりました — 暗号スイート、曲線、署名アルゴリズム、ALPN、レコードサイズ制限、証明書圧縮、GREASE、拡張の順列/順序、OCSP ステープリング、Certificate Transparency（SCT）、セッションチケット、ALPS、Encrypted Client Hello（ECH、DoH 経由でライブ解決、GREASE フォールバック付き）はすべて YAML プロファイルによって制御されます。HTTP/2 フィンガープリンティング（Akamai）と HTTP/1.1 のヘッダー順序/書き換えも完全に設定可能です。TCP（L4）フィンガープリンティングもライブで動作します：上流接続の SYN パケットは NFQUEUE で書き換えられ（TTL、ウィンドウサイズ、MSS、ウィンドウスケール、DF フラグ、タイムスタンプ、正確な TCP オプション順序、ドメインごとのマーク）、iptables の管理は自動で行われます。
MITM（Man-in-the-Middle） — 透過的な 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 を参照）プロキシは tracing を使用し、RUST_LOG によるモジュール単位のフィルタリングを行います。
例:
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: clap を使用して -c / --config <path> を解析する CLI エントリポイント。YAML 設定にはプロキシポート、上流プロキシ、CA パス、TLS フィンガープリントプロファイル、HTTP/2 フィンガープリントプロファイルが含まれます。src/config.rs: すべてのフィンガープリンティングレイヤーに対する YAML 設定モデルとパーサー。TLS 設定、ECH/DoH オプション、HTTP/2 SETTINGS、ストリーム優先度、ヘッダー順序、HTTP ヘッダーオーバーライド、疑似ヘッダー順序、その他のプロファイル固有オプションを処理します。
src/domain.rs: ドメインごとのプロファイルオーバーレイ（-d / --domain）。部分的なオーバーライドは起動時に一度だけベースプロファイルにディープマージされます。接続ごとのルックアップは再割り当てなしの安価な 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 の配置、およびリクエストトレーラー。