mandatoryprogrammer/thermopticHTTP-прокси следующего поколения для скрытной работы, который идеально маскирует запросы под браузер Chrome на всех уровнях стека.
«Не могу поверить, термооптический камуфляж!»
Это 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
(То же самое касается и нашего JA4 TLS-отпечатка, и т. д.).
## Настройка
Чтобы запустить прокси `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 предназначено для хостов NVIDIA, на которых уже установлены Docker-рантайм/тулкит NVIDIA. Оно резервирует GPU-устройство, монтирует `/dev/dri` и позволяет встроенному контейнеру Chrome переключиться на путь рендеринга NVIDIA/Vulkan. Чтобы использовать это, выполните `docker compose -f docker-compose.yml -f docker-compose.gpu.yml up --build`.
## Возможности
- 🕵️ [Проксирование с паритетом браузера](#how-does-this-cloaking-work-exactly), которое воспроизводит запросы через реальную сессию Chrome, чтобы соответствовать отпечаткам JA4 байт в байт.
- 🤝 Для интеграции вашего HTTP-клиента (например, `curl`, `requests` и т.д.) с `thermoptic` требуется мало или вообще не требуется пользовательского кода — просто [настройте прокси](#setup), и ваши отпечатки будут обработаны.
- 🪝 [Каркас хуков](#handling-browser-javascript-fingerprinting-with-thermoptic-hooks) для автоматизации before-request/after-request/on-start, позволяющий управлять полным браузером для решения задач или сбора артефактов.
- 📘 Пример хука для решения Cloudflare turnstile можно увидеть в [`./hooks/onstart.js`](https://github.com/mandatoryprogrammer/thermoptic/blob/main/hooks/onstart.js).
- 🖥️ [Веб-интерфейс управления браузером](#control-the-dockerized-chrome-browser-via-web-ui-xpra) (по адресу `http://127.0.0.1:14111`) для управления окном браузера Chrome в Docker. Полезен для ручного входа на сайты, после чего можно seamlessly использовать прокси для выполнения запросов от имени вашей авторизованной сессии (а также для отладки).
- 🔌 Задайте 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)](https://chromedevtools.github.io/devtools-protocol/) для управления браузером и настройки страницы, которая имитирует запрос точно так, как он обычно происходит в реальном веб-браузере.
* `thermoptic` запускает запрос через имитированный контекст и перехватывает HTTP-ответ.
* `thermoptic` отправляет HTTP-ответ обратно клиенту.
Благодаря тому, что запрос фактически выполняется браузером с использованием всего его стека, результирующие отпечатки JA4 идентичны.
ПРИМЕЧАНИЕ. Поскольку многие WAF используют JavaScript-фingerprinting на уровне браузера, `thermoptic` также предоставляет хуки для использования браузера на ключевых этапах процесса scraping. Дополнительную информацию см. в [этом разделе](#handling-browser-javascript-fingerprinting-with-thermoptic-hooks).
## Почему именно *такой* подход, а не другие решения?
Если говорить прямо: другие подходы имеют фундаментальные недостатки, которые мешают им быть практичным долгосрочным решением проблемы браузерного фингерпринтинга.
Многие другие попытки «обойти» JA4+ фингерпринтинг браузера делают это путём повторной реализации различных уровней стека браузера. У такого подхода есть ряд серьёзных недостатков, например:
* Требуется большая осторожность, чтобы идеально соответствовать поведению «настоящей» реализации браузера. В результате *любые* особенности или расхождения могут быть использованы для отличия таких клиентов от «настоящей» реализации браузера.
* Попытка решить проблему только на одном уровне стека. Chrome использует несколько протоколов для обеспечения работы в веб-браузере. В результате, даже если вы создали идеально совпадающий TLS-уровень, ваш HTTP-уровень может вас выдать, если он не совпадает байт в байт.
* Поскольку «настоящие» браузеры регулярно меняют своё поведение, их отпечатки меняются, и в результате эти инструменты постоянно требуют более интенсивной разработки для компенсации.