<div id="post_message_791770">

Даже через HTTPS видно, где вы работаете, что любите и кого поддерживаете — и это не баг, а стандарт.<br/>
<br/>
Несмотря на распространённость HTTPS, который защищает содержимое веб-сайтов от перехвата, немалая часть данных о действиях пользователей по-прежнему остаётся открытой. Один из таких уязвимых участков — доменные имена сайтов, которые легко перехватываются сотовыми операторами, Wi-Fi-провайдерами и злоумышленниками. Эти данные, даже в минимальном объёме, могут быть использованы для профилирования, шантажа или целевых атак на отдельные категории людей, включая государственных служащих и другие уязвимые группы.<br/>
<br/>
Поверхностный просмотр сайтов может рассказать о человеке больше, чем он сам осознаёт. Один из сотрудников Google <a href="https://medium.com/jigsaw/a-more-private-internet-encryption-standards-hit-new-milestones-c239ede23eaf" target="_blank">провёл </a>простой эксперимент: собрал доменные имена всех сайтов, которые посетил в течение одного часа. Этого оказалось достаточно, чтобы на основе полученных данных сделать выводы о его текущем местоположении, месте работы, профессиональных и личных интересах, а также потенциальных связях. Такие выводы могут быть автоматически получены и масштабированы при помощи современных аналитических систем.<br/>
<br/>
<img alt="" border="0" class="bbCodeImage" src="https://cdn.securitylab.ru/upload/medialibrary/5c4/5e2nyhphslrig3rjo1o5r1ue1ugmvgef.png"/><br/>
<div style="margin:20px; margin-top:5px; ">
<!-- <div class="smallfont" style="margin-bottom:2px">Quote:</div> -->
<table border="0" cellpadding="6" cellspacing="0" width="100%">
<tr>
<td class="alt2" style="background: rgb(37, 37, 37) none repeat scroll 0% 0%; border: 1px solid rgb(0, 0, 0); border-radius: 5px; font-size: 11px; text-shadow: none;">

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

</td>
</tr>
</table>
</div>Проблема в том, что при защищённом HTTPS-соединении доменные имена просачиваются наружу как минимум в двух точках. Первая — это DNS-запрос: когда браузер пытается определить IP-адрес сайта. Исторически такие запросы передавались в незашифрованном виде, что позволяло отслеживать, какие ресурсы посещаются. Вторая — это фаза TLS ClientHello, при которой браузер инициирует подключение к серверу и передаёт параметры шифрования. До начала самого шифрования в сообщении содержится незашифрованное имя сайта, необходимое для правильного выбора сертификата на стороне сервера. Только после ответа ServerHello начинается полноценная защита трафика.<br/>
<br/>
Обе эти точки остаются уязвимыми уже много лет, и главной причиной тому были два замкнутых круга. Во-первых, разработчики не стремились исправлять только один из каналов утечки, если второй всё равно оставался открытым — ведь эффективность защиты в таком случае сомнительна. Во-вторых, клиентские и серверные решения двигались несогласованно: браузеры и операционные системы не внедряли поддержку зашифрованных DNS-запросов, потому что серверы не предлагали такую возможность, и наоборот.<br/>
<br/>
<img alt="" border="0" class="bbCodeImage" src="https://cdn.securitylab.ru/upload/medialibrary/59d/u9e7wir8rna0m5ye7oeyo20yjtv08dlc.png"/><br/>
Шаги для получения доступа к веб-сайту (Medium.com)<br/>
<br/>
Чтобы разорвать этот цикл, Google начал с защиты DNS-запросов. Совместно с командой Jigsaw компания стала одним из инициаторов рабочих групп в рамках Internet Engineering Task Force ( <a href="https://www.ietf.org/" target="_blank">IETF </a>), направленных на разработку и распространение протоколов защищённого DNS. Внедрение зашифрованного DNS было реализовано в <a href="https://android-developers.googleblog.com/2018/04/dns-over-tls-support-in-android-p.html" target="_blank">Android </a>, <a href="https://blog.chromium.org/2020/05/a-safer-and-more-private-browsing-DoH.html" target="_blank">Chrome </a>, сервисе <a href="https://developers.google.com/speed/public-dns/docs/dns-over-tls" target="_blank">Google Public DNS</a> , а также через приложение Jigsaw Intra . При участии других компаний, таких как Cloudflare, Mozilla Firefox и Quad9, удалось обеспечить защиту более чем <a href="https://stats.labs.apnic.net/edns" target="_blank">одного миллиарда пользователей</a> по всему миру.<br/>
<br/>
На этом фоне и государственные организации стали уделять внимание уязвимости DNS. В США Управление по вопросам управления и бюджета (OMB) потребовало от всех федеральных агентств перейти на зашифрованный DNS до конца 2024 года, указывая на необходимость усиления киберзащиты правительственной инфраструктуры. В Европе аналогичные <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=OJ%3AL_202402690" target="_blank">положения </a>содержатся в Регламенте по реализации <a href="https://digital-strategy.ec.europa.eu/en/policies/nis2-directive" target="_blank">Директивы NIS2</a> , в котором закреплены «лучшие практики обеспечения безопасности DNS».<br/>
<br/>
После значительного прогресса на стороне DNS Google направил усилия на вторую ключевую точку утечки — шифрование данных в сообщении ClientHello. Этот шаг давно обсуждался в рамках IETF, но лишь недавно получил полноценную реализацию в виде стандарта Encrypted Client Hello (ECH). Кроме того, была разработана дополнительная спецификация для доставки ключей шифрования ECH, которая не только делает передачу данных безопасной, но и ускоряет установку защищённого соединения.<br/>
<br/>
Поддержка нового стандарта была реализована в браузере <a href="https://chromestatus.com/feature/6196703843581952" target="_blank">Chrome </a>, а также в криптографической библиотеке <a href="https://issues.chromium.org/issues/40644929" target="_blank">BoringSSL </a>, которая используется в множестве приложений. Для тестирования совместимости и ускорения внедрения Google тесно сотрудничал с Cloudflare, подтвердив, что технология может стабильно работать на практике. Уже в ближайшие недели стандарт ECH будет опубликован IETF, что откроет путь к его широкому внедрению в различных браузерах и системах.<br/>
<br/>
При этом новая степень шифрования не означает потерю контроля со стороны администраторов сетей, школ или предприятий. В Android и Chrome реализация защищённого DNS позволяет настраивать его поведение с помощью корпоративных политик и выбирать предпочитаемого провайдера. Протоколы устроены так, чтобы шифровать сам канал передачи данных, но при этом оставлять управление на уровне клиента. Это означает, что родительский контроль и защита от вредоносных сайтов по-прежнему работают — либо через клиентские решения, либо через DNS-провайдеров. Агентство CISA опубликовало <a href="https://www.cisa.gov/sites/default/files/2024-05/Encrypted%20DNS%20Implementation%20Guidance_508c.p df" target="_blank">рекомендации по применению зашифрованного DNS (.pdf)</a> , позволяющие сохранять баланс между конфиденциальностью и соответствием требованиям.<br/>
<br/>
По мере роста угроз, усиленных применением нейросетей и генеративного ИИ, необходимость в тотальной шифровке трафика становится всё более очевидной. Google заявляет о своей приверженности делу приватности и продолжит инвестировать в развитие и распространение технологий вроде зашифрованного DNS и ECH. Широкое сотрудничество с другими компаниями, правительствами и техническим сообществом может изменить архитектуру интернета, сделав его по-настоящему безопасным и конфиденциальным.<br/>
<br/>
<a href="https://www.securitylab.ru/news/559396.php" target="_blank">@ SecurityLab </a>
</div>