dxdt.ru: занимательный интернет-журнал

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

Дело в том, что начальное сообщение, отправляемое клиентом, – ClientHello, – содержит много параметров и, соответственно, имеет структуру, которой хватает для эффективного построения отпечатков. Например, весьма подробное представление о том, как такой классификатор действует, можно составить, если внимательно посмотреть на выдачу моего тестового сервера TLS 1.3. Посмотреть можно непосредственно веб-браузером. При успешном соединении сервер вернёт страницу, где в подробностях показано то самое CLientHello, которое сервер получил от клиента. Вы можете подключиться браузером, обновить страницу несколько раз и увидеть, какие блоки данных не изменяются и, поэтому, служат основой для построения сигнатур.

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

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

Эта же идея важна и для разбора самого сообщения ClientHello, где она позволяет анализировать структуру следующего уровня, так как ClientHello вложено в TLS-запись. А состоит идея в том, что значения байтов, кодирующих предполагаемую длину, интерпретируются как смещение; полученное значение прибавляется к текущему адресу (в предварительно собранном потоке байтов) и значения байтов по вычисленному адресу сравниваются с ожидаемыми значениями, которые там оказались бы, если это действительно анализируется ClientHello. И если TLS-записи тут не добавляют много нового (они просто следуют одна за одной), то в ClientHello появляются вложенные поля данных (расширения) и более богатая структура, которая, тем не менее, устроена точно так же: значения байтов, интерпретируемые как целое число, задающее длину, должны строго сходиться, когда рассматриваются в виде цепочки. Заметьте, что до разбора самих значений полей данных дело ещё даже не дошло. Это важная особенность TLS: данный протокол не обладает скрытностью. Скрытный протокол выглядел бы случайным набором байтов со случайными же значениями. TLS, – особенно, на начальном этапе соединения, – выглядит как связанная строгими параметрами длины и типов байтовая структура (так, впрочем, и должно быть).

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

Итак, вернёмся к ClientHello. Помимо верхнеуровневой структуры из вложенных блоков, есть и содержание этих блоков. Например, сообщение ClientHello, в самом начале, после указания версии, полей Random и SessionID, содержит перечень шифронаборов, которые поддерживает клиент. (Это всё хорошо видно в выдаче тестового сервера.) Сокращённый пример: 0x1301, 0x1303, 0x1302, 0xC02B, 0xC02F… На уровне потока данных это всё просто последовательные значения байтов, по два байта на каждый идентификатор шифронабора (понятно, что данному блоку предшествуют байты с записью длины, что добавляет “узнаваемости”).

Так, для конкретной версии браузера перечень шифронаборов – узнаваем. В принципе, ничто не мешает клиенту менять состав и порядок пар байтов, обозначающих шифронаборы, но, например, Firefox передаёт фиксированный набор. Понятно, что строгая последовательность из 36 байтов – это уже достаточный идентифицирующий признак. (36 байтов получается так: 17 идентификаторов шифронаборов от Firefox, по два байта каждый, плюс два байта на запись длины.) Чуть более подробный пример, начальная часть ClientHello TLS 1.3:

 Type (тип сообщения, 0x01, один байт - подходит для сигнатуры);
 Len (длина сообщения, три байта - подходит для сигнатуры: должно соответствовать общей структуре);
 Version (версия, 0x0303, два байта - подходит для сигнатуры);
 Random ([...], 32 "случайных" байта - не подходит для сигнатуры);
 SessionID_Len (длина данных Session_ID, один байт, для TLS 1.3 - подходит для сигнатуры);
 SessionID (обычно, для TLS 1.3 от браузера тут будет 32 байта - не подходит для сигнатуры).
 CS_Len (длина данных списка шифронаборов, два байта - подходит для сигнатуры);
 CS (список двухбайтовых идентификаторов шифронаборов - подходит для сигнатуры).
 [...]

При этом, скажем, браузер Chromium/Chrome добавляет к списку шифронаборов так называемые значения GREASE (для тестирования реализаций TLS), которые меняются от сеанса к сеансу. Но значения GRASE имеют строго определённый формат, так что их несложно распознать автоматом. Если взять такой клиент, как cURL, то состав ClientHello будет другим, в частности, другим будет список шифронаборов. Более того, по составу ClientHello нередко можно определить даже используемую библиотеку, реализующую TLS.

Естественно, не только шифронаборы подходят для построения сигнатуры. В ClientHello современных браузеров присутствует разнообразный набор расширений – это дописываемые в сообщение поля со своей структурой: они содержат заголовок с записью длины, дополнительные блоки внутри. Для TLS 1.3 расширения имеют определяющее значение. Внутри расширений передаются различные необходимые параметры, в частности, открытая часть протокола Диффи-Хеллмана и открытый ключ постквантовой криптосистемы X25519Kyber768. По составу и количеству расширений можно построить дополнительную сигнатуру. Так, уже наличие X25519Kyber768 едва ли не однозначно выдаёт современный веб-браузер. А ведь современный браузер ещё и укажет расширение ECH (Encrypted ClientHello). Firefox использует зафиксированный порядок расширений ClientHello, а браузер Chromium/Chrome – порядок следования расширений изменяет между сессиями. Однако даже в случае, когда порядок расширений разный, всё равно можно использовать перечень имеющихся расширений для построения сигнатуры.

Адрес записки: https://dxdt.ru/2024/08/13/13623/