JA3 / JA4 フィンガープリント

JA3 ↗ と JA4 ↗ のフィンガープリントは、接続の開始方法に基づいて TLS クライアントを識別します。クライアントの種類（ブラウザ、ボット、アプリケーション）ごとに接続の特徴が異なるため、結果のフィンガープリントは、宛先 IP、ポート、証明書が違っても安定した識別子になります。

JA4 は ClientHello の拡張を並べ替えることで JA3 を改善し、現行ブラウザのユニークなフィンガープリント数を減らし、グループ化をしやすくします。

JA4 フィンガープリントと Signals Intelligence を使う場合、Bot Management が JA4 Signals を算出または設定できないとき（TLS 以外のトラフィック、Bot Management がスキップされた場合など）に欠けるフィールドを、Workers スクリプト側で扱えるようにしてください。Bot Management が有効な Orange-to-Orange（O2O）では、JA4 Signals は eyeball（エンドユーザー）接続に対応し、O2O チェーン全体で保持されます。O2O ゾーン上のリクエストと、対応するサブリクエストも対象です。

JA4 フィンガープリントが欠ける可能性があります。
ja4Signals 配列が欠ける可能性があります（リクエストに JA4 が使えない場合など）。
NaN または Infinity の値を持つ結果は、配列から除外されます。


{
  "ja4Signals": {
    "h2h3_ratio_1h": 0.98826485872269,
    "heuristic_ratio_1h": 7.288895722013e-05,
    "reqs_quantile_1h": 0.99905741214752,
    "uas_rank_1h": 901,
    "browser_ratio_1h": 0.93640440702438,
    "paths_rank_1h": 655,
    "reqs_rank_1h": 850,
    "cache_ratio_1h": 0.18918327987194,
    "ips_rank_1h": 662,
    "ips_quantile_1h": 0.99926590919495
  },
  "jaSignalsParsed": {
    "ratios": {
      "h2h3_ratio_1h": 0.98826485872269,
      "heuristic_ratio_1h": 7.288895722013e-05,
      "browser_ratio_1h": 0.93640440702438,
      "cache_ratio_1h": 0.18918327987194
    },
    "ranks": {
      "uas_rank_1h": 901,
      "paths_rank_1h": 655,
      "reqs_rank_1h": 850,
      "ips_rank_1h": 662
    },
    "quantiles": {
      "reqs_quantile_1h": 0.99905741214752,
      "ips_quantile_1h": 0.99926590919495
    }
  }
}

JA4 Signals がない場合、出力は次のようになります。

Missing JA4 signals outputjson

{
  "ja4Signals": {},
  "jaSignalsParsed": {
    "ratios": {},
    "ranks": {},
    "quantiles": {}
  }
}

JA3 または JA4 フィンガープリントは SSL/TLS ベースの識別子です。特定の状況では、ログ上で null または空になることがあります。

JA3 と JA4 は TLS（SSL）ハンドシェイク中に算出されるため、暗号化されていない HTTP トラフィックには含まれません。
Worker が、Cloudflare ネットワーク内部のゾーン（例: 非プロキシ / 内部 O2O）またはサードパーティのオリジンへリクエストを送る場合や、Worker が対象ゾーンへトラフィックをルーティングしている場合、このフィールドは空になることがあります。
リクエストで Bot Management 自体がスキップされると、フィンガープリントが欠けることがあります。これらの値の算出と設定は Bot Management が担うためです。
TLS Session Resumption ↗ では、最初の TLS ハンドシェイクが成功したあと、以降の接続は簡略化されます。その結果、フィンガープリントは再計算されません。

Bot Management が有効な Orange-to-Orange（O2O）では、JA3/JA4 フィンガープリントは O2O チェーンを通じて保持され、eyeball（エンドユーザー）接続を表します。O2O ゾーン上のリクエストと、対応するサブリクエストの両方が対象です。

分析

ボットの可能性があるリクエストの詳細を知るには、JA3 と JA4 のフィンガープリントを次で使います。

Bot Analytics
Security Events と Security Analytics
Analytics GraphQL API（特に HTTP Requests データセット）
Logs

アクション

特定のフィンガープリントへのアプリケーションの応答を調整するには、次と組み合わせて使います。

ユースケース

特定のトラフィックをブロックまたは許可する

似たリクエストのグループは、同じ JA3 フィンガープリントを共有することがあります。そのため JA3 は、着信する脅威のブロックに役立ちます。たとえば既存の防御で捉えられないボット攻撃に気づいたら、攻撃に使われた JA3 をブロックまたはチャレンジするカスタムルールを作成します。

逆に、既存の防御が正当なトラフィックをブロックしている場合は、正常なリクエストに共通する JA3 を許可する Skip アクションのカスタムルールを作成します。

Bot Management で誤検知や見逃しをすぐ直したいときにも、JA3 は役立ちます。

モバイルトラフィックを許可する

多くの場合、モバイルアプリのトラフィックは、デバイスやユーザーが違っても同じ JA3 フィンガープリントになります。つまり、モバイルアプリのトラフィックを JA3 フィンガープリントで識別できます。

JA3 フィンガープリントを使い、モバイルアプリからのトラフィックを許可し、残りのトラフィックはブロックまたはチャレンジします。