Вы только загрузили страницу — а провайдер уже знает, о чём вы будете думать следующие 10 минут

[WWW]

Даже через HTTPS видно, где вы работаете, что любите и кого поддерживаете — и это не баг, а стандарт.



Несмотря на распространённость HTTPS, который защищает содержимое веб-сайтов от перехвата, немалая часть данных о действиях пользователей по-прежнему остаётся открытой. Один из таких уязвимых участков — доменные имена сайтов, которые легко перехватываются сотовыми операторами, Wi-Fi-провайдерами и злоумышленниками. Эти данные, даже в минимальном объёме, могут быть использованы для профилирования, шантажа или целевых атак на отдельные категории людей, включая государственных служащих и другие уязвимые группы.



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

Примеры того, что доменные имена могут рассказать о пользователе (Medium.com)

Проблема в том, что при защищённом HTTPS-соединении доменные имена просачиваются наружу как минимум в двух точках. Первая — это DNS-запрос: когда браузер пытается определить IP-адрес сайта. Исторически такие запросы передавались в незашифрованном виде, что позволяло отслеживать, какие ресурсы посещаются. Вторая — это фаза TLS ClientHello, при которой браузер инициирует подключение к серверу и передаёт параметры шифрования. До начала самого шифрования в сообщении содержится незашифрованное имя сайта, необходимое для правильного выбора сертификата на стороне сервера. Только после ответа ServerHello начинается полноценная защита трафика.



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





Шаги для получения доступа к веб-сайту (Medium.com)



Чтобы разорвать этот цикл, Google начал с защиты DNS-запросов. Совместно с командой Jigsaw компания стала одним из инициаторов рабочих групп в рамках Internet Engineering Task Force ( IETF ), направленных на разработку и распространение протоколов защищённого DNS. Внедрение зашифрованного DNS было реализовано в Android , Chrome , сервисе Google Public DNS , а также через приложение Jigsaw Intra . При участии других компаний, таких как Cloudflare, Mozilla Firefox и Quad9, удалось обеспечить защиту более чем одного миллиарда пользователей по всему миру.



На этом фоне и государственные организации стали уделять внимание уязвимости DNS. В США Управление по вопросам управления и бюджета (OMB) потребовало от всех федеральных агентств перейти на зашифрованный DNS до конца 2024 года, указывая на необходимость усиления киберзащиты правительственной инфраструктуры. В Европе аналогичные положения содержатся в Регламенте по реализации Директивы NIS2 , в котором закреплены «лучшие практики обеспечения безопасности DNS».



После значительного прогресса на стороне DNS Google направил усилия на вторую ключевую точку утечки — шифрование данных в сообщении ClientHello. Этот шаг давно обсуждался в рамках IETF, но лишь недавно получил полноценную реализацию в виде стандарта Encrypted Client Hello (ECH). Кроме того, была разработана дополнительная спецификация для доставки ключей шифрования ECH, которая не только делает передачу данных безопасной, но и ускоряет установку защищённого соединения.



Поддержка нового стандарта была реализована в браузере Chrome , а также в криптографической библиотеке BoringSSL , которая используется в множестве приложений. Для тестирования совместимости и ускорения внедрения Google тесно сотрудничал с Cloudflare, подтвердив, что технология может стабильно работать на практике. Уже в ближайшие недели стандарт ECH будет опубликован IETF, что откроет путь к его широкому внедрению в различных браузерах и системах.



При этом новая степень шифрования не означает потерю контроля со стороны администраторов сетей, школ или предприятий. В Android и Chrome реализация защищённого DNS позволяет настраивать его поведение с помощью корпоративных политик и выбирать предпочитаемого провайдера. Протоколы устроены так, чтобы шифровать сам канал передачи данных, но при этом оставлять управление на уровне клиента. Это означает, что родительский контроль и защита от вредоносных сайтов по-прежнему работают — либо через клиентские решения, либо через DNS-провайдеров. Агентство CISA опубликовало рекомендации по применению зашифрованного DNS (.pdf) , позволяющие сохранять баланс между конфиденциальностью и соответствием требованиям.



По мере роста угроз, усиленных применением нейросетей и генеративного ИИ, необходимость в тотальной шифровке трафика становится всё более очевидной. Google заявляет о своей приверженности делу приватности и продолжит инвестировать в развитие и распространение технологий вроде зашифрованного DNS и ECH. Широкое сотрудничество с другими компаниями, правительствами и техническим сообществом может изменить архитектуру интернета, сделав его по-настоящему безопасным и конфиденциальным.



@ SecurityLab