Fake-TLS перестал спасать — разбираю, что технически означает «анализ сигнатур протокола», почему статистика трафика выдаёт прокси и где предел этой гонки

В конце мая 2026 рунет накрыло волной сообщений о массовых отказах MTProto-прокси. Сервисы, через которые пользователи обходили замедление Telegram, перестали работать почти у всех операторов одновременно. «Код Дурова» зафиксировал, по их формулировке, беспрецедентное количество жалоб. Технические каналы запестрели заголовками в духе «РКН прокачал блокировки, обойти невозможно».

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

Сразу обозначу жанр. Это разбор теории обнаружения протоколов — области на стыке сетевого анализа, статистики и DPI. Это не инструкция по обходу блокировок: конкретных рецептов «как сделать так, чтобы у вас работало» здесь не будет, для этого есть профильные ресурсы. Цель — понять, как технически устроена детекция, потому что это интересная инженерная задача сама по себе, и понимание механики полезно любому, кто работает с сетями.

Краткая вводная: что такое MTProto и Fake-TLS

Чтобы разговор был предметным, нужна база.

MTProto — собственный транспортный протокол Telegram. Он создавался не только для шифрования, но и для работы в условиях фильтрации трафика. Внутри Telegram есть встроенный механизм прокси — MTProxy, который работает прямо в клиенте, без дополнительного софта.

Ключевая фишка MTProxy последних лет — Fake-TLS (он же FakeTLS, padded TLS). Идея в том, чтобы замаскировать соединение под обычный HTTPS. Когда вы открываете любой сайт по HTTPS, между клиентом и сервером происходит TLS handshake — обмен сообщениями ClientHello, ServerHello, обмен ключами. Fake-TLS оборачивает MTProto-трафик так, чтобы начало соединения выглядело как легитимный TLS 1.3 handshake к какому-нибудь нормальному домену.

Для DPI, который смотрит только на начало соединения, это выглядело как обычный визит на сайт. Поэтому годами Fake-TLS MTProxy спокойно проходил через фильтры — система не могла отличить его от рядового веб-серфинга, не ломая попутно весь HTTPS.

Это работало. До определённого момента.

Этап 1: детекция по TLS handshake (что было раньше)

Первый уровень детекции, который применялся в начале 2026 года — анализ самого TLS handshake. И тут есть тонкость, которую важно понять.

Fake-TLS имитирует TLS, но имитирует не идеально. Реальный TLS-стек браузера (BoringSSL в Chrome, NSS в Firefox) формирует ClientHello с определённым набором полей в определённом порядке: список cipher suites, extensions, эллиптические кривые, форматы точек, ALPN, signature algorithms. Этот «отпечаток» получил название JA3 (и его развитие JA4) — хеш от параметров ClientHello, по которому можно идентифицировать клиентскую библиотеку.

У реализации Fake-TLS в MTProxy этот отпечаток отличается от настоящего браузера. Не сильно, но измеримо. Где-то другой порядок extensions, где-то отсутствует расширение, которое есть у настоящего Chrome, где-то набор cipher suites не совпадает с актуальной версией браузера.

DPI с базой JA3/JA4-отпечатков популярных браузеров может сравнивать: вот пришёл ClientHello, который заявляет себя как Chrome, но его JA3-хеш не совпадает ни с одной реальной версией Chrome. Подозрительно — помечаем.

Именно это произошло в марте-апреле 2026. ТСПУ получили обновлённые правила, которые ловили несоответствие TLS-отпечатка. Разработчики прокси отвечали подгонкой fingerprint под актуальные браузеры — классическая гонка щита и меча.

Но детектирование по handshake имеет фундаментальное ограничение: отпечаток можно подделать. Если знать, какой именно JA3 у свежего Chrome, можно сформировать ClientHello с точно таким же. Это вопрос инженерных усилий, не принципиальной возможности. Поэтому регулятор перешёл к следующему уровню — там, где подделка гораздо сложнее.

Этап 2: статистический анализ сигнатур протокола

Вот здесь начинается самое интересное с технической точки зрения. Новый виток, о котором писали в конце мая 2026 — анализ не handshake, а поведения трафика на всём протяжении соединения.

Ключевая идея: даже если начало соединения идеально замаскировано под TLS, дальнейший обмен данными подчиняется логике другого протокола — MTProto. А у каждого протокола есть статистические инварианты, которые сложно скрыть, не сломав сам протокол.

Что конкретно анализируется.

Размеры пакетов и их распределение

Реальный HTTPS-трафик при загрузке веб-страницы имеет характерный паттерн: большой всплеск в начале (HTML, CSS, JS, изображения летят крупными TLS-records близкими к MTU), потом затишье, потом мелкие запросы по мере взаимодействия. Распределение размеров пакетов веб-сессии — это «рваный» профиль с явными фазами.

MTProto в режиме мессенджера ведёт себя иначе. Это поток мелких сообщений — текст, статусы набора, пинги, подтверждения доставки. Распределение размеров пакетов другое: много мелких пакетов схожего размера, ровный поток без характерных веб-всплесков. Даже завёрнутый в TLS-обёртку, этот паттерн статистически отличается от реального просмотра сайтов.

DPI может строить гистограмму размеров пакетов в соединении и сравнивать её с эталонными профилями. Веб-сессия и MTProxy-сессия дают разные гистограммы.

Тайминги и направление трафика

Второй сигнал — временная структура. Веб-загрузка асимметрична: клиент отправляет маленький запрос, сервер отвечает большим объёмом данных. Соотношение upload/download для веб-серфинга сильно смещено в сторону download.

Мессенджер-трафик симметричнее: вы и отправляете, и принимаете сообщения сопоставимого размера. Плюс есть характерный «долгоживущий» паттерн — соединение держится открытым часами с периодическими keep-alive пингами через регулярные интервалы. Веб-соединения так себя не ведут — они короткоживущие, открылись-закрылись.

Регулярность пингов — отдельный сильный маркер. Если в «TLS-соединении» каждые N секунд проходит пакет фиксированного размера — это очень похоже на keep-alive мессенджера, а не на веб.

Энтропия и структура полезной нагрузки

Третий уровень — анализ энтропии зашифрованного потока. Тут тонко: и TLS, и MTProto шифруют данные, так что полезная нагрузка в обоих случаях выглядит как высокоэнтропийный «шум». Но есть нюансы в том, как структурированы TLS-records поверх шифрования: их длины, заголовки, паттерн фрагментации. MTProto поверх Fake-TLS формирует records не совсем так, как настоящий TLS-стек при передаче HTTP/2-трафика.

Поведенческая корреляция по IP

И, наконец, маркер, о котором прямо писали в новостях: корреляция подключений к одному IP. Логика такая. Публичный MTProxy обслуживает много пользователей. Все они подключаются к одному IP-адресу. Если Fake-TLS у всех них имитирует одну и ту же версию браузера (потому что прокси-сервер использует один и тот же fingerprint), то DPI видит странную картину: на один IP приходят десятки и сотни клиентов, и все с идентичным TLS-отпечатком одной и той же, часто устаревшей, версии браузера.

В реальном мире так не бывает. К одному сайту подключаются пользователи с разными браузерами, разными версиями, разными ОС — естественный разброс fingerprint. А когда сто клиентов приходят с побайтово одинаковым ClientHello «Chrome версии полугодовой давности» — это статистическая аномалия, которая прямо указывает на прокси.

Почему это работает, а подделать сложнее, чем handshake

Тут ключевой инженерный момент, ради которого я и затеял разбор.

Подделать статический отпечаток (JA3 handshake) — относительно просто: скопировал параметры настоящего браузера, сформировал такой же ClientHello. Один раз настроил — работает, пока браузер не обновится.

Подделать динамическую статистику протокола — принципиально сложнее. Потому что эта статистика порождается самой логикой работы MTProto. Чтобы профиль размеров пакетов и таймингов был неотличим от веба, нужно либо:

• генерировать фейковый «веб-подобный» трафик поверх реального — это огромный overhead, который убивает производительность и всё равно не идеален;

• переписать сам способ упаковки данных так, чтобы он статистически совпадал с настоящим HTTP/2 over TLS — это, по сути, и есть «переработать протокол», о чём писали в новостях. Именно поэтому фраза «избежать нельзя, Telegram должен переработать протоколы» в исходной новости — не совсем кликбейт. Доля правды в ней есть: косметической подгонкой fingerprint от статистической детекции не уйти, нужно менять то, как протокол формирует трафик на уровне паттернов.

Хотя «нельзя» — это преувеличение. Можно. Просто это требует более глубоких изменений, чем подмена одного хеша. И это снова гонка, просто на новом уровне.

Контекст: почему это часть большой гонки

Стоит понимать, что детекция MTProxy — лишь один фронт. С декабря 2025 по май 2026, судя по публикациям, DPI-системы научились распознавать по сигнатурам и другие протоколы обхода: WireGuard, OpenVPN, VLESS, SOCKS5, L2TP. Логика везде одинаковая — у каждого протокола есть статистический отпечаток, и при достаточных вычислительных мощностях его можно выделить.

Ответ со стороны обходных инструментов тоже идёт по понятному вектору — обфускация, которая не имеет стабильной сигнатуры. Протоколы вроде AmneziaWG (обфусцированный WireGuard) добавляют случайный шум в трафик, рандомизируют размеры пакетов и тайминги, чтобы у соединения не было устойчивого статистического профиля. Это прямой контр-приём против статистической детекции: если профиль каждый раз разный, эталон для сравнения построить сложно.

Это классическая динамика censorship-resistance: детекторы ищут инварианты, обходные инструменты их устраняют, детекторы ищут новые. Академически это хорошо описано в работах про обнаружение и обфускацию протоколов — например, исследования группы Tor про pluggable transports, работы про обнаружение Shadowsocks китайским GFW.

Ограничение со стороны железа

Есть ещё одна сторона, без которой картина неполна — стоимость детекции.

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

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

В апреле 2026 был показательный эпизод: при попытке нагрузить ТСПУ большим количеством правил фильтрации (по публикациям, около 40 тысяч против обычных 10-15 тысяч) система на части узлов ушла в bypass — то есть начала пропускать трафик без фильтрации, включая ранее заблокированные ресурсы. Это прямое следствие того, что глубокий анализ ресурсоёмкий, а суммарная пропускная способность оборудования конечна.

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

Что из исходной новости правда, а что преувеличение

Раз уж повод — конкретная новость, разберу её формулировки с технической точки зрения.

«DPI анализирует не только handshake, но и сигнатуры протокола — размер пакетов, fingerprint» — это технически корректно. Именно переход от анализа handshake к анализу поведенческой статистики и есть суть нового витка.

«Если к одному IP подключаются разные клиенты с одинаковой устаревшей версией браузера — это признак прокси» — корректно и логично. Это та самая поведенческая корреляция по IP, сильный и дешёвый в вычислении маркер.

«Избежать этого сейчас нельзя» — преувеличение. Точнее будет «нельзя избежать косметической подгонкой fingerprint». Статистическую детекцию обходят обфускацией с рандомизацией, и эти методы существуют (AmneziaWG как пример). Гонка продолжается, а не закончилась.

«Telegram должен полностью переработать протоколы» — частично правда. Чтобы Fake-TLS снова стал неотличим, нужно менять не отпечаток, а способ формирования трафика — это глубже, чем подмена хеша. Но «полностью переработать» — драматизация.

Типичная картина для технических новостей: основные факты верны, выводы драматизированы до уровня «всё пропало».

Что из этого полезно вынести

Несколько мыслей, выходящих за рамки конкретного кейса с Telegram.

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

Статический отпечаток подделать легко, динамическое поведение — трудно. Это общий принцип для любой детекции. Сигнатура, которую можно скопировать один раз — слабая защита. Поведенческие инварианты, порождаемые самой логикой системы — куда более устойчивый признак. Это применимо и в антифроде, и в обнаружении ботов, и в fingerprinting устройств.

Любая детекция упирается в стоимость. Чем глубже анализ, тем дороже он вычислительно. Это создаёт фундаментальный предел: систему можно перегрузить объёмом. Защита и нападение здесь — это всегда ещё и экономика вычислений, не только алгоритмы.

Обфускация против сигнатур — это про устранение инвариантов. Лучший способ не быть пойманным по статистике — не иметь стабильной статистики. Рандомизация размеров, таймингов, добавление шума. Это контр-приём, который работает против любого детектора, ищущего устойчивый паттерн.

Резюме

То, что произошло в мае 2026 с MTProxy — это переход детекции с уровня «как выглядит начало соединения» на уровень «как ведёт себя соединение во времени». Технически это закономерный шаг: анализ handshake обходится подделкой fingerprint, поэтому регулятор перешёл к статистическому анализу, который подделать сложнее.

Это не «конец Telegram» и не «обойти невозможно» — это новый виток давней гонки между детекцией и обфускацией протоколов. Статистическую детекцию, в свою очередь, обходят рандомизацией трафика, и инструменты для этого уже существуют. Параллельно вся система упирается в потолок вычислительных мощностей — глубокий анализ дорог, и это объективное ограничение.

С чисто инженерной точки зрения это красивая задача на стыке сетевого анализа, статистики и теории обнаружения. И понимание её механики полезно далеко за пределами темы блокировок — те же принципы работают в traffic analysis, антифроде, обнаружении ботов и анализе зашифрованных каналов.

Это технический разбор механики обнаружения протоколов, не политическое высказывание и не руководство по обходу блокировок. Если у вас есть корректировки по технической части — пишите в комментариях.

Источники и для дальнейшего чтения:

• Документация по JA3/JA4 fingerprinting (Salesforce, FoxIO)

• Исследования Tor Project про pluggable transports и обнаружение obfs4

• Работы про обнаружение Shadowsocks системой GFW (различные академические публикации по censorship measurement)

• Спецификация MTProto в открытой документации Telegram