Как провайдеры вставляют «perma‑cookies», почему это опасно и как защититься

TL;DR

Verizon и другие провайдеры обнаружены вставляющими в HTTP‑заголовки уникальные идентификаторы пользователя («perma‑cookies»), которые позволяют отслеживать поведение в сети даже при удалении обычных cookie. Такое вмешательство происходит на сетевом уровне и обходится стандартными средствами браузера. Защититься можно надёжнее всего при помощи VPN или сквозного шифрования (HTTPS, STARTTLS), а также дополнительных настроек и практик защиты приватности.

Важно: если вы пользуетесь мобильным интернетом и посещаете сайты по незашифрованному HTTP, провайдер может добавлять идентификаторы в запросы — это серьёзная угроза приватности.

Что произошло — кратко и по делу

Вкратце: у Verizon был обнаружен механизм, который модифицирует HTTP‑трафик абонентов, добавляя в заголовки поле (X‑UIDH) с постоянным идентификатором пользователя. Это не cookie в привычном понимании, а «перманентный» идентификатор, который передаётся каждому посещённому незашифрованному сайту и позволяет отслеживать перемещения пользователя по сети. У пользователя нет простой опции «отключить» эту функцию, удаление cookie в браузере не помогает.

Как это работает технически

HTTP — это протокол запросов и ответов. Каждый HTTP‑запрос содержит заголовки (HTTP headers) — структурированные пары «ключ: значение», которые передают метаданные о запросе (тип браузера, язык, реферер и т. п.). Провайдер, контролирующий сетевой шлюз, может читать и модифицировать эти заголовки.

В случае Verizon в HTTP‑заголовки вставлялось поле с именем X‑UIDH и значением, уникальным для абонента. Любой сервер, получивший такой заголовок, мог зафиксировать идентификатор и связывать посещения разных сайтов с одним пользователем.

Здесь ключевой момент: модификация происходит на сетевом уровне в инфраструктуре провайдера, а не на устройстве. Это значит, что стандартные меры вроде удаления cookie, использования приватного окна браузера или смены браузера не решают проблему, если трафик не защищён шифрованием.

STARTTLS и перехват почты

Похожая практика наблюдалась и в отношении почтового трафика. Когда почтовый клиент подключается к серверу по протоколу SMTP/IMAP, он может инициировать шифрование с помощью команды STARTTLS. Некоторые провайдеры, по заявлениям исследователей и организаций, удаляли или запрещали передачу флага STARTTLS, в результате чего соединение шифровалось не было. Тогда логин и содержимое писем передавались в открытом виде и могли быть перехвачены.

Почему это опасно

• Отслеживание поведения: уникальный идентификатор позволяет строить профиль посещённых сайтов, интересов и последовательностей действий.
• Сопряжение данных: если OP/третья сторона свяжет X‑UIDH с аккаунтом (например, через вход на сайт), профиль можно персонализировать по имени, адресу и т. п.
• Уязвимость при утечках: идентификаторы, передаваемые в открытом виде, попадают в логи и могут быть использованы злоумышленниками.
• Обход пользовательского контроля: пользователь не может удалить сетевой идентификатор средствами браузера.

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

Это касается только Verizon? Нет — проблема шире

Verizon — лишь один публично освещённый пример. Другие провайдеры в США и за рубежом также обвинялись в модификации трафика: удаление флагов шифрования электронной почты, вставка рекламных заголовков, внедрение прокси с подменой содержимого. В некоторых странах крупные провайдеры и вовсе перехватывали соединения между пользователями и почтовыми сервисами.

Как узнать, уязвимы ли вы

• Проверить наличие X‑UIDH в исходящих HTTP‑запросах можно инструментами вроде эмуляторов трафика или сетевых снифферов (только в рамках личной диагностики).
• Сайты-тесты: в прошлом существовали ресурсы вроде lessonslearned.org/sniff и amibeingtracked.com, которые показывали, присутствует ли в ваших запросах сторонний идентификатор. Некоторые из таких ресурсов могли перестать существовать.
• Практический тест: подключитесь к мобильному интернету без VPN и откройте сайт, который показывает заголовки запроса — если в списке есть подозрительные поля с постоянными значениями, это тревожный сигнал.

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

Надёжная защита — VPN и сквозное шифрование

Самый простой и надёжный способ защиты от вмешательства провайдера — обеспечить шифрование всего трафика между вашим устройством и доверенным узлом вне сети провайдера.

• VPN (Virtual Private Network) создаёт зашифрованный туннель между устройством и сервером провайдера VPN. Провайдер мобильной сети видит только подключение к VPN‑серверу, но не торренты заголовков или содержимое запросов.
• HTTPS (сквозное шифрование для веба) защищает каждый запрос к сайту; если сайт использует HTTPS, провайдер не видит содержимое заголовков и тела запроса (но может видеть домен через SNI, если не используется ESNI/EnS). Полноценная защита достигается сочетанием HTTPS + VPN.
• STARTTLS/SMTPS/IMAPS — для почты: используйте клиенты и серверы, которые поддерживают и требуют шифрование; при подозрении на вмешательство применяйте VPN.

В оригинальном материале рекомендовали SurfEasy как вариант VPN. Это один из коммерческих сервисов с бесплатной квотой и платными тарифами. Стоимость годового тарифа в оригинальном объявлении была $49.99. Скидочные акции и условия меняются — ориентируйтесь на актуальную информацию от поставщика.

Примечание: выбор VPN зависит от доверия к провайдеру VPN. Даже при использовании VPN вы переносите доверие с мобильного оператора на поставщика VPN.

Альтернативные и дополнительные меры защиты

• Включите в браузере и клиентах почты требование шифрования (например, настройка «только HTTPS» или расширения, блокирующие загрузку по HTTP).
• Используйте DNS через DoH/DoT (DNS over HTTPS / DNS over TLS), чтобы провайдер не видел, какие домены вы запрашиваете.
• Для почты используйте современные протоколы с обязательным шифрованием и двухфакторную аутентификацию.
• Применяйте блокировщики трекеров и скриптов в браузере (uBlock Origin, Privacy Badger и т. п.). Они не помешают вставке заголовков, но снизят профильную сборку в доменах, где работает JavaScript‑трекер.
• Обновляйте ПО: современный браузер и клиент почты лучше умеют обнаруживать и защищать от смешанных (mixed) соединений.

Практический чеклист для обычного пользователя

1. Подключайтесь к мобильной сети и проверьте: используете ли вы VPN? Если нет — подумайте о подключении.
2. Всегда предпочитайте сайты c HTTPS (замок в адресной строке).
3. В почтовом клиенте включите шифрование/безопасные порты и двухфакторную аутентификацию.
4. Установите проверенное расширение блокировки трекеров в браузер.
5. Регулярно проверяйте настройки приватности в телефоне и у мобильного оператора.

Чеклист для администратора сервисов/разработчика

• Логируйте не больше необходимого и не храните идентификаторы третьих сторон в открытом виде.
• Требуйте HTTPS и HSTS для всех сайтов.
• Приём почты: используйте принудительное TLS и MTA‑STS/STARTTLS‑политику.
• Мониторьте сеть на предмет неожиданных заголовков и полей в приходящих запросах.

Мини‑методология проверки (короткая инструкция для техничного пользователя)

1. Подключитесь к мобильной сети без VPN.
2. Откройте инструмент, который показывает исходящие заголовки (локальный прокси, расширение для разработчика в браузере не отражает сетевые изменения провайдера — нужен сниффер или внешний echo‑сервис).
3. Сравните запросы при подключении через мобильную сеть и при подключении через VPN.
4. Если при обычном подключении вы видите дополнительные поля (например, X‑UIDH), а при VPN они исчезают — это очевидный признак вмешательства провайдера.

Решения для разных ролей (коротко)

• Обычный пользователь: включить VPN, пользоваться HTTPS, блокировщиками трекеров.
• IT‑специалист в компании: требовать защищённого доступа по VPN для удалённых сотрудников, проверять сторонние заголовки в логах.
• Разработчик сервиса: не полагаться на заголовки со стороны клиента, валидировать и игнорировать подозрительные поля.

GDPR и правовая сторона (заметка для Европы)

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

Важно: конкретные правовые выводы зависят от законодательства и должны подтверждаться юридической консультацией.

Когда VPN может не помочь — варианты, когда схема не сработает

• Если уязвимость реализована на стороне конечного сервера или в браузере (например, вредоносные расширения), VPN проблему не решит.
• Если провайдер использует технику «man‑in‑the‑middle» с собственным сертификатом и пользователь добровольно или по умолчанию установил доверие к такому сертификату на устройстве, VPN/HTTPS перестанут быть эффективны.
• Если устройство скомпрометировано (malware), никакие сетевые меры не защитят данные на уровне приложения.

Пример политики реагирования для команды поддержки (короткий план действий)

1. При обнаружении жалоб от пользователей: воспроизведите сценарий с контролируемыми тестами.
2. Соберите телеметрию (лог заголовков, временные метки, IP‑подключения).
3. Уведомите руководство и, при необходимости, регулятора или организацию по защите данных.
4. Включите уведомления для пользователей и предложите временные обходные меры (VPN, изменение портов).

Визуальное руководство — простое дерево решений

flowchart TD
  A[Вижу подозрительный идентификатор в заголовках?] -->|Да| B{Подключены ли вы через VPN}
  A -->|Нет| Z[Вероятно, вмешательство отсутствует]
  B -->|Да| C[Проблема, вероятно, у сервиса/устройства]
  B -->|Нет| D[Включите VPN и повторите тест]
  D -->|Исчезло| E[Вмешательство провайдера подтверждено]
  D -->|Осталось| C
  C --> F[Проверить расширения, сертификаты, устройство]
  E --> G[Использовать VPN, уведомить провайдера, обратиться в регулятор]

Краткое резюме и рекомендации

• Проблема: провайдеры могут вставлять постоянные идентификаторы в HTTP‑заголовки и вмешиваться в почтовые протоколы.
• Наиболее защищённая позиция: использовать VPN и сквозное шифрование (HTTPS, зашифрованная почта).
• Дополнительно: включите DNS over HTTPS/TLS, блокируйте трекеры и проверяйте настройки клиента почты.
• Если вы в ЕС, проверьте возможные правовые шаги — вмешательство в трафик может нарушать правила о персональных данных.

Фото: Google mail homepage [Broken URL Removed], Verizon homepage [Broken URL Removed], Internet cookies, Email menu

Часто задаваемые вопросы

Что такое «perma‑cookie» и чем он отличается от обычного cookie?

«Perma‑cookie» в данном контексте — это не cookie браузера, а постоянный идентификатор, вставляемый провайдером в HTTP‑заголовок. В отличие от обычных cookie, он не хранится в браузере и не удаляется при очистке cookie.

Поможет ли только HTTPS защититься от вставки заголовков?

HTTPS защищает содержимое и заголовки запроса между браузером и сервером сайта, поэтому провайдер не сможет прочитать или модифицировать защищённые заголовки. Однако если сайт использует только HTTP, защита отсутствует.

Какие быстрые шаги предпринять прямо сейчас?

Включите проверенный VPN на мобильном устройстве, обновите браузер и почтовый клиент, используйте блокировщики трекеров и требуйте HTTPS на сайтах.

Photo Credits: Google mail homepage [Broken URL Removed], Verizon homepage [Broken URL Removed], Internet cookies, Email menu