thermoptic

"Не верю, термооптический камуфляж!"

Что это?

Это HTTP-прокси, предназначенный для обхода сервисов, использующих фингерпринтинг, такой как JA4+, для блокировки определённых HTTP-клиентов. Используя этот прокси, вы можете применять свои любимые HTTP-клиенты, такие как curl, и при этом магическим образом иметь неотличимые отпечатки от настоящего (Chrome/Chromium) веб-браузера. thermoptic также включает некоторые забавные возможности для смягчения фингерпринтинга на основе JavaScript. Он также упрощает гибридный скрапинг с одновременным использованием веб-браузера и низкоуровневых HTTP-клиентов.

Даже если вы не знакомы с фингерпринтингом JA4+, если вы занимались скрапингом, вас, вероятно, уже блокировали с его помощью. Популярные сервисы, такие как Cloudflare, используют подобные техники (и другие приёмы) для обнаружения использования «нечеловеческих» HTTP-клиентов с целью блокировки запросов. Эти сервисы также могут использовать такой фингерпринтинг, чтобы определить, что вы начали сессию с настоящим браузером, а затем переключились на низкоуровневый клиент вроде curl. thermoptic решает все эти проблемы, представляя единый «настоящий» отпечаток браузера для всех запросов скрапинга.

Пример

Вот пример отпечатка JA4H (HTTP) для curl без прокси:

$ curl https://ja4db.com/id/ja4h/
ge11nn090000_b6a016211e8a_000000000000_e3b0c44298fc

Это сильно отличается от отпечатка, который создаёт Chrome при прямом переходе по URL:

ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e

Однако, когда мы используем прокси для выполнения запроса, наш отпечаток JA4H волшебным образом становится идентичным:

$ curl --proxy http://thermoptic:1234 https://ja4db.com/id/ja4h/
ge11cn19enus_f2808f0d04cf_9a10d4221160_7068f58def6e

(То же самое касается и нашего TLS-отпечатка JA4, и т. д.).

Установка

Чтобы запустить прокси thermoptic, который маскирует ваш трафик через контейнеризованный экземпляр Chrome на Ubuntu 22.04:

Обычная установка Docker (работает на хостах без среды выполнения GPU):

docker compose up --build

Вот и всё, теперь вы можете проксировать трафик через него:

curl --proxy http://127.0.0.1:1234 --insecure https://ja4db.com/id/ja4h/

Важные замечания:

• По умолчанию прокси работает без аутентификации. Если вы планируете открывать прокси наружу, обязательно настройте аутентификацию с помощью переменных окружения PROXY_USERNAME и PROXY_PASSWORD.
• Если вы не хотите использовать ---insecure, вам нужно использовать сгенерированный CA-файл, расположенный в ./ssl/rootCA.crt. Он создаётся при первом запуске thermoptic.
• Вы можете подключить thermoptic к любому экземпляру Chrome/Chromium, запущенному с флагом --remote-debugging-port. Это важно, так как вам нужно будет настроить и проксировать через более распространённые окружения, чтобы ваш отпечаток был как можно менее заметным (например, Chrome на Windows).
• GPU compose override предназначен для хостов NVIDIA, на которых уже установлены NVIDIA runtime/toolkit для Docker. Он резервирует устройство GPU, монтирует /dev/dri и позволяет встроенному контейнеру Chrome переключиться на путь рендеринга NVIDIA/Vulkan. Чтобы использовать это, запустите docker compose -f docker-compose.yml -f docker-compose.gpu.yml up --build.

Возможности

• 🕵️ Проксирование с паритетом браузера, которое воспроизводит запросы через реальную сессию Chrome, чтобы побайтово соответствовать отпечаткам JA4.
• 🤝 Требуется минимум или вовсе не требуется пользовательский код для интеграции вашего HTTP-клиента (например, curl, requests и т. д.) с thermoptic, просто настройте прокси, и ваши отпечатки будут учтены.
• 🪝 Фреймворк хуков для автоматизации before-request/after-request/on-start, чтобы вы могли управлять всем браузером для решения задач или захвата артефактов.
  • 📘 Пример хука для решения Cloudflare turnstile можно увидеть в ./hooks/onstart.js.
• 🖥️ UI управления веб-браузером (по адресу http://127.0.0.1:14111) для управления окном Dockerized Chrome. Полезно для ручного входа на сайты, а затем бесшовного использования прокси для выполнения запросов от имени вашей авторизованной сессии (и для отладки).
• 🔌 Задайте URI вышестоящего HTTP- или SOCKS-прокси через переменную окружения UPSTREAM_PROXY в docker-compose.yml.
• 🛡️ Встроенные проверки работоспособности и цикл контроля перезапуска для обнаружения зависших браузеров и автоматического восстановления без участия оператора.
• ⚡ Поддерживает HTTP/1.1 и HTTP/2, позволяя проксировать трафик по любому из этих протоколов. (Обратите внимание, что вы можете общаться с прокси по HTTP/1.1, а управляемый Chrome может согласовывать с конечным сайтом другой протокол.)

Как именно работает это маскирование?

• HTTP-запрос выполняется с использованием HTTP-клиента, такого как curl, с thermoptic, установленным в качестве прокси.
• thermoptic анализирует запрос, чтобы наилучшим образом определить, каким типом запроса браузера он должен быть (например, ручной переход по URL? Отправка формы? Запрос fetch()?).
• thermoptic использует Chrome Debugging Protocol (CDP) для управления браузером и настройки страницы, которая имитирует запрос точно так, как он обычно происходил бы в реальном веб-браузере.
• thermoptic инициирует запрос через сымитированный контекст и захватывает HTTP-ответ.
• thermoptic отправляет HTTP-ответ обратно клиенту.

Благодаря тому, что браузер фактически выполняет запрос, используя весь свой стек, итоговые отпечатки JA4 идентичны.

ПРИМЕЧАНИЕ: Поскольку многие WAF применяют фингерпринтинг веб-браузеров на уровне JavaScript, thermoptic также предоставляет хуки для использования браузера на ключевых этапах процесса скрейпинга. См. этот раздел для получения дополнительной информации об этом.

Почему этот подход, а не другие решения?

Говоря прямо: другие подходы имеют фундаментальные недостатки, которые не позволяют им быть практичным долгосрочным решением проблемы фингерпринтинга браузера.

Многие другие попытки «обойти» фингерпринтинг браузера JA4+ делают это путём повторной реализации различных слоёв стека браузера. У этого подхода есть ряд серьёзных недостатков, таких как:

• Требуется большая осторожность, чтобы идеально соответствовать поведению «реальной» реализации браузера. В результате любые особенности или расхождения могут быть использованы для отличия этих клиентов от «реальной» реализации браузера.
• Попытка решить проблему только на одном слое стека. Chrome использует несколько протоколов для обеспечения работы веб-браузера. В результате, даже если вы сделали идеально совпадающий TLS-слой, ваш HTTP-слой может вас выдать, если он не побайтово идеален.
• Поскольку «реальные» браузеры регулярно меняют своё поведение, их отпечатки меняются, и в результате эти инструменты постоянно требуют более интенсивной работы по разработке для компенсации.