Skip to content
KitploitKITPLOIT
ツールブログ
提出
ツールブログ
提出

ハッキング、侵入テスト、サイバーセキュリティツールをあなたのセキュリティアーセナルに!

Kitploitはハッキング、サイバーセキュリティ、ペネトレーションテストのツールディレクトリです。最新のプロジェクトアップデートを見つけて、脆弱性の発見、システム分析、テストの自動化、セキュリティの強化を行いましょう。

··フィード·お問い合わせ·プライバシー·© 2026 Kitploit

ツールディレクトリ

カテゴリ

すべてのカテゴリを見る
Loading categories
impersonate-proxy — TLSフィンガープリント(JA3/JA4)、HTTP/2フィンガープリント、HTTPヘッダーの順序、User-Agentを、単一のYAML設定ファイルからすべて制御できるローカルMITMプロキシ。 | Kitploit
ツール/GitHubGitHub/ytkoka/impersonate-proxy
ウェブプロキシと傍受なりすましツールWAFバイパスペネトレーションテストレッドチーミングフィンガープリントスプーフィング
GitHubytkoka/impersonate-proxy

impersonate-proxy

TLSフィンガープリント(JA3/JA4)、HTTP/2フィンガープリント、HTTPヘッダーの順序、User-Agentを、単一のYAML設定ファイルからすべて制御できるローカルMITMプロキシ。

リポジトリを見る
40293日前Kitploit レビュー済み

人気

すべて見る →

コミュニティで最も使われているツールを見つけましょう。

すべてのツールを探索

ツールコレクションを閲覧

すべてのツールを見る →
共有
ウェブサイト

impersonate-proxy

Chrome Web Store

English | 日本語 | 简体中文

TLSフィンガープリント(JA3/JA4)、HTTP/2フィンガープリント、HTTPヘッダーの順序、User-Agent、送信元IPヘッダーを、単一のYAML設定ファイルから制御できるローカルMITMプロキシです。

プロキシを再起動せずにブラウザのツールバーから直接プロキシのON/OFF切り替えやフィンガープリントプロファイルの変更ができる Chrome拡張機能 も同梱しています。

WAFのボット検知システムに対する 許可されたセキュリティテスト を目的としています。curl・ブラウザ・Playwrightのトラフィックをこのプロキシ経由にすることで、フィンガープリントの組み合わせごとにどう判定されるかを観察できます。

仕組み

root@kitploit:~
curl / browser / Playwright
        │  HTTP CONNECT (to proxy)
        ▼
┌─────────────────────────────────────────┐
│            impersonate-proxy            │
│                                         │
│  MITM TLS ◄──────────────► uTLS         │
│  (our CA cert)          (custom JA3/4)  │
│                                         │
│  Header rewriter (UA, order, add/del)   │
│  HTTP/2 framer  (SETTINGS, WINDOW_UPDATE│
│                  pseudo-header order)   │
└─────────────────────────────────────────┘
        │  Custom TLS ClientHello + HTTP/2
        ▼
   Target server / WAF
レイヤー制御できる項目
TLSuTLSのプリセット、または完全にカスタムな custom_hello 指定により、暗号スイート・拡張とその順序(JA3 / JA4)を制御
HTTP/1.1ヘッダーの順序、User-Agent、任意ヘッダーの追加/削除、IPスプーフィング(X-Forwarded-For / )

前提条件

  • macOS または Linux(amd64 / arm64)
  • Go 1.22+

macOS

root@kitploit:~
brew install go

Linux

ディストリビューション同梱のGoは古いことが多いため、公式バイナリを直接インストールしてください:

root@kitploit:~
# ダウンロードして展開(1.22.5は https://go.dev/dl/ の最新版に置き換えてください)
curl -OL https://go.dev/dl/go1.22.5.linux-amd64.tar.gz
sudo rm -rf /usr/local/go
sudo tar -C /usr/local -xzf go1.22.5.linux-amd64.tar.gz

# PATHに追加(恒久化するには ~/.bashrc または ~/.zshrc にこの行を追記)
export PATH=$PATH:/usr/local/go/bin

確認:

root@kitploit:~
go version
# go version go1.22.5 linux/amd64

ARM64(Raspberry Pi、AWS Gravitonなど): ダウンロードURL内の linux-amd64 を linux-arm64 に置き換えてください。

Docker(Goツールチェーン不要)

Goをインストールせず使い捨て環境で試したい場合は、Dockerセクションへ直接進んでください。

セットアップ

1. クローンとビルド

root@kitploit:~
git clone https://github.com/ytkoka/impersonate-proxy.git
cd impersonate-proxy
make build

2. MITM CA証明書の生成

CAは初回起動時に自動生成されます。一度プロキシを起動して ca.crt と ca.key を作成してください:

root@kitploit:~
make run
# 2026/04/22 12:00:00 generated CA certificate → ca.crt
# 2026/04/22 12:00:00 listening on 127.0.0.1:8080  preset=chrome

Ctrl-C で停止します。

3. CA証明書を信頼する

プロキシが生成するリーフ証明書をクライアントが拒否しないよう、MITM CAを信頼させる必要があります。

macOSシステムキーチェーン(全アプリに影響):

root@kitploit:~
make trust-ca        # runs: sudo security add-trusted-cert ...

Linuxシステムのトラストストア(全アプリに影響。ca-certificatesパッケージが必要):

root@kitploit:~
# Debian / Ubuntu
sudo cp ca.crt /usr/local/share/ca-certificates/impersonate-proxy.crt
sudo update-ca-certificates

# RHEL / Fedora / Amazon Linux
sudo cp ca.crt /etc/pki/ca-trust/source/anchors/impersonate-proxy.crt
sudo update-ca-trust

curlのみ(システム全体には影響しない):

root@kitploit:~
curl --cacert ca.crt ...

Playwright / Node.js:

root@kitploit:~
export NODE_EXTRA_CA_CERTS="$(pwd)/ca.crt"

Firefox: 設定 → プライバシーとセキュリティ → 証明書を表示 → 認証局 → ca.crt をインポート

Docker

コンテナ内でプロキシを実行できます。ローカルにGo/Makeをインストールする必要はありません。

1. プロキシを起動する

Linux環境限定の注意: コンテナは非特権ユーザー(nonroot、UID 65532)で動作し、CA証明書/鍵を保存する ./data ディレクトリへの書き込み権限が必要です。./data が存在しない状態で初回起動すると、Dockerが自動作成するディレクトリの所有者は root になり他ユーザーからは書き込めないため、CA証明書の生成に失敗します。事前に正しい所有者で作成しておいてください:

root@kitploit:~
mkdir -p data && sudo chown 65532:65532 data

Docker Desktop for Mac/Windowsでは、バインドマウント層が所有権を自動的にマッピングするため不要です。

root@kitploit:~
git clone https://github.com/ytkoka/impersonate-proxy.git
cd impersonate-proxy
docker compose up -d

イメージをローカルでビルドしてコンテナを起動します。初回起動時にMITM CAが生成され、以下のように出力されます:

root@kitploit:~
impersonate-proxy  | generated CA certificate → /data/ca.crt (add to OS trust store to avoid cert errors)
impersonate-proxy  | listening on 0.0.0.0:8080  preset=chrome

クローンせずビルド済みイメージを直接使う場合:

root@kitploit:~
docker run -d --name impersonate-proxy \
  -p 127.0.0.1:8080:8080 -p 127.0.0.1:8081:8081 \
  -v "$(pwd)/config.docker.yaml:/config.yaml:ro" \
  -v "$(pwd)/data:/data" \
  ghcr.io/ytkoka/impersonate-proxy:latest

docker-compose.yml は両ポートとも 127.0.0.1 にのみ公開します — ネイティブインストール時と同じループバック限定の露出範囲です(管理APIは無認証のため、独自のアクセス制御を追加しない限り 0.0.0.0 には変更しないでください)。

2. CA証明書を信頼する

CAはコンテナ内で生成されますが、ボリュームマウント経由でホストの ./data/ca.crt と ./data/ca.key に永続化されるため、コンテナの再起動・再作成をまたいで保持されます。上記のネイティブセットアップと同じ手順で、./ca.crt の代わりに ./data/ca.crt を指定してください:

root@kitploit:~
# curl
curl --proxy http://127.0.0.1:8080 --cacert ./data/ca.crt https://tls.peet.ws/api/all

# macOSシステムキーチェーン
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain ./data/ca.crt

3. 設定する

config.yaml ではなく config.docker.yaml(Docker用)を編集し、再起動してください:

root@kitploit:~
docker compose restart

config.docker.yaml は config.yaml とほぼ同一ですが、listen/mgmt_listen が 0.0.0.0 になっている点(Dockerのポート公開がプロセスに到達するために必須 — コンテナ自身の 127.0.0.1 はホストから到達できないため)と、ca_cert/ca_key が永続化ボリュームの /data 配下を指している点が異なります。指定可能な全項目は下記の設定を参照してください。

Makefileショートカット

ターゲット説明
make docker-builddocker compose build でイメージをビルド
make docker-runビルドしてバックグラウンドで起動
make docker-stopコンテナを停止・削除

停止・クリーンアップ

root@kitploit:~
docker compose down          # コンテナを停止
rm -rf data                  # 永続化したCAも削除する場合(削除後は再度信頼設定が必要)

設定

プロキシを起動する前に config.yaml を編集してください。全項目にデフォルト値があるため、変更したい項目だけを指定すれば十分です。

root@kitploit:~
listen: "127.0.0.1:8080"
mgmt_listen: "127.0.0.1:8081"  # Chrome拡張機能が使う管理API(空文字で無効化)
ca_cert: "ca.crt"
ca_key:  "ca.key"

tls:
  # TLSフィンガープリントのプリセット(JA3 / JA4を制御)
  # 選択肢: chrome | firefox | safari | edge | ios | random | golang
  preset: "chrome"

http:
  # User-Agentを上書き(空にするとクライアントのUAをそのまま通す)
  user_agent: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36"

  # 送信元IPを偽装: X-Forwarded-For と True-Client-IP の両方をこの値に設定し、
  # クライアントが既に設定していた値を上書きする(空にすると無効化)
  # client_ip: "1.2.3.4"

  # このヘッダー順で送出する。リストにないヘッダーは末尾に追加される
  header_order:
    - "Host"
    - "User-Agent"
    - "Accept"
    - "Accept-Language"
    - "Accept-Encoding"
    - "Connection"

  # ヘッダーを追加または上書き
  add_headers:
    Accept-Language: "ja,en-US;q=0.9,en;q=0.8"

  # 転送前に削除するヘッダー
  remove_headers: []

http2:
  enabled: true

  # SETTINGSフレームのエントリ — idと順序の両方がHTTP/2フィンガープリントに影響する。
  # RFC 7540 §11.3 のID:
  #   1=HEADER_TABLE_SIZE  2=ENABLE_PUSH  3=MAX_CONCURRENT_STREAMS
  #   4=INITIAL_WINDOW_SIZE  5=MAX_FRAME_SIZE  6=MAX_HEADER_LIST_SIZE
  settings:
    - { id: 1, val: 65536 }    # ここではChromeのデフォルト値を例示
    - { id: 2, val: 0 }
    - { id: 4, val: 6291456 }
    - { id: 6, val: 262144 }

  # コネクションレベルのWINDOW_UPDATE増分
  window_update: 15663105

  # HEADERSフレーム内の疑似ヘッダーの順序
  pseudo_header_order: [method, authority, scheme, path]

管理API

プロキシ起動時、mgmt_listen(デフォルト 127.0.0.1:8081)にも軽量なHTTP APIが公開されます。Chrome拡張機能はこれを使ってプロキシを再起動せずに実行時の設定を読み書きします。curlから直接呼び出すこともできます:

POST /api/config は本当の意味での部分更新です。変更したいフィールドだけを送れば、TLSプリセットやアップストリームの選択を含め、それ以外はそのまま維持されます。

root@kitploit:~
# 現在の設定を読む
curl http://127.0.0.1:8081/api/config

# Firefoxのフィンガープリントに切り替え、偽装IPを設定(他のフィールドは変更しない)
curl -s -X POST http://127.0.0.1:8081/api/config \
  -H "Content-Type: application/json" \
  -d '{"tls_preset":"firefox","client_ip":"203.0.113.1"}'

# 実行時に任意のJA3/JA4フィンガープリントへ切り替える — config.yamlのcustom_helloブロックと
# 同じフィールドをJSONとして送信する(後述の「カスタムTLSフィンガープリント」を参照)
curl -s -X POST http://127.0.0.1:8081/api/config \
  -H "Content-Type: application/json" \
  -d '{
    "tls_preset": "custom",
    "custom_hello": {
      "cipher_suites": [2570, 4865, 4866, 4867, 49195, 49199, 49196, 49200, 52393, 52392, 49171, 49172, 156, 157, 47, 53],
      "curves": ["X25519", "P256", "P384"],
      "versions": ["1.3", "1.2"],
      "extensions": [2570, 0, 23, 65281, 10, 11, 35, 16, 5, 18, 13, 51, 45, 43, 27, 21]
    },
    "client_ip": "",
    "user_agent": ""
  }'

# アップストリームプロキシを有効化し、名前で選択する — TLSプリセット・送信元IP・
# User-Agentはそのまま維持される
curl -s -X POST http://127.0.0.1:8081/api/config \
  -H "Content-Type: application/json" \
  -d '{"upstream_enabled": true, "upstream_select": "residential_us"}'

# 現在のアップストリームの状態を読む
curl -s http://127.0.0.1:8081/api/upstream

変更は新規接続から即座に反映されます。APIを完全に無効化するには mgmt_listen: "" を設定してください。

ブラウザ別フィンガープリント早見表

カスタムTLSフィンガープリント(preset: "custom")

組み込みのプリセット(chrome、firefox、safari など)で大半のケースはカバーできます。特定のブラウザバージョンや、これらのプリセットとは異なるフィンガープリントに合わせたい場合は、preset: "custom" を設定し custom_hello ブロックを指定してください。

JA3 / JA4と設定フィールドの対応

JA3・JA4は一方向ハッシュのため、ハッシュ値から元の仕様を逆算することはできません。対象ブラウザの実際のパラメータは tls.peet.ws やWiresharkで調べ、それを custom_hello に転記してください。

Chrome 131の例

root@kitploit:~
tls:
  preset: "custom"
  custom_hello:
    cipher_suites:      # 16進ID。0x0a0a = GREASEプレースホルダー(接続ごとにランダム化)
      - 0x0a0a
      - 0x1301          # TLS_AES_128_GCM_SHA256
      - 0x1302          # TLS_AES_256_GCM_SHA384
      - 0x1303          # TLS_CHACHA20_POLY1305_SHA256
      - 0xc02b          # ECDHE-ECDSA-AES128-GCM-SHA256
      - 0xc02f          # ECDHE-RSA-AES128-GCM-SHA256
      - 0xc02c          # ECDHE-ECDSA-AES256-GCM-SHA384
      - 0xc030          # ECDHE-RSA-AES256-GCM-SHA384
      - 0xcca9          # ECDHE-ECDSA-CHACHA20-POLY1305
      - 0xcca8          # ECDHE-RSA-CHACHA20-POLY1305
      - 0xc013          # ECDHE-RSA-AES128-SHA
      - 0xc014          # ECDHE-RSA-AES256-SHA
      - 0x009c          # RSA-AES128-GCM-SHA256
      - 0x009d          # RSA-AES256-GCM-SHA384
      - 0x002f          # RSA-AES128-SHA
      - 0x0035          # RSA-AES256-SHA
    curves:             # X25519 | X25519Kyber768 | P256 | P384 | P521
      - "X25519Kyber768"
      - "X25519"
      - "P256"
    versions:           # アドバタイズするTLSバージョン
      - "1.3"
      - "1.2"
    extensions:         # 拡張タイプIDを順序通りに(JA3のextensions要素を制御)
      - 0x0a0a          # GREASE
      - 0               # server_name (SNI)
      - 23              # extended_master_secret
      - 65281           # renegotiation_info
      - 10              # supported_groups
      - 11              # ec_point_formats
      - 35              # session_ticket
      - 16              # ALPN
      - 5               # status_request
      - 18              # signed_certificate_timestamp
      - 13              # signature_algorithms
      - 51              # key_share
      - 45              # psk_key_exchange_modes
      - 43              # supported_versions
      - 27              # compress_certificate
      - 17513           # application_settings (ALPS)
      - 0x0a0a          # GREASE
      - 21              # padding

対応している拡張タイプID

実行時の変更: preset: "custom" は config.yaml に限定されません。管理API(前述の「管理API」セクションを参照。POST /api/config に custom_hello オブジェクトを送信)や、Chrome拡張機能のTLS Presetドロップダウンからも、プロキシを再起動せずに実行時に切り替えられます。

アップストリームプロキシ

デフォルトではプロキシはターゲットに直接接続するため、X-Forwarded-For / True-Client-IP の偽装(前述)はリクエストが「主張する」内容を変えるだけで、TCP接続の実際の送信元IPは自分のままです。upstream.enabled: true を設定すると、ターゲットへの接続をまずSOCKS5またはHTTP CONNECTプロキシ経由にするため、実際のegress IPも変わります。これにより、偽装可能なヘッダーを無視して接続元IP自体を見るWAFルールをテストしたり、「フィンガープリントは正常だがIPが悪い」場合と「IPは綺麗だがフィンガープリントが変」な場合を切り分けたりできます。

対応しているのはトンネルを張れるスキーム(socks5、socks5h、http(CONNECT))のみです。どちらも生のTCPトンネルを返し、それをプロキシ自身がuTLSでラップするため、このツールが制御しようとしているClientHelloとHTTP/2フレーミングは一切変更されずにそのまま通過します。https://(TLSを終端するタイプ)のアップストリームはサポートされていません。TLSを自分で復号・再確立してしまい、uTLSのフィンガープリントが自分のものに置き換わってしまうためです。

root@kitploit:~
upstream:
  enabled: false                         # デフォルトはオフ。再起動なしで実行時に切り替え可能
  select: "residential_us"               # プロキシ名 | "rotate" | "random" | ""(先頭のプロキシ)
  dial_timeout_ms: 15000
  suppress_ip_headers_when_active: true  # アップストリーム有効時はXFF/True-Client-IPを送らない — 綺麗なIPが偽装ヘッダーを名乗る矛盾を防ぐ
  proxies:
    - name: residential_us
      url: "socks5://user:[email protected]:1080"   # ホスト名はプロキシ側で解決される(SOCKS5h相当の挙動)。ローカルでは解決しない
    - name: datacenter
      url: "http://user:[email protected]:8080"
    - name: tor
      url: "socks5://127.0.0.1:9050"                   # 無料で試せる: brew install tor && brew services start tor

TLSプリセットと同様に、実行時にもプロキシを切り替えられます。Chrome拡張機能の「Upstream proxy」トグル・ドロップダウンから、または:

root@kitploit:~
curl -s -X POST http://127.0.0.1:8081/api/config \
  -H "Content-Type: application/json" \
  -d '{"upstream_enabled": true, "upstream_select": "residential_us"}'

GET /api/upstream とChrome拡張機能のドロップダウンには、常にプロキシの名前しか表示されません。URLや認証情報がプロキシプロセスの外に出ることはありません。

実際に効いているかの確認方法: アップストリームを有効化する前後で実際のegress IPを確認し(例: curl --proxy http://127.0.0.1:8080 https://ifconfig.me)、あわせてtls.peet.wsでフィンガープリントに影響がないことも確認してください。ネットワーク経路だけが変わっているので、upstream.enabled のオン・オフに関わらずJA3/JA4とHTTP/2フィンガープリントは一致するはずです。

注意点: ブラウザは(curlと違って)オリジンごとに接続を保持・再利用します。select を切り替えたり enabled をトグルしたりした直後に、すでに接続済みのタブをただリロードしただけだと、ブラウザが新しい接続を張らずに既存の接続を再利用してしまうことがあります。その場合、実際に新規接続が発生するまで変更が反映されているように見えません。切り替えが効いていないように見える場合は、新しいシークレットウィンドウで試すか、chrome://net-internals/#sockets でソケットプールをフラッシュしてください。

接続を受け付けたからといって、そのプロキシを信用しないでください。 SOCKS5/CONNECTのハンドシェイクが成功したからといって、そのプロキシが正直に動いているとは限りません。悪意のあるプロキシは生のバイト列をトンネリングする代わりに、自分自身でTLSを終端し、自分の証明書を返すことができます。そうなると、本来エンドツーエンドで暗号化されているはずの通信を、まるごと読まれる(あるいは改ざんされる)ことになります。自分で用意したのではないプロキシを信頼する前には、必ずこれを確認してください: そのプロキシ経由で https://tls.peet.ws にアクセスし、(a)証明書エラーが出ないこと、(b) upstream.enabled: false のときと同じJA4になることを確認します。証明書エラーが出たり、JA4が変わっていたりする場合、その「プロキシ」はトンネリングではなく通信を傍受しています — そこには何も流さないでください。

Docker: ホストマシンを指すアップストリームURL(例: ローカルのTorインスタンス socks5://127.0.0.1:9050)は、コンテナ内ではそのままでは名前解決できません。ここでの 127.0.0.1 はホストではなくコンテナ自身のループバックだからです。代わりに socks5://host.docker.internal:9050(Docker DesktopのMac/Windows)や、コンテナのデフォルトゲートウェイIP(Linux)を使ってください。

使い方

プロキシを起動する

root@kitploit:~
make run
# ポート8080で動いている既存プロセスを終了し、再ビルドして起動する

フィンガープリントのプロファイルを切り替えるには、config.yaml を編集して make run を再実行してください。

curl

root@kitploit:~
# CAをシステム全体で信頼させている場合(make trust-ca 実行後):
curl --proxy http://127.0.0.1:8080 https://tls.peet.ws/api/all

# システムに信頼させていない場合 — CAを明示的に指定:
curl --proxy http://127.0.0.1:8080 --cacert ca.crt https://tls.peet.ws/api/all

Chrome拡張機能

chrome-extension/ ディレクトリには、ブラウザのツールバーからプロキシを操作するManifest V3拡張機能が入っています。

Chrome拡張機能のポップアップ

インストール:

方法A — Chrome Web Store(推奨): Chrome Web Store

方法B — パッケージ化されていない拡張機能を読み込む(開発用、または未リリースの変更を試す場合):

  1. Chromeで chrome://extensions を開く
  2. デベロッパーモードを有効化(右上のトグル)
  3. パッケージ化されていない拡張機能を読み込むをクリックし、chrome-extension/ フォルダを選択

操作項目:

User-Agentの適用範囲: この拡張機能が変更するのはHTTPの User-Agent ヘッダーのみです。JavaScriptの navigator.userAgent はChrome自体が制御しており、影響を受けません。両方を同時に偽装するには、プロキシ設定と併せてChromeを --user-agent="..." オプション付きで起動してください。

Playwright(Node.js)

root@kitploit:~
const { chromium } = require('playwright');

const browser = await chromium.launch();
const context = await browser.newContext({
  proxy: { server: 'http://127.0.0.1:8080' },
});
// CAがシステムキーチェーンに入っていない場合は、起動前に設定:
// NODE_EXTRA_CA_CERTS=./ca.crt node script.js
const page = await context.newPage();
await page.goto('https://tls.peet.ws/api/all');

管理APIでプリセットを切り替えながら、WAFの許可/ブロック判定を記録していくような、より実践的な例はexamples/waf-fingerprint-test.jsを参照してください。

Playwright(Python)

root@kitploit:~
from playwright.sync_api import sync_playwright

with sync_playwright() as p:
    browser = p.chromium.launch()
    context = browser.new_context(proxy={"server": "http://127.0.0.1:8080"})
    page = context.new_page()
    page.goto("https://tls.peet.ws/api/all")

CAがシステム全体で信頼されていない場合は、NODE_EXTRA_CA_CERTS(Node)または REQUESTS_CA_BUNDLE(Python)を設定してください。

フィンガープリントの検証

tls.peet.ws は受け取ったリクエストのフィンガープリントを詳細に返してくれます。jq やPythonに通すと見やすくなります:

root@kitploit:~
curl -s --proxy http://127.0.0.1:8080 --cacert ca.crt \
  https://tls.peet.ws/api/all | python3 -m json.tool

確認すべき主なフィールド:

プロジェクト構成

root@kitploit:~
impersonate-proxy/
├── main.go                   # エントリーポイント
├── config/config.go          # YAML設定の構造体とデフォルト値
├── fp/dialer.go              # uTLSダイアラー — TLSフィンガープリントのプリセット
├── h2fp/conn.go              # HTTP/2フレーマー — SETTINGS / WINDOW_UPDATE / 疑似ヘッダー制御
├── mitm/ca.go                # MITM CA: リーフ証明書の生成・キャッシュ・発行
├── upstream/                 # アップストリームSOCKS5/HTTP-CONNECTプロキシ: マネージャー、ダイアラー、選択ロジック
├── proxy/proxy.go            # プロキシサーバー: CONNECT処理、プロトコル分岐、実行時設定
├── rewrite/headers.go        # HTTPヘッダー書き換え(UA、順序、追加/削除、IP偽装)
├── mgmt/server.go            # 管理HTTP API(/api/config, /api/upstream)
├── chrome-extension/
│   ├── manifest.json         # Manifest V3
│   ├── popup.html            # ツールバーポップアップUI
│   ├── popup.css
│   ├── popup.js               # プロキシトグル + アップストリームトグル + 管理APIクライアント
│   ├── icon.svg
│   └── icon16.png, icon48.png, icon128.png  # ツールバー / Web Store用アイコン
├── config.yaml               # デフォルト設定
├── config.docker.yaml        # docker-compose.ymlが使用する設定
├── examples/
│   └── waf-fingerprint-test.js  # Playwrightハーネス: プリセットを切り替えながらWAFの判定結果を記録
├── Dockerfile
├── docker-compose.yml
└── Makefile

Makefileターゲット

クリーンアップ

バイナリと生成されたCAファイルを削除します:

root@kitploit:~
make clean

CAをmacOSシステムキーチェーンに追加していた場合は、キーチェーンアクセス(「impersonate-proxy CA」で検索)から削除するか、以下を実行してください:

root@kitploit:~
sudo security delete-certificate -c "impersonate-proxy CA" /Library/Keychains/System.keychain

既知の制限

  • MITM前提: プロキシは通信を復号・再暗号化します。クライアントは生成されたCAを信頼している必要があります。
  • クライアント側はHTTP/2非対応: クライアント→プロキシ間はHTTP/1.1(CONNECT経由)です。プロキシ→サーバー間のみカスタムフィンガープリント付きのHTTP/2を使用します。
  • チャンク転送のリクエストボディ: Transfer-Encoding: chunked を伴うリクエストボディは現時点で正しく転送されません。
  • QUIC / HTTP/3非対応: 対象外です。
  • User-Agent(HTTPヘッダーのみ): プロキシはHTTPの User-Agent ヘッダーを書き換えますが、JavaScriptの navigator.userAgent はブラウザが独自に設定するため影響を受けません。両方を同時に上書きするにはChromeの --user-agent 起動オプションを使用してください。
  • アップストリームプロキシはTCPトンネルのみ対応: socks5 / socks5h / http(CONNECT)のアップストリームのみサポートしています。TLSを自分で終端するタイプのアップストリームはuTLSのClientHelloを壊してしまうため、起動時に拒否されます。アップストリームプロキシを参照してください。

法的注意事項

本ツールは 許可されたセキュリティテストのみ を目的としています。例えば、自分が所有するシステムや、書面による明示的なテスト許可を得ているシステムに対するWAF・ボット検知設定のテストなどです。

許可を得ていないシステムに対して本ツールを使用することは、適用される法律(米国のComputer Fraud and Abuse Act、日本の不正アクセス禁止法、または各法域における同等の法令など)や対象の利用規約に違反する可能性があります。

作者は誤用による一切の責任を負いません。

謝辞

  • uTLS — TLSフィンガープリントのカスタマイズ
  • tls.peet.ws — 例で使用しているフィンガープリント検査API
  • JA4+ — フィンガープリント標準の参考資料

License

License: MIT

ツールをダウンロード
True-Client-IP
HTTP/2SETTINGSの値と順序、WINDOW_UPDATE、疑似ヘッダーの順序(HTTP/2フィンガープリント)
エンドポイントメソッド説明
/api/configGET現在の設定をJSONで返す(現在の custom_hello とアップストリームの状態を含む)
/api/configPOSTTLSプリセット / custom_hello / 送信元IP / User-Agent / アップストリームの有効化・選択を部分的に更新する — 指定しなかったフィールドは変更されない
/api/upstreamGETアップストリームの状態を返す: enabled、select、設定済みプロキシの名前(URLや認証情報は含まない)、IPヘッダー抑制が有効かどうか
ブラウザTLSプリセットHTTP/2 SETTINGSWINDOW_UPDATE
Chromechrome1:65536,2:0,4:6291456,6:26214415663105
Firefoxfirefox1:65536,4:131072,5:1638412517377
Safarisafari1:4096,3:100,4:2097152,6:1638410485760
フィンガープリント要素設定フィールド備考
TLSバージョン範囲versions最小/最大は自動的に算出される
暗号スイートのリストと順序cipher_suitesGREASEのプレースホルダーとして 0x0a0a を使用。uTLSが接続ごとにランダム化する
拡張タイプIDと順序extensions順序がJA3のextensions要素を直接左右する。GREASEパターン(0xXAXA)に一致する値は接続ごとにランダム化される
サポートするグループ(曲線)curves送信されるキーシェアも制御する
ID名前備考
0xXAXA(GREASEパターン全般)GREASE接続ごとにランダム化
0server_name (SNI)
5status_requestOCSPステープリング
10supported_groupscurves リストを使用
11ec_point_formats固定: uncompressed (0)
13signature_algorithmsChrome相当のデフォルト
16ALPNh2、http/1.1 をアドバタイズ
18signed_certificate_timestamp
21paddingBoringSSL方式のパディング
23extended_master_secret
27compress_certificate
28record_size_limit固定: 0x4001
35session_ticket
43supported_versionsversions リストを使用
45psk_key_exchange_modesPSK with DHE
50signature_algorithms_certChrome相当のデフォルト
51key_sharecurves に基づくX25519・P256のキーシェア
17513application_settings (ALPS)h2 をアドバタイズ
17613application_settings (ALPS, 新コードポイント)h2 をアドバタイズ。Chrome 133以降は17513の代わりにこちらを送信
65037encrypted_client_hello (ECH)GREASE ECHペイロード(BoringSSL方式)
65281renegotiation_info
その他GenericExtension空ペイロードで送信
操作項目内容
プロキシトグルChromeのプロキシ設定を有効/無効化(:8080 経由でトラフィックをルーティング)
TLS PresetuTLSのフィンガープリントプリセットを切り替え(chrome / firefox / safari / edge / ios / random / golang / custom)
Cipher Suites / Curves / TLS Versions / ExtensionsCustom (JA3/JA4) 選択時に表示 — config.yaml の custom_hello と同じフィールドで、YAMLを編集したりプロキシを再起動したりせずに任意のJA3/JA4フィンガープリントを指定できる
Client IP全リクエストに X-Forwarded-For と True-Client-IP を設定
User-AgentHTTPの User-Agent ヘッダーを上書き
Upstream proxyアップストリームのSOCKS5/HTTP-CONNECTプロキシ経由のルーティングを有効化し、使用するプロキシ(または rotate/random)を選択する — アップストリームプロキシを参照
Applyボタン新しい設定を管理APIにPOSTする。即座に反映される
APIフィールド管理APIのアドレス(デフォルト http://127.0.0.1:8081)
フィールド説明
tls.ja3_hashJA3フィンガープリントハッシュ
tls.ja4JA4フィンガープリント文字列
http2.akamai_fingerprintHTTP/2フィンガープリント文字列(SETTINGS + WINDOW_UPDATE + 疑似ヘッダー順)— フィールド名はtls.peet.ws側のAPI仕様による
http1.headersサーバーが受信したヘッダー名の順序
user_agentサーバー側から見えるUser-Agent
ipサーバー側から見える送信元IP — X-Forwarded-For / True-Client-IP の偽装をここで確認
ターゲット説明
make buildバイナリをコンパイル
make runビルドし、既存プロセスを終了させてから起動
make trust-caca.crt をmacOSシステムキーチェーンに追加(sudoが必要)
make cleanバイナリ、ca.crt、ca.key を削除
make docker-buildDockerイメージをビルド(Docker参照)
make docker-runビルドしてバックグラウンドで起動
make docker-stopコンテナを停止・削除