TLS-фингерпринтинг: почему даже чистые прокси не спасают от банов

Представьте ситуацию: вы тщательно подготовились к работе с мультиаккаунтингом - настроили окружение, для каждого потока прописали уникальный резидентный прокси, уверены в чистоте ваших IP-адресов. Но после старта все ваши аккаунты один за другим улетают в бан, хотя каждый поток работал со своего уникального IP-адреса. Как говорится - ситуация патовая, в чем может быть дело? 

Причина, по которой вы лишились своих профилей может быть в TLS-фингерпринтинге. Это не какая то скрытая технология цивилизации древних Атцеков, а вполне себе современная методика, которая работает глубже уровня IP-адреса и позволяет идентифицировать устройства и сессии по характерному отпечатку TLS-соединения.

Другими словами, если у всех ваших запросов будет одинаковый TLS-отпечаток, даже самые качественные прокси не спасут от блокировки на платформах, которые умеют работать с этими отпечатками. 

Что такое TLS-фингерпринтинг и как он работает

TLS (Transport Layer Security) - это криптографический протокол, обеспечивающий защищенное HTTPS-соединение между клиентом и сервером. И тут нас интересует самый первый обмен данными - TLS-рукопожатие. Во время этого виртуального обмена клиент отправляет сообщение ClientHello с набором параметров для согласования шифрования. Вот эти то параметры во многом и могут спалить, серверу кто к нему подключается.

Именно набор данных, которые содержаться в ClientHello и формирует уникальный TLS-отпечаток, один из цифровых идентификаторов клиента.

На скриншоте ниже я привел пример такого отпечатка - это скриншот реального TLS-рукопожатия, которое я перехватил Wiresharkом на своем локальном устройстве.

Проблема (а для кого-то это реально станет проблемой) в том, что каждый браузер, библиотека или ОС реализуют TLS по-своему, поэтому то набор параметров и получается уникальным.

Отпечаток TLS всегда будет постоянным для конкретного клиента независимо от его IP-адреса или используемого прокси. Он может незначительно измениться, если изменится набор шрифтов или расширений, но в большинстве случаев будет идентичен.

Из чего формируется TLS-отпечаток:

• Версия TLS. Стандартный Chrome поддерживает TLS версии 1.3, а у Python библиотеки requests будет версия 1.2 или тоже 1.3, как у Хрома и т.д.

• Набор шифров (Cipher Suites). Это не те шрифты, которыми вы пишите, нет - тут речь про шрифты для шифрования, если хотите алгоритмы шифрования. У каждого браузера они плюс минус похожи, но отличия будут - у Firefox примерно 15 шифров, а у Chrome около 17, скрипты (python requests, curl) имеют еще более короткий список, характерный для библиотеки OpenSSL, но при этом сами алгоритмы шифрования могут отличаться.

• Список расширений TLS. Сюда относят дополнительные опции протокола (SNI, ALPN, OCSP и др.), которые решают различные прикладные задачи. Набор и количество расширений также зависит от браузера, у каждого из них цифра будет своя - это и формирует разницу.

• Поддерживаемые группы (кривые). Это уже вообще "математический язык", на котором строится защита. У каждого браузера свой уникальный список методов.

• Алгоритмы подписи. Предпочтительные алгоритмы для цифровой подписи в рамках TLS (различаются по приоритетам между клиентами). Это такой список стандартов, которые ваш браузер в состоянии проверить. У Chrome это проверка по одним алгоритмам, у Safari по другим, суть вы думаю уловили.

Тут еще важно понимать нюанс - сам набор может быть примерно одинаковым, а вот порядок их передачи разным. Если два разных клиента будут поддерживать один и тот же список шифров или расширений, но отправят их в разной последовательности - мы получим разные отпечатки. Вот такая тонкость - любая, казалось бы, мелочь - а итог разный.

Интересная аналогия с приготовлением пищи - если вы сначала положите в сковороду чеснок, и только перед подачей блюда опустите в нее мясо, на 5-10 минут - у него будет совершенно другой вкус, чем у блюда приготовленного по классическому рецепту - сначала мясо, а перед подачей за 5 минут чеснок. Так и тут - порядок передачи имеет серьезное значение!

JA3 - при чем тут третья часть популярной в 00-х игры на ПК?

Кто такой же древний мамонт как и я, и помнит игру про наемников Jagged Aliance, вероятно подумал - дед опять забыл таблетки принять, но нет - я все правильно пишу - речь не про гейминг, а все так же про TLS-отпечатки, а вернее про технику их передачи.

JA3 - это хэш, длиной 32 символа, который вычисляется по совокупности перечисленных выше параметров. Его удобно хранить и сверять. И вот этот хеш и будет нашим отпечатком.

Каждая уникальная комбинация параметров даст свой JA3-хэш, и даже минимальное отличие сформирует разные хеши - Chrome 120 на Windows 11 и на Firefox 121 на одном и том же устройстве даст разные JA3-отпечатки.

Узнать свой JA3 хэш можно с использованием специальных сервисов (tls.peet.ws или через встроенный функционал Wireshark).

Справка: Wireshark - это программное обеспечение для анализа сетевого трафика (сниффер), с помощью которого вы можете увидеть в реальном времени данные, проходящие через ваш компьютер. Предупреждаю, стоит только начать и остановиться потом будет сложно.

Резюмируем: TLS-фингерпринтинг позволяет достатоверно отделить одного клиента от другого, анализируя только лишь сетевые параметры шифрованного соединения. Ни смена IP, ни подмена User-Agent здесь не помогут - "почерк" вашего TLS-рукопожатия останется прежним.

Почему прокси не скрывают TLS-отпечаток

Использование прокси-сервера по-дефолту рассматривается как способ скрыть или подменить свою личность в сети. И отчасти это так и работает. Если вы будете использовать прокси чтобы замаскировать IP-адрес одного конкретного юзера на конкретном устройстве - все получится, прокси скроет реальный IP-адрес.

Не хочется душнить по поводу предыдущего абзаца - но соблазн велик. Смена IP-адреса не скрывает вас со 100% уверенностью, при желании сервис может вытащить ваш реальный IP-шник, есть несколько способов и все они известны. Так что без дополнительной защиты просто использование прокси - это иллюзия маскировки, не более того.

С мультиаккаунтингом это так не работает. Прокси работает на сетевом уровне, и его возможности ограничены передачей трафика через другой IP. 

При HTTPS-соединении TLS-рукопожатие происходит напрямую между вашим устройством и целевым сервером, а прокси лишь пересылает уже зашифрованные данные, не вмешиваясь в их содержимое.

Прокси меняет для запроса лишь некоторые внешние атрибуты:

• IP-адрес, который видит сайт (маскируя ваш реальный адрес);

• Геолокацию (зависит от IP прокси);

• Маршрут трафика в сети (пропускает через себя);

• В некоторых случаях позволяет обойти региональные блокировки контента.

Однако прокси не способен изменить такие вещи, как:

• TLS-отпечаток вашего браузера или скрипта;

• Отпечатки браузера: Canvas, WebGL, аудио, шрифты и пр.;

• HTTP-заголовки и характеристики самого клиента (если вы их вручную не меняли);

• Другие аппаратно-программные признаки (разрешение экрана, часовой пояс, плагины и т.д.).

Отсюда следует простой вывод: даже самый надежный прокси, не делает ваш запрос невидимым для систем фингерпринтинга. Если вы запускаете несколько сессий через разные прокси, но одним и тем же клиентом (который просто позволяет менять ip-адреса, не трогая ничего из вышеперечисленного), то для целевого сайта все эти сессии выглядят как исходящие с одного и того же устройства.

Типичная ошибка новичков - покупать дорогие резидентные прокси в надежде, что смена IP решит проблему анонимности или мультиаккаунтинга. Дороже - не значит сильнее защищенные. Дорогие прокси это не про полную защищенность, а про качество полученных IP-адресов. Дорогие прокси с большей степенью вероятности не будут висеть в черных списках и не будут иметь какую-то серую историю использования (хотя и это не факт, но шанс получить мертвый пул меньше, и вот это уже факт).

Если вы не меняете TLS-отпечаток (и не только его, так как TLS-отпечаток - лишь одна из составляющих браузерного фингерпринта), то хоть по 5$, хоть по 10$ вы купили прокси для каждого аккаунта, результат будет предсказуем - бан ваших профилей или усложнение работы (частая капча, ошибки и т.п.).

Вот вам и ответ - почему вас банят даже с чистых прокси - IP-адрес новый, а цифровой след остался прежним.

Тем не менее, сами по себе прокси остаются важным инструментом - они решают задачу разделения и маскировки IP-адресов. Но для полноценной анонимности их необходимо сочетать с другими мерами антидетекта.

Как платформы используют TLS-фингерпринтинг для блокировок

Технологию TLS-фингерпринтинга уже давно используют практически все крупные платформы, борющиеся с ботами, мошенничеством и мультиаккаунтингом. Более того, даже многие средние по размеру сервисы подключают готовые решения для снятия отпечатков устройства. Можно сказать так - если веб-платформа серьезно относится к безопасности, велика вероятность, что при каждом вашем HTTPS-запросе она пассивно собирает TLS-отпечаток клиента и сверяет его с известными шаблонами.

Теперь к персоналиям:

Cloudflare и аналогичные антибот-сервисы. Cloudflare, защищая сайты от ботов, активно анализирует TLS-рукопожатия. Если JA3-хэш вашего запроса не совпадает с шаблоном ни одного распространенного браузера, запрос помечается как подозрительный. Например, вызовы из Python-скрипта с библиотекой requests имеют совсем иной TLS-почерк, чем у Chrome/Firefox, и Cloudflare их либо блокирует, либо выдает капчу или вызывает специальную страницу с JS-челленджем (Turnstile). Таким образом, если dfi клиент выдает себя на этапе TLS, защита среагирует независимо от IP.

Социальные сети и рекламные кабинеты (Meta, TikTok, и т.д.). Facebook и Instagram применяют очень строгий фингерпринт-контроль. Их системы связывают между собой аккаунты с одинаковыми TLS-отпечатками, даже если те никогда не входили с одного IP-адреса. В результате блокировка одного профиля может автоматически затронуть все связанные аккаунты.

Meta помимо TLS учитывает десятки других признаков (Canvas, WebGL, фоновые сенсоры и пр.) для построения многомерного портрета пользователя.

TikTok также агрессивно отслеживает мультиаккаунты - помимо TLS-отпечатка, они смотрят на поведение (одновременный вход, схожие действия), но одного только общего TLS-профиля уже будет достаточно, чтобы связать ваши учетные записи между собой.

Маркетплейсы и e-commerce (Wildberries, Ozon, Amazon и др.). Крупные торговые платформы применяют TLS-фингерпринтинг не только против мультиаккаунтов селлеров, но и для защиты от массированного парсинга данных.

Wildberries и Ozon борются с автоматическим сбором цен конкурентов, отслеживая однотипные TLS-отпечатки на множестве запросов. Если вы запустите парсер с несколькими прокси, но он везде будете использовать одну и ту же библиотеку HTTP (а значит и один отпечаток) - маркетплейс довольно быстро это вычислит. В течение нескольких часов IP-адреса ваших прокси попадут на карандаш или вообще улетят в бан, поскольку система увидит сотни запросов с идентичным TLS-почерком и заблокирует весь диапазон IP-адресов как вредоносный.

Рекламные системы (Google Ads и др.). Google Ads проверяет TLS-отпечаток при создании новых рекламных аккаунтов и при подозрительной активности. Если вы пытаетесь завести, несколько кабинетов с разных IP-адресов, но на одном и том же устройстве, то все они будут помечены и отправлены на ручную модерацию (или просто превентивно заблокированы).

Другие площадки (Amazon/eBay, LinkedIn, Twitter/X, Авито) также в той или иной степени учитывают TLS-фингерпринт при автоматическом поиске аномалий.

Сейчас внимательно! Я старался уточнять, но если у кого-то сформировалось впечатление, что при использовании одного устройства и нескольких прокси, вас выдаст именно TLS-отпечаток - это далеко не так. TLS всего лишь один из методов, который используется антибот-системами для определения аномальной активности. Антифрод-системы работают по методу скоринга (начисления штрафных баллов), и TLS-отпечаток просто один из кирпичиков в общем каркасе.

Способы обхода TLS-фингерпринтинга

Если TLS-отпечаток может нас выдать, логичный подход для обхода - изменить или замаскировать его. В идеале наш клиент должен выглядеть как самый обыкновенный браузер реального пользователя, или каждый поток автоматизированных запросов должен иметь разные TLS-профили, чтобы их нельзя было связать друг с другом. Логично? Конечно логично, но как этого добиться?

Вот какие способы для борьбы с TLS-фингерпринтингом используют:

• Использовать настоящий браузер через автоматизацию. Самый простой способ сгенерировать правдоподобный TLS-пакет - это реально открыть браузер (Chrome, Firefox и т.п.), который сам осуществит обмен данными с сервером. Инструменты типа Selenium, Puppeteer, Playwright в связке с браузером Chromium/Firefox дают аутентичный TLS-отпечаток штатного браузера. Даже в headless-режиме современные браузеры обмениваются с сервером теми же ClientHello, что и в обычном, поэтому по одному TLS-отпечатку их не отличить от обычного пользователя. Однако запуск браузера через средства автоматизации может оставлять другие следы, но это уже тема другой статьи.

• Использовать антидетект-браузеры. Антидетект-браузеры - это одно из самых надежных решений. По сути, антидетект-браузеры - это модифицированные Chromium или Firefox, которые для каждого профиля генерируют уникальный набор фингерпринтов: от Canvas и WebGL до TLS. Они могут при старте нового профиля выдавать ему случайный, но реалистичный TLS-отпечаток, взятый из базы реальных устройств. Или же сгенерировать параметры на лету, рандомизируя их под правдоподобные комбинации. Плюс в некоторых случаях можно настроить эти параметры вручную, но подмена TLS-отпечатка это уже более тонкая настройка, и выполнять ее не профессионалам не рекомендуется. Отпечаток должен выглядеть достоверно. Если задать несуществующую в природе комбинацию TLS-параметров, умные системы это тоже распознают как подделку. Качественные антидетекты избегают таких ошибок, предоставляя профили неотличимые от обычных пользователей.

  Антидетект-браузер в связке с уникальным прокси на каждый аккаунт - стандартное решение для безопасного мультиаккаунтинга. В контексте веб-парсинга антидетект-браузер менее удобен (сложнее масштабировать на сотни потоков), как правило их используют точечно, для прохождения сложной капчи.

• Имитация TLS-пакета программными методами. Профессионалы могут настраивать низкоуровневые параметры TLS-соединения вручную. Есть библиотеки и патчи для HTTP-клиентов, которые позволяют задать свой порядок шифров, расширений и т.д., тем самым эмулировать TLS-рукопожатие нужного браузера.

• Ротация TLS-отпечатков. Если эмулировать браузерный профиль сложно, можно попробовать альтернативный подход - частую смену TLS-отпечатка, чтобы каждый поток запросов выглядел по-разному. Некоторые прокси провайдеры или сервисы парсинга предлагают функцию динамической подмены TLS-профиля. По сути, ваш запрос проходит через специальный сервер, который рандомизирует параметры TLS перед соединением с нужным сайтом. Однако важно, чтобы подменяемые отпечатки тоже соответствовали реальным устройствам, иначе вместо одного подозрительного профиля вы можете создать несколько подозрительных.

Каждый из методов имеет свои плюсы и минусы по сложности реализации и эффективности. Лучше всего комбинировать несколько подходов.

Для массового парсинга данных использовать ротацию прокси + утилиты для спуффинга TLS, а для управления учетными записями - антидетект-браузеры + выделенные прокси для каждого профиля.

Общий же принцип один - недостаточно скрыть свой IP, нужно еще и убедить сервер, что вы обычный пользователь. 

Заключение

Эпоха, когда смены IP-адреса было достаточно для анонимности или обхода банов, осталась позади. TLS-фингерпринтинг доказал свою эффективность в распознавании ботов и связывании учетных записей, поэтому крупные интернет-платформы внедрили его повсеместно. Если вас необъяснимо блокируют даже при использовании чистых резидентных прокси, очень вероятно, что дело именно в TLS-отпечатке вашего клиента. А значит важно следить не только за чистотой прокси, но и за тем, какой след оставляет ваш софт.