Verizon внедряет перма‑cookie: как провайдеры вмешиваются в трафик и что с этим делать

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

О чём статья

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

Ключевые понятия в одном предложении

• Perma‑cookie: уникальный идентификатор, добавленный провайдером в сетевые запросы, не зависящий от браузерных cookie.
• HTTP‑заголовки: метаданные, отправляемые браузером или сервером вместе с запросом/ответом.
• STARTTLS: команда, используемая для перевода почтового соединения в зашифрованный режим.

Как Verizon внедрял perma‑cookie (технически)

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

Примечание: перма‑cookie не устанавливается на вашем устройстве как обычный браузерный cookie: его нельзя удалить, почистив cookie браузера, и частный режим браузера тоже не помогает. Изменение происходит на уровне сети провайдера, а не в приложении или ОС пользователя.

Почему это работает

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

Если соединение HTTPS, то заголовки шифруются в TLS‑сессии и провайдер не увидит содержимое запроса, поэтому перма‑cookie в чистом виде применимо только к незашифрованному HTTP.

Другие приёмы вмешательства: STARTTLS и почта

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

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

Это проблема только Verizon?

Нет. Описанные приёмы вмешательства встречались и у других провайдеров в разных странах: сообщения о модификации заголовков, удалении флагов шифрования и вмешательстве в TLS/STARTTLS поступали из США, Таиланда и других регионов. Степень и масштаб вмешательств зависят от политики провайдера, локального регулирования и доступных технических средств.

Как проверить, вмешивается ли провайдер в ваш трафик

Короткая методика проверки:

1. Откройте устройство на мобильной сети (не Wi‑Fi) и посетите несколько HTTP‑сайтов.
2. Запустите сетевой сниффер (tcpdump, Wireshark) на промежуточном устройстве или используйте сторонние инструменты для анализа заголовков запросов из браузера.
3. Ищите нестандартные заголовки (например, X‑UIDH или похожие).
4. Для почты — проверьте, посылает ли ваш сервер STARTTLS и действительно ли сервер отвечает переключением на TLS.

Короткие онлайн‑проверки, упомянутые в старых публикациях (например, amibeingtracked.com), могли помочь, но их актуальность и доступность меняется со временем.

Критерии приёмки: как убедиться, что провайдер не вмешивается

• На мобильной сети при обращении к простым HTTP‑страницам вы не видите дополнительных нестандартных заголовков.
• Почтовые соединения с серверами, которые поддерживают STARTTLS, действительно переходят в TLS (порт 587/993 или STARTTLS на 25) при просмотре логов.
• При использовании VPN все подозрительные заголовки и модификации исчезают (см. тест ниже).

Надёжная защита — VPN

Самый простой и эффективный способ предотвратить оба описанных вмешательства — шифровать весь трафик с устройства до доверенного сервера: использовать полноценный VPN. VPN создаёт зашифрованный туннель между вашим устройством и сервером VPN‑провайдера. Для провайдера мобильной сети весь трафик выглядит как единый TLS/UDP поток между абонентом и VPN‑сервером, и он не видит конкретных HTTP‑заголовков или STARTTLS‑команд внутри туннеля.

Плюсы VPN:

• Шифрование всего трафика независимо от приложения.
• Блокировка возможности вставки сетевых заголовков провайдером.
• Защита в общих и ненадёжных сетях Wi‑Fi.

Минусы и ограничения:

• Надёжность зависит от VPN‑провайдера — он видит ваш трафик на своей стороне.
• Нужно выбирать проверенные сервисы с прозрачной политикой логов и юрисдикцией, удобной для вас.

В материале исходного источника рекомендовали SurfEasy: бесплатный тариф даёт 500 МБ трафика на до пяти устройств, годовая подписка Total VPN — $49.99; в рекламной части упоминалась акция со скидкой 50% по коду MAKEUSE50 до 2 декабря. Важно помнить: выбор VPN — личное решение, и при необходимости следует читать пользовательское соглашение и политику конфиденциальности.

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

1. По возможности используйте HTTPS: переходите на сайты с https:// и устанавливайте расширения, принудительно включающие HTTPS (HTTPS Everywhere или встроенные функции современных браузеров).
2. Включайте строгие настройки почтовых клиентов: используйте SMTPS/IMAPS на стандартных портах (587, 993) и требуйте TLS; проверяйте сертификаты сервера.
3. Используйте защищённые DNS (DoT/DoH) — это не защитит от вставки заголовков в HTTP, но уменьшит утечки через DNS.
4. Ограничьте использование общих и неизвестных VPN‑провайдеров и публичных прокси; выбирайте сервисы с аудиторией и прозрачной политикой.
5. Для особо чувствительных задач используйте дополнительный уровень — отдельный доверенный сервер (bastion) или собственный VPS с VPN/SSH‑туннелем.

Практическая методика тестирования (мини‑методология)

1. Запустите тест на двух конфигурациях: мобильная сеть без VPN и с VPN.
2. Выполните запросы на контролируемый HTTP‑сервер (можно использовать собственный сервер для логов) и сохраните заголовки.
3. Сравните заголовки: наличия нестандартных полей в первом случае и их отсутствие во втором — признак вмешательства.
4. Для почты — включите подробные логи SMTP/IMAP и проверьте ответ сервера на STARTTLS.

Когда VPN может не помочь (примеры неудач)

• Если провайдер осуществляет активный MITM (man‑in‑the‑middle) и подсовывает клиенту поддельные сертификаты, пользователь может быть обманут. Однако это требует компрометации доверенной цепочки PKI и обычно заметно предупреждениями в браузере.
• Если вы устанавливаете непроверенное приложение, которое само передаёт данные в незашифрованном виде — VPN не спасёт от утечек данных внутри устройства.
• Если VPN‑провайдер ведёт логи и сотрудничает с третьими сторонами или властями — конфиденциальность зависит от его политики и юрисдикции.

Ролевые чек‑листы

Пользователь (быстрая проверка):

• Включён VPN при работе в мобильной сети?
• Сайты открываются по HTTPS по умолчанию?
• Почтовый клиент настроен на шифрование (IMAPS/SMTPS)?

Системный администратор / IT‑специалист:

• Есть ли мониторинг нетипичных HTTP‑заголовков у пользователей в сети?
• Проводились ли тесты на вмешательство со стороны провайдера?
• Есть ли инструкции для сотрудников по использованию корпоративного VPN и защите учётных данных?

Активист / журналист:

• Используется ли многослойная защита (VPN + HTTPS + зашифрованная почта)?
• Готов ли план безопасной коммуникации и резервного канала при компрометации основных сервисов?

Стандарты приёма и тесты (test cases)

1. Тест: доступ к контролируемому HTTP‑серверу без VPN. Ожидаем: наличие X‑UIDH или аналогичных полей — если они есть, регистрируем.
2. Тест: доступ к тому же серверу через VPN. Ожидаем: отсутствие дополнительных полей.
3. Тест почты: соединение с почтовым сервером, отправка STARTTLS. Ожидаем: сервер отвечает и переходит в TLS. Если STARTTLS удалён — критическая ошибка.

Рекомендации по безопасности для организаций

• Требуйте от сотрудников использования корпоративного VPN при работе вне защищённой сети.
• Используйте политики MDM/EMM для блокировки нежелательных приложений и для форсирования конфигураций почты и VPN.
• Проводите регулярные аудиты сетевого трафика и тесты на вмешательство провайдера.

Правовые и конфиденциальные аспекты (заметка о GDPR и приватности)

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

Быстрый план реагирования (playbook) при обнаружении вмешательства

1. Документируйте доказательства: снимки заголовков, логи, даты и номера сессий.
2. Сообщите в службу поддержки провайдера с описанием проблемы и доказательствами.
3. Если провайдер не реагирует — обратитесь к регулятору связи или защите данных в вашей стране.
4. Информируйте пользователей и сотрудников о временных мерах (включить VPN, избегать HTTP).
5. По возможности опубликуйте технический отчёт для общественности (с учётом безопасности источников).

Пример мер жёсткой безопасности (Hardening)

• Принудительное использование HSTS и HTTPS на всех веб‑ресурсах.
• Блокировка незашифрованного трафика на уровне корпоративной сетевой политики.
• Централизованное управление VPN/SSL и аудит сертификатов.

Памятка: что делать прямо сейчас

1. Включите и настройте надёжный VPN на мобильном устройстве.
2. Предпочитайте HTTPS и проверяйте адресную строку браузера.
3. Настройте почтовый клиент на IMAPS/SMTPS и проверяйте использование TLS.
4. Если вы администратор — проведите тесты и проинструктируйте сотрудников.

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

Q: Удаляет ли приватный режим браузера перма‑cookie?
A: Нет — перма‑cookie вставляется на уровне сети и не зависит от браузерных cookie.

Q: Поможет ли защищённый DNS (DoH/DoT)?
A: Защищённый DNS защищает только разрешение имён; он не шифрует HTTP‑заголовки и не помешает провайдеру вставлять поля в незашифрованные HTTP‑запросы.

Заключение

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

Photo Credits: Google mail homepage (удалённый/недоступный), Verizon homepage (удалённый/недоступный), изображения интернет cookie, меню электронной почты

Краткое резюме и действия:

• Включите VPN при использовании мобильного интернета.
• Проверяйте, использует ли ваш почтовый клиент TLS.
• Проводите простые тесты на наличие непредвиденных заголовков.