ТехТок №7. Нешуточные вопросы про безопасность и конфиденциальность
В этом выпуске нашей регулярной колонки ТехТок мы затрагиваем вопросы расхода батареи в контексте квантово-устойчивых протоколов шифрования, разбираемся, чем отличаются DoH и DoQ, а также изучаем, что такое цифровые сертификаты — и как они взаимодействуют с такими инструментами, как AdGuard. Пристегните ремни, мы взлетаем.
Пользователь с ником Big Mekk спрашивает нас:
Вы говорите о том, что AdGuard VPN будет поддерживать протокол, устойчивый к Kyber/Quantum-вычислениям. Потребует ли включение данной опции большего ресурса батареи? Я имею в виду повседневное использование на мобильном устройстве.
Для тех, кто еще не в курсе новостей: AdGuard VPN начал поддерживать Kyber — алгоритм, разработанный для защиты от угроз, исходящих от постквантовых компьютеров, — в своих десктопных и мобильных приложениях. Чтобы ответить на заданный вопрос, давайте подробнее рассмотрим, как мы реализуем эту поддержку. Как в мобильных, так и в десктопных приложениях мы используем гибридный подход, сочетающий классический алгоритм эллиптических кривых X25519 и ML-KEM768 на базе Kyber768.
Когда между вашим мобильным устройством и AdGuard VPN устанавливается соединение, оба этих алгоритма используются параллельно. Ваше устройство отправляет два открытых ключа, для X25519 и для Kyber768, и сервер делает то же самое в ответ. Затем каждая сторона извлекает общие секретные значения из обоих алгоритмов и безопасно объединяет их в единый ключ шифрования, который защищает VPN-сессию. Это двойной обмен, и да, он требует больше данных, чем традиционное «рукопожатие». В то время как обычное рукопожатие требует около 32 байт в каждом направлении, гибридное рукопожатие требует около 1,2 КБ.
Что касается влияния на батарею, то дополнительные вычисления действительно немного сильнее нагружают процессор вашего устройства. Если вы используете старое и медленное устройство, установление соединения с использованием алгоритма Kyber может занять на 0,1 секунды дольше обычного. Это может привести к небольшому увеличению расхода заряда батареи, но только на начальном этапе подключения. Эффект незаметен и пренебрежимо мал — особенно по сравнению с такими повседневными действиями, как включение экрана или открытие какого-либо приложения. После установления VPN-соединения сессия работает на основе традиционного симметричного шифрования, а значит, расход батареи остаётся таким же, как и раньше.
Скажем так: если ваше VPN-соединение не обрывается несколько раз за сессию и вам не приходится каждый раз подключаться заново, включение алгоритма Kyber не окажет существенного влияния на время работы батареи.
Какой DNS-протокол более приватен, DOH или DOQ?
Это непростой вопрос, спасибо, Álvaro, что задали его! Прежде чем мы начнём на него отвечать, нам нужно прояснить, что означают DoH (DNS over HTTPS, DNS поверх HTTPS) и DoQ (DNS over QUIC, DNS поверх QUIC) и как именно они передают ваши данные — ведь именно это они и делают. Для этого нам нужно вкратце рассмотреть, как работает DNS (система доменных имён).
Когда ваш браузер хочет получить доступ к сайту, ему необходимо знать его IP-адрес. Именно здесь на помощь приходит DNS-сервер: он переводит (или «разрешает») понятное человеку доменное имя, которое вы вводите в адресную строку, в состоящий из цифр IP-адрес, который используется компьютерами для навигации между сайтами.
Изначально этот процесс осуществлялся полностью открытым текстом — без какого-либо шифрования. Это означало, что ваши DNS-запросы, содержащие в том числе информацию о посещаемых вами сайтах, могли быть видны вашему провайдеру. Это также делало DNS-трафик уязвимым для подслушивания, подделки или спуфинга. Таково было состояние DNS до появления таких зашифрованных протоколов, как DoT (DNS поверх TLS), а затем и DoH (DNS поверх HTTPS). DoT стал первым серьёзным шагом на пути к защите DNS-трафика. Он работает, оборачивая DNS-трафик внутри протокола TLS (Transport Layer Security, «Протокол защиты транспортного уровня»). Он использует отдельный порт — порт 853 — специально зарезервированный для зашифрованного DNS-трафика. Тот факт, что он использует отдельный порт, облегчает работу сетевых администраторов, но также делает трафик DoT более легко обнаруживаемым и, в некоторых случаях, более легко блокируемым фаерволлами или цензорами.
В отличие от DoT, DoH отправляет запросы по HTTPS, смешиваясь с обычным веб-трафиком через порт 443 — тот самый порт, который используется при посещении защищённых сайтов. Это обоюдоострый меч: с одной стороны, трафик DoH сложнее обнаружить или заблокировать, что повышает уровень конфиденциальности. С другой стороны, поскольку DoH часто использует то же HTTPS-соединение, что и посещаемые вами сайты (особенно в браузерах), он может непреднамеренно раскрывать закономерности — например, какие DNS-запросы связаны с какими сайтами или сессиями. По своей сути HTTP и, соответственно, HTTPS не являются протоколами транспортного уровня. Давайте запомним это на будущее.
Как же DoH пересылает ваши данные? Он использует HTTP/2 или HTTP/3 на прикладном уровне — части сети, отвечающей за определение стандартов и процедур обмена информацией — по зашифрованным транспортным протоколам, таким как TCP (для HTTP/2) или QUIC (для HTTP/3). При использовании HTTP/2 несколько DNS-запросов могут быть отправлены одновременно через одно соединение благодаря функции, называемой мультиплексированием. Она позволяет сразу нескольким запросам и ответам использовать одно и то же соединение, не дожидаясь завершения друг друга. Однако, поскольку HTTP/2 работает через одно TCP-соединение, все пакеты данных используют один и тот же транспортный уровень. Это приводит к проблеме, известной как блокировка начала очереди. Если один пакет теряется или задерживается при передаче, все последующие пакеты — даже если они относятся к разным запросам — должны ждать, пока недостающий пакет будет повторно передан и получен. Это задерживает весь поток ответов, даже если другие данные были готовы к отправке. Эта проблема характерна не только для DoH, она затрагивает любой другой протокол, работающий через TCP.
С помощью DoQ каждый DNS-запрос/ответ изолируется в своём собственном потоке, что устраняет проблему блокировки начала очереди, описанную выше.
А теперь давайте вернёмся к главному вопросу: как всё это влияет на вашу конфиденциальность?
Когда DNS-запросы отправляются по одному общему потоку — как это происходит в DoH с HTTP/2, — их временны́е метки становятся связанными. Если один запрос задерживается, это может повлиять на время выполнения других, создавая видимые закономерности в трафике. Даже если контент зашифрован, наблюдатель, например администратор сети, интернет-провайдер или цензор, всё равно может проанализировать эти закономерности, чтобы определить, какие сайты вы посещаете, когда вы их посещаете и как часто.
Ещё одним преимуществом DoQ перед DoH, когда речь идёт о конфиденциальности, является способ обработки трафика. DoQ построен на базе UDP и использует протокол QUIC. В отличие от DoH, который смешивает DNS-запросы с обычным веб-трафиком, DoQ хранит DNS-трафик отдельно — аналогично тому, как это делает DoT, но без проблемы блокировки начала очереди. Такое разделение означает отсутствие смешивания с другим HTTPS-контентом, что затрудняет сторонним наблюдателям привязку DNS-активности к конкретному поведению пользователей в браузере, хотя отличить этот трафик от другого веб-трафика проще.
Однако вы можете задаться вопросом — а как же HTTP/3, последняя версия протокола HTTP, которая также использует QUIC в качестве транспортного уровня? Это хороший вопрос. На самом деле, более 95% основных браузеров, включая Chrome, Firefox и Safari, теперь поддерживают HTTP/3. Но вот в чём дело: хотя HTTP/3 и использует QUIC под капотом, сам HTTP не является транспортным протоколом. И хотя он может служить заменой настоящему транспортному протоколу, это вызовет множество ненужных рисков. Если говорить непосредственно о конфиденциальности, то использование трафика на основе HTTP часто сопряжено с такими вещами, как куки, заголовки аутентификации, строки User-Agent, и другими метаданными. Они могут быть использованы для отслеживания, создания цифровых отпечатков или даже для профилирования пользователей — вещи, которые нежелательно смешивать с чем-то столь чувствительным, как DNS-трафик.
Подводя итог, если DoH обеспечивает высокую степень конфиденциальности, смешиваясь с обычным веб-трафиком (что затрудняет его обнаружение или блокировку), то DoQ позволяет избежать блокировки начала очереди, отделить DNS-трафик от остальной веб-активности и снизить вероятность утечки идентифицирующей информации. С точки зрения конфиденциальности DoQ — лучший вариант.
Это подводит нас к последнему вопросу, заданному анонимным пользователем:
Сертификаты с публичным ключом стали неотъемлемой частью современных сетей. AdGuard устанавливает сертификат на ваше локальное устройство — как он защищает данные? Приносит ли такая установка сертификата больше вреда, чем пользы, или наоборот?
Прежде чем мы углубимся в эту тему, нам необходимо определить, что такое цифровые сертификаты. Проще всего представить цифровые сертификаты как «документы», которые должны предъявлять все сайты, веб-сервисы и API, чтобы доказать, что они действительно являются теми, за кого себя выдают. Можно сказать, что если что-либо «находится в сети» — то есть доступно через интернет и удалённо взаимодействует с пользователями или другими системами, — ему необходим сертификат, подтверждающий его подлинность. Да, ваш трафик может быть зашифрован с помощью HTTPS и безопасен в процессе передачи, но без цифровых сертификатов вы не сможете определить, является ли сайт, к которому вы подключаетесь, настоящим, или же кто-то выдаёт себя за него, чтобы, возможно, украсть вашу информацию.
Но если мошенник готов пойти на создание сайта только для того, чтобы украсть ваши конфиденциальные данные, что помешает ему подделать и сертификат тоже? К счастью, сделать это не так просто. Когда ваш браузер подключается к сайту, сайт отправляет свой сертификат, а также все промежуточные сертификаты, образующие цепочку до доверенного корневого центра сертификации (ЦС), которому браузер уже доверяет. Затем браузер с помощью криптографии с открытым ключом проверяет цифровую подпись на каждом сертификате в цепочке и, если всё в порядке, даёт зелёный свет на установление соединения. Таким образом, практически невозможно подделать сертификат, не скомпрометировав перед этим ЦС или не выдав себя за него. Это не невозможно, но крайне маловероятно — последний крупный инцидент со взломом центра сертификации произошёл в 2017 году. Браузеры и операционные системы уже поставляются со списком доверенных сертификатов корневых ЦС, а производители регулярно обновляют списки доверенных ЦС, удаляя скомпрометированные или ненадёжные ЦС и добавляя новые. Пользователи также могут вручную добавлять центры сертификации в список доверенных, но делать это следует с особой осторожностью.
Теперь вернёмся к тому, как AdGuard участвует в этом процессе. Допустим, вы установили приложение AdGuard для Windows, Mac или Android (браузерные расширения и приложение AdGuard для iOS работают по-другому), и ваш браузер хочет подключиться к веб-серверу. AdGuard занимает позицию между браузером и сервером, так что трафик браузера сначала проходит через AdGuard. Но точно так же, как ваш браузер должен доверять серверу, когда он подключается к сайту напрямую, браузер должен доверять AdGuard, иначе у AdGuard не было бы возможности расшифровывать HTTPS-трафик. А для этого, как мы уже знаем, нужен доверенный сертификат. Поэтому при установке AdGuard генерирует специальный корневой сертификат и устанавливает его в вашу систему.
Ранее мы уже говорили о том, что пользователям не стоит легкомысленно добавлять пользовательские сертификаты, и мы остаёмся при своём мнении. Есть причина, по которой вы должны быть осторожны — если вы доверитесь кому-то, кому не должны, то последствия могут быть весьма плачевными. Но мы очень серьёзно относимся к вопросам безопасности. В криптографии с открытым ключом очень важно хранить свой приватный ключ в безопасности, и AdGuard генерирует приватный ключ на вашем устройстве. Этот ключ шифруется и хранится локально; он никогда никому не передаётся, и никто его не знает, даже мы.
И, конечно же, ваш исходящий трафик остаётся безопасным благодаря AdGuard. После расшифровки HTTPS-трафика и блокировки всех найденных в нём рекламных объявлений и трекеров он зашифровывает всё заново. AdGuard проверяет подлинность веб-сервера, проверяя его сертификат, точно так же, как это делает ваш браузер. Мы приняли некоторые дополнительные меры безопасности, подробнее о них вы можете прочитать в статье Базы знаний.
В конечном итоге AdGuard не повышает безопасность вашего соединения как такового, но и не создаёт дополнительных рисков. Вы можете установить приложение AdGuard на своё устройство и быть уверенным, что ваш трафик будет свободен от рекламы и трекеров, оставаясь при этом безопасным.
