TLSフィンガープリンティングとJA4ハッシュの仕組み

すべてのHTTPS接続はTLSハンドシェイクから始まり、すべてのTLSハンドシェイクはClient Helloメッセージから始まります。このメッセージには、接続してくるクライアントに関する豊富な情報（暗号スイート、拡張、サポートする曲線、署名アルゴリズム）が含まれており、それらはブラウザ・バージョン・オペレーティングシステムによって大きく異なります。TLSフィンガープリンティングはこの情報を捉え、識別シグナルとして利用します。

Client Helloには何が含まれるのか

ブラウザがHTTPSサーバに接続する際、次の情報を含むClient Helloメッセージを送信します。サポートするTLSバージョン、使用してもよい暗号スイートのリスト、含めるTLS拡張（SNI、ALPN、key shareなど）、サポートする楕円曲線、受け入れる署名アルゴリズム、そして提供する圧縮方式です。

各ブラウザファミリは固有のフィンガープリントを持ちます。Chrome、Firefox、Safariはいずれも異なる暗号スイートの並び順、異なる拡張のセット、異なる曲線の優先順位を送信します。同じブラウザファミリ内であっても、暗号スイートが追加または非推奨化されるにつれ、バージョンごとにわずかに異なるClient Helloメッセージを送信することがあります。

JA3からJA4へ

JA3は2017年にSalesforceが導入した、最初のTLSフィンガープリンティング用ハッシュでした。TLSバージョン、暗号スイート、拡張、楕円曲線、EC点形式を1つの文字列に連結し、MD5ハッシュを計算します。画期的ではあったものの、JA3には限界があります。分析が難しい単一の不透明なハッシュを生成し、いずれかのフィールドの些細な変化が完全に異なるハッシュを生み出してしまうのです。

2023年にFoxIOが導入したJA4は、いくつかの点でJA3を改善しています。3つの構成要素からなる構造化されたフィンガープリントを生成します。人間に読めるプレフィックス（「t13d1715h2」のような形式 — TLS 1.3、17個の暗号スイート、15個の拡張、HTTP/2）、暗号スイートの順序付きハッシュ、そして拡張の順序付きハッシュです。この構造により、JA4フィンガープリントは識別に必要な精度を保ちつつ、ひと目で分析可能になります。

TLSフィンガープリントがデバイスインテリジェンスにとって重要な理由

TLSフィンガープリントが価値を持つのは、JavaScriptが実行される前に収集されるからです。ユーザーエージェントを偽装し、canvasレンダリングを偽り、navigatorのプロパティにパッチを当てるボットであっても、実際に使用しているTLSライブラリから本物のClient Helloメッセージを送信します。Client Helloが「Goのcrypto/tlsライブラリ」だと示しているのにユーザーエージェントが「Chrome 124」だと主張していれば、何かが偽装されていると分かります。

このクロス検証はボット検知において極めて強力です。大半の自動化フレームワーク（Selenium、Puppeteer、Playwright）はブラウザネイティブのTLSスタックを使用するため、そのTLSフィンガープリントは操作対象のブラウザと一致します。しかしカスタムHTTPクライアント、Goベースのスクレイパー、requestsライブラリを使うPythonスクリプトは、いずれも固有のTLSフィンガープリントを持ち、ブラウザ以外のクライアントであることが即座に判別されます。

TLSフィンガープリントの安定性

TLSフィンガープリンティングにおける懸念の1つは、ブラウザ更新をまたいだ安定性です。Chromeが暗号スイートを追加または削除すると、TLSフィンガープリントは変化します。実際には、これは予想よりも起こりにくい事象です。Chromeの暗号スイートのリストは比較的安定しており、大きな変化はバージョンごとではなく年に1〜2回発生します。

ここでJA4の構造化された形式が役立ちます。人間に読めるプレフィックスはマイナーバージョンの変化をまたいでも安定を保つため（暗号スイートと拡張の数はそう頻繁には変わりません）、詳細なハッシュが変化したときでも、プレフィックスが連続性を提供します。私たちのマルチティア識別システムでは、TLSフィンガープリントのデータはTier 2に配置されています。識別に寄与するのに十分安定していますが、想定されるドリフトに対処するためセッション横断のマッチングを通して処理されます。

サーバサイドでの収集

JavaScriptの実行を必要とするクライアントサイドのシグナルとは異なり、TLSフィンガープリントは完全にサーバサイドで収集されます。私たちのエッジサーバは、接続が確立される前に生のTLSハンドシェイクを検査し、Client Helloを抽出します。つまりTLSフィンガープリンティングは、JavaScriptがブロックされていても、ブラウザにプライバシー拡張がインストールされていても、クライアントがそもそもブラウザでなくても機能するのです。

このサーバサイドという性質により、TLSフィンガープリントはなりすましにも耐性を持ちます。特定のブラウザを模倣するカスタムTLS Client Helloを作り込むことは理論上は可能ですが、それには低レベルでのTLS実装が必要であり、ユーザーエージェント文字列を変更するよりもはるかに手間がかかります。大半のなりすましツールはそれを試みません。

Device Identificationとの統合

私たちのデバイス識別エンジンにおいて、TLSフィンガープリントはシグナルとバリデータの両方の役割を果たします。シグナルとしては、独自の識別ウェイトを持って全体のデバイスフィンガープリントに寄与します。バリデータとしては、申告されたブラウザのアイデンティティに対するクロスチェックを提供します。JavaScriptのシグナルが「macOS上のChrome」だと示しているのにTLSフィンガープリントが「Linux上のFirefox」だと示していれば、その食い違いがSmart Signals分析における改ざんフラグを立てます。