Отпечатки JA3+HTTP2+TCP, какие и за что отвечают?

Zloy

Всем привет. Пожалуй начну с начала. Для того что бы лучше понимать как работает любой Антифрод - нужно с начала ответить на первоочередные вопросы. Как вообще работает интернет? Что именно происходит когда вы в браузере запрашиваете какую либо страничку? Как именно происходит прохождение трафика по сети? В этом материале я хочу развеять все предрассудки - о том как именно работает сеть, и объяснить какая часть вашей системы за какой отпечаток отвечает (напомню у нас их три JA3+HTTP2+TCP).

Почему отпечатка именно три? Вообще весь трафик который гуляет по глобальной сети - подчиняется стандартной модели OSI - она выглядит вот так:

Из этой картинки понятно - что трафик который вы отправляете (что бы получить страницу) - он состоит из нескольких уровней и у каждого уровня свои цели и задачи - это называется инкапсуляция (подробно про модель OSI можно почитать тут ). То есть когда вы отправляете какой то запрос - его можно разложить с начала на прикладной уровень - это и будет собственно запрос - потом на уровень представления, сеансовый уровень и так далее. В дальнейшем нас будут интересовать уровни: Прикладной, Сеансовый и Транспортный. (нас не будет интересовать уровни: Канальный и физический - так как они нужны для внутреннего взаимодействия сети - конечный хост их не будет учитывать).

Вот тут можно посмотреть какие протоколы на каком уровне работают:

Многие спрашивают меня: Может ли хост видеть MAC адрес моего роутера\системы итд? - Отвечаю: Нет это невозможно. Потому что мак находится на канальном уровне и только ваш роутер видит MAC ваш MAC адрес и маршрутизатор провайдера видит мак вашего роутера. Таким образом MAC адрес видят ТОЛЬКО СОСЕДНИЕ УСТРОЙСТВА. То есть это невозможно по технологии. Ну а если бы это было бы не так - то это была бы дырища глобального интернета с точки зрения безопасности.

Про то как именно могут идентифицировать ваше устройство различные сайты - мы сейчас и поговорим..

TCP отпечатки L4

Это самый первый отпечаток который в принципе можно собрать с каждого пользователя. Мы сделали специальный сервис с помощью которого можно смотреть отпечаток https://fingerprintcheck.work.gd/classify?detail=1 и так же есть сервис сторонний http://www.speedguide.net:8080/

Из чего вообще формируется отпечаток? Начнём с того как вообще выглядит TCP пакет?

Первое и самое важное из чего состоит TCP отпечаток это конечно TCP опции

iPhone OS 17_3_1 MSS:1348,NOP:,WindowScale:12,SACKPermitted:,Timestamps:364032648/0

iPhone OS 17_3_1 MSS:1380,SACKPermitted:,Timestamps:4281595168/0,NOP:,WindowScale:13

iPhone OS 17_4_1 MSS:1388,NOP:,WindowScale:6,NOP:,NOP:,Timestamps:3763022276/0,SACKPermitted:,EndList:

iPhone OS 16_6 MSS:1460,NOP:,WindowScale:8,NOP:,NOP:,SACKPermitted:

Windows MSS:1420,NOP:,WindowScale:8,NOP:,NOP:,SACKPermitted:

Видно что все они отличаются. (Больше примеров тут)

Абсолютно все антифрод системы смотрят на ваш MTU( MTU = MSS+40), это первый сигнал если человек использует ВПН - так как при использовании ВПН MTU становится меньше (по умолчанию он 1500), например https://ip-score.com/ - если вы зайдёте с ВПН и у вас будет маленький MTU например 1400 - то система будет говорить что вы используете ВПН - по этому нам важно изменять этот показатель на максимальный (Важно помнить что при использовании ВПН - MTU не может быть больше чем 1500-40=1460 - потому что эти 40 байт нужны для использовнания самого ВПН) Подробнее о детекте ВПН через эти параметры тут. В нашей прокcи вы можете заменить значение MSS(это такой же показатель только -40 байт который прописывается в TCP опциях) - а MTU уже посчитается сам.

WindowSize - это сколько неподтверждённых байт данных клиент может принять.

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

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

Подробно про это можно почитать тут общепризнанный отпечаток TCP: MSS+TCP Options+TTL+TOS+WindowScale. Его выдаёт непосредственно ОС (Windows\Linux\MacOS\Android\Iphone итд). Но - бывает такое что проходят через какие то шлюзы - например прокси ваш отпечаток может изменится, по этому важно убедится что этот отпечаток именно такой - который вы хотите использовать.

JA3 отпечатки (TLS - L6)

Что такое вообще эти отпечатки и откуда они берутся? Когда вы заходите на сайт httpS это значит что вы хотите использовать защищенный протокол то есть TLS (Transport Layer Security). По правилам протокола соединение должно выглядеть так:

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

В каждом TLS соединении клиент (то есть мы) - отправляет сообщение ClientHello выглядит оно примерно так

То есть наше сообщение ClientHello - содержит набор шифров и других расширений - которые есть в браузере. У каждого шифра и расширения есть свой код. Таким образом складывая эти коды получается вот такой отпечаток:

769,47–53–5–10–49161–49162–49171–49172–50–56–19–4,0–10–11,23–24–25,0

Потом это превращается в MD5 хеш и получается что то такое 160df3588996dbf66817cc71bba8a903

Примеры отпечатков выложил в отдельную таблицу: (Посмотреть Ja3 Отпечатки). В конце таблицы есть формула - она считает сколько уникальных значений есть в столбце (Unique prints) - таким образом вы можете понять где какие отпечатки уникальные. Так же есть один нюанс который есть только в браузерах CHROME это механизм GREASE - он внутри поля Extensions - перемешивает местами расширения - таким образом хеш отпечатка всегда разный получается (наша прокси умеет делать тоже самое). Но остальная часть отпечатка остаётся неизменной.

Больше про эти отпечатки можно узнать тут

HTTP2 отпечатки он же Akamai. L7

Отпечаток HTTP2 Это еще один метод идентификации пользователей, который работает на прикладном уровне - наряду с User-Agent, отпечатком JS, Canvas, WebGL итд.

Сам HTTP2 - это следующая версия привычного нам протокола HTTP/1.1

Пример http/1.1 запроса:

GET / HTTP/1.1
Host: www.wikipedia.org

sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="101", "Google Chrome";v="101"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/101.0.4951.67 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9

Сейчас уже практически все современные сайты поддерживают HTTP2 убедится в этом можно следующим образом (открыть консоль разработчика в браузере )

У этого протокола есть несколько преимуществ перед HTTP1 а именно:

Мультиплексирование - несколько запросов и ответов могут одновременно использовать одно TCP-соединение, что позволяет сократить время получения сайтов с большим количеством ресурсов (изображений, скриптов и т. д.).
Приоритизация - HTTP/2 поддерживает приоритезацию определенных запросов и ответов.
Server push - в HTTP/2 сервер может отправлять ресурсы клиенту до того, как клиент их запросит.

Не будем вдаваться в подробности. нам более важно как это может быть использовано для идентификации антифрод системой.

Http2 представляет из себя поток. А поток состоит из фреймов. Вот как раз эти фремы и можно использовать для идентификации.

SETTINGS: этот фрейм является первым фреймом, отправляемым клиентом, и содержит специфичные для HTTP/2 параметры. Он является частью потока 0, который является корневым потоком. Никакой ресурс не получается в потоке 0.
WINDOW_UPDATE: увеличивает размер окна получателя.
HEADERS: содержит фактический запрос от клиента к серверу. Он содержит URI, HTTP-метод и HTTP-заголовки клиента.

Каждый из этих фреймов содержит информацию, которая позволяет легко идентифицировать клиентов. Например, фрейм SETTINGS содержит параметры, которые контролируют такие настройки, как максимальное количество одновременных потоков, максимальное количество HTTP-заголовков, размер окна по умолчанию и поддержка серверного пуша. Каждый клиент HTTP/2 использует различные наборы параметров, и эти параметры обычно не изменяются в зависимости от того, какой именно HTTP-запрос отправляется.

Фрейм WINDOW_UPDATE увеличивает размер окна получателя. Этот фрейм может быть использован для идентификации клиента, поскольку каждый клиент может использовать различные размеры окна.

Фрейм HEADERS содержит фактический HTTP-запрос от клиента к серверу. Он содержит URI, HTTP-метод и HTTP-заголовки клиента. Этот фрейм также может быть использован для идентификации клиента, поскольку каждый клиент может использовать различные наборы заголовков и различные значения для этих заголовков.

Примеры отпечатков:

1:65536,2:0,4:6291456,6:262144|15663105|0|m,a,s,p 1:65536,3:1000,4:6291456,6:262144|15663105|0|m,a,s,p 2:0,4:2097152,3:100|10485760|0|m,s,p,a

4:2097152,3:100|10485760|0|m,s,p,a

Расшифровка отпечатков в таблице

Так же подробнее про эти отпечатки можно почитать тут

Заключение

Так получается складывая разные варианты этих отпечатков можно получать абсолютно разные варианты общего отпечатка - который конечно же будет видеть анфтирод система (Если мы можем собирать их с обычных пользователей - то что мешает АФ делать тоже самое??). Надеюсь мне удалось приоткрыть завесу тайны над этими отпечатками. Ну а подменить их(JA3+HTTP2+TCP) я могу вам помочь. Пишите в ЛС ;) @Siemons8