Определение посещённого сайта по TLS-записям: что заявляет препринт CipherSight
14 августа 2026 года в открытом архиве препринтов появилась работа CipherSight — про распознавание посещённых сайтов по зашифрованному HTTPS-трафику. Задача не новая, ей больше десяти лет: наблюдатель не расшифровывает соединение, а смотрит на его внешние признаки — размеры, порядок и тайминги — и пытается назвать сайт. Новизна конкретной работы в том, откуда берутся признаки: не из последовательности TCP-пакетов, как почти во всех предыдущих методах, а из записей протокола TLS.
Что заявлено
Работа подана 14 августа 2026 года девятью авторами (первый — Runhan Song), отнесена к разделам по безопасности, искусственному интеллекту и сетевым технологиям. Заявленные результаты в аннотации приведены три: 95,41% верных ответов в так называемом закрытом сценарии на выборке более чем из 2000 сайтов; свыше 90% точности при временном дрейфе, то есть когда модель обучали в одно время, а проверяли заметно позже; столько же при географическом дрейфе, когда наблюдение ведётся из другой страны.
Устойчивость к дрейфу здесь важнее самой цифры точности. Методы распознавания сайтов давно показывают высокие результаты в лабораторных условиях и резко теряют качество, когда меняются страна, провайдер или просто проходит время — сайты обновляют вёрстку, меняют CDN, и признаки уплывают. Заявка авторов состоит именно в том, что переход от TCP-пакетов к TLS-записям делает признаки устойчивее, потому что запись — это единица прикладного уровня, и она меньше зависит от того, как транспорт нарезал поток.
Как это устроено и почему это ещё не факт
Архитектура, по описанию авторов, двухуровневая: сначала модель учитывает зависимости между TLS-записями внутри одного потока, затем — взаимодействие нескольких одновременных потоков, из которых обычно и состоит загрузка страницы. Дополнительно применяется приём с маскированием части записей при обучении и разметка «запись — ресурс» в качестве вспомогательного сигнала; при работе на реальном трафике такая разметка уже не требуется.
Теперь оговорки, без которых читать эту новость нельзя. Это препринт: он не проходил рецензирования и не воспроизводился независимыми группами. Все числа — из собственных экспериментов авторов на собственных данных, и относиться к ним нужно как к заявке, а не как к установленному факту. Отдельно отметим: мы приводим только те цифры, что есть в аннотации самой работы, и не пересказываем сравнения с другими методами по вторичным источникам.
Что это значит для того, кто пользуется туннелем
Ключевая деталь, которую легко потерять при пересказе: работа посвящена HTTPS-трафику, а не трафику внутри VPN-туннеля. Метод предполагает, что наблюдатель видит сами TLS-записи соединения с сайтом. Именно в таком положении находится оператор связи или владелец сети, через которую пользователь ходит напрямую.
Отсюда корректный вывод — и он скромнее, чем хотелось бы: туннель не отменяет наблюдение, он переносит точку наблюдения. Тот, кто стоит до туннеля, видит поток к одному адресу вместо записей к конкретному сайту. Тот, кто стоит после — оператор выходного узла и дальше по маршруту, — видит ровно то же, что видел бы провайдер без туннеля. Это не рекламный тезис, а описание того, как устроен маршрут, и оно одинаково верно для любого поставщика, включая нас.
Практического действия из этой новости не следует вовсе, и придумывать его мы не будем: работа описывает метод анализа, а не инцидент. Полезна она другим — как напоминание, что шифрование скрывает содержимое, но не форму трафика, и что усилия по маскировке этой формы (переменные размеры пакетов, изменение таймингов) в протоколах обхода появляются не на пустом месте.