In this Article
アンチボット対策は新たなセキュリティ上の課題に応じて進化しており、正当なスクレイパーまでブロックされることがあります。そうした対策の一つがTLSフィンガープリンティングです。これは、サーバーへの接続を試みるデバイスを識別する、巧妙で比較的新しい効果的な手法です。なぜ回避が簡単ではないのか、必要なデータを問題なくスクレイピングするにはどうすればよいのかを、本記事で解説します。
そもそもTLSとは？
TLSフィンガープリンティングを理解するには、まずTLSそのものを確認しましょう。 TLSまたはTransport Layer Security（以前のSSL – Secure Sockets Layer）は、標準的なHTTP接続を介した通信を保護するプロトコルです。URL付近に鍵のマークが表示されていたり、Webサイトのアドレスがhttpsで始まっていたりする場合は、TLSが有効であることを示します。現在では、TLSを使用していないWebサイトを見つけるほうが難しいでしょう。「http」（「s」なし）で始まるWebサイトにアクセスしようとすると、ブラウザはページを表示する代わりに、安全でない接続に関する警告を表示します。
TLSは、データをターゲットサーバーに送信する前に暗号化します。つまり、9823h4brjhvbiのようなランダムな文字列に変換されるため、悪意のある第三者が情報を傍受しても利用できません。ただし、データを送信する前に、TLSは正当なサーバーに情報を送っていることを確認し、そのサーバー側で復号できるようにする必要があります。そのため、TLSはデータ送信前にまず接続を確立します。ターゲットサーバーと一連のメッセージを交換してサーバーを検証し、暗号化方式に合意し、通信中にデータを保護して復号するための共有セッションキーを生成します。
この一連の処理はTLSハンドシェイクと呼ばれ、「ClientHello」メッセージから始まります。TLSフィンガープリンティングで重要なのはこのメッセージです。サーバーがユーザーを識別する際に利用するデータの元になるためです。
「ClientHello」メッセージの構成要素
「ClientHello」メッセージには認証情報のような機密データは含まれず、暗号化されないまま送信されるため、Wiresharkのようなネットワーク解析ツールを使えば簡単に取得して内容を確認できます。そこには多くのデータが含まれています。
- TLSバージョン – クライアントがサポートする最も新しいバージョン。
- Random – クライアントが生成する乱数。
- Session ID – セッション再開に使われるため、最初のハンドシェイクでは空です。
- Cipher suites – クライアントがサポートする暗号化アルゴリズム。優先順位順に列挙されます。
- Compression method – 現在ではほぼ常に0です。
- Supported extensions – クライアントが利用したい追加機能。例：
- Server Name Indication (SNI) – クライアントが要求しているホスト名を指定します。
- Application-Layer Protocol Negotiation (ALPN)プロトコル – TLS上で使用するプロトコルをネゴシエートするための拡張機能です。アプリケーション層から独立して利用できます。Webサーバーでは通常、HTTP/1.1またはHTTP/2が指定されます。
- TLSライブラリ – クライアントが使用するライブラリ。使用するライブラリはクライアントごとに異なります。
- Signature algorithms – サーバーの正当性を検証するためにサポートされるアルゴリズムの一覧。
- Elliptic curves – 暗号化通信では有限体上の曲線方程式を使用するため、この部分で使用する曲線を示します。
- Elliptic curve point formats – 点がどのようにエンコードされるかを示します。
このほかにも拡張機能があります。これらの情報から、Webサイトは「ClientHello」メッセージを基に、ブラウザの系統、デバイスの種類、セキュリティ状態など、ソフトウェアスタックに関する多くの情報を推測できます。
JA3フィンガープリンティング手法
では、サーバーが「ClientHello」メッセージを受信した後はどうなるのでしょうか。ここでJA3手法が登場します。これはSalesforceが管理する、最も一般的なフィンガープリンティング手法です。この手法は、メッセージ内の5つの主要コンポーネント、すなわちTLSバージョン、cipher suites、拡張ID、サポートされるグループ（楕円曲線）、楕円曲線点形式に注目します。各要素は10進数に変換され、カンマとハイフンで連結されます。ただし、実際のフィンガープリントデータは長い文字列になるため、利便性のために暗号学的ハッシュ関数であるMD5が使用されます。これにより固定長の128-bitハッシュが生成されます。その後、サーバーはその結果を、多くの場合は内部データベース内の他のフィンガープリント候補と比較します。ただし、公開データベースが使用される場合もあります。
目的は違いを見つけることです。このクライアントが一般的なWebブラウザに見えるか、それとも不審な点があるかを判断します。問題は、Chromeのような通常のWebブラウザが生成するハッシュと、Webスクレイピングに使用されるプログラミングライブラリが生成するハッシュは異なるという点です。それぞれのClientHelloメッセージが異なるためです。JA3アルゴリズムは少数の変数のみを考慮するため、固有のフィンガープリントの選択肢は多くありません。そのため、通常のユーザーとスクレイピングボットを比較的簡単に区別できます。
このことから、TLSフィンガープリンティングはスクレイパー対策として有効であり、Webスクレイピングに依存する人々にとって大きな障壁になっていることが分かります。
JA3フィンガープリントを収集するアンチWebスクレイピング用のデータベースも存在します。円滑にアクセスするため、自身のフィンガープリントを計算し、ホワイトリストに登録されているか確認できます。
ただし、接続中のクライアントがスクレイパーであることを示すのは、JA3フィンガープリントだけではありません。ClientHelloメッセージ自体の値の違いでさえ、アンチボットシステムを作動させる可能性があります。例：
- SNIがない場合、通常はリクエストに含まれることが期待されるため、危険信号と見なされる可能性があります。
- 古いALPNリクエストは、現代のブラウザが通常HTTP/2をサポートしているため、不審な活動の兆候と見なされる可能性があります。
- ChromeのようなブラウザがサポートするElliptic curvesと、プログラミングスクリプトがサポートするものは異なるため、疑念を招く可能性があります。
- Cipher Suitesの一覧は優先順位順に並んでおり、その順序も含めて一般的なWebブラウザの一覧と一致している必要があります。Extensionsについても同様です。
TLSフィンガープリンティングへの対処方法
TLSフィンガープリンティングへの対処では、スクレイパーのフィンガープリントを一般的なWebブラウザのものに近づけることが目標です。これは簡単な作業ではありませんが、試せるアイデアはいくつかあります。複数を組み合わせることもできます。
- ヘッドレスブラウザを使用する
Puppeteer、Playwright、Seleniumのような高品質なヘッドレスブラウザを使えば、実際のブラウザを利用するため、本物に近いフィンガープリントが得られます。これらはTLSフィンガープリントを変えないため、Webサイトは通常のブラウザによる接続とヘッドレスブラウザによる接続を区別しにくくなります。検出の手がかりを一つ減らせます。
- 複数のブラウザとオペレーティングシステムのバージョンの組み合わせを使う
この方法は、複数のフィンガープリントを通じて接続を分散するのに役立ちます。大規模なWebスクレイピングプロジェクトを実行する場合に有効です。
- LibCurlベースのHTTPクライアントを使用する
この種のクライアントでは、curl-impersonateを使えるように更新できます。これはlibcurlライブラリの修正版で、TLSフィンガープリントを通常のWebブラウザのものに見せかけます。libcurlをサポートするライブラリには、Typhoeus（Ruby）、Guzzle（PHP）、PyCurl（Python）、curl defaultおよびcrulコミュニティライブラリ（R）があります。
- TLSの強化
Go言語を使用しているなら幸運です。GoはTLSスプーフィングを可能にする言語の一つです。Refraction Networkingのutls、ja3transport、CycleTLSのようなライブラリが必要になります。
一方で、JavaやPythonを使用している場合はそれほど簡単ではありません。Javaでは、sslconfig.enabledCipherSuitesメソッドを使用して、有効なcipher suitesの一覧を再構成できます。Pythonでは、requestsとhttpxを使用してCipher SuiteとTLSバージョンの変数を設定する程度まで可能です。これらの値をスプーフィングすることでアクセスの中断を解消できる場合もありますが、それでもフィンガープリントが完全に本物らしく見えるとは限りません。
- 他の要素をローテーションする
すべてのトラフィックが同じTLSフィンガープリントを持っている場合（たとえ本物らしく見えても）、不審に見える可能性があります。Cookie、ユーザーエージェント、ヘッダー、IPアドレスなど、変更可能な要素をローテーションしてください。これによりClientHelloメッセージがわずかに変化し、その結果、JA3フィンガープリントも多少異なるものになります。 マルチアカウントブラウザと高品質なプロキシがこれを支援します。
最後に
最後に、TLSフィンガープリンティングに対応するのは難しい場合があります。WebサイトごとにTLSプロトコルの実装がわずかに異なり、アクセスの許可・拒否に独自の基準やデータベースを用いているためです。TLSフィンガープリントを適切にスプーフィングするには、Webサイトごとに検証し、どの要素がフィンガープリンティングの検出を作動させるのか、標準プロトコルをどのようにカスタマイズしているのかを特定してください。さらに、現在のWebサイトはJA3フィンガープリンティングのようなネットワークレベルのシグナルと、フォントや画面解像度のようなアプリケーションレベルのシグナルを組み合わせているため、TLSスプーフィングだけでは不十分です。スクレイパーのあらゆる詳細が本物らしく見えるようにする必要があります。また、すべてを定期的に見直してください。Webサイトはポリシーや検出スキームを頻繁に更新し、新しいアンチボット手法も登場するため、正確なデータを取得するにはこちらも同じように対応しなければなりません。 もちろん、常に許可された範囲内にとどまり、利用可能なデータのみをスクレイピングし、ターゲットWebサイトに過度な負荷をかけず、合法的に取得されたプロキシなどの信頼できるツールを使用する必要があります。 DataImpulseは、最後の点で確実にお役に立てます。「今すぐ試す」ボタンを押すか、ご不明な点があれば[email protected]までお問い合わせください。