dxdt.ru: занимательный интернет-журнал

Одна из не очевидных особенностей DNS, как сервиса, в том, что этот сервис позволяет преодолевать самые разнообразные системы сетевых ограничений. Типичная ситуация: на некотором сервере закрыты не только все внешние входящие, но и исходящие сетевые соединения “во внешний Интернет”; это может быть сделано как силами сетевого экрана (файрвола) в операционной системе, так и настройкой правил на том или ином маршрутизаторе, за которым подключен сервер. Однако DNS-сервис здесь доступен через выделенный локальный (для сетевого сегмента) резолвер без ограничений. Почему? Во-первых, без DNS не работает множество привычных системных утилит. Во-вторых, администраторы нередко воспринимают DNS именно как сервис, поэтому доступ к резолверу считается доступом к локальным ресурсам и не фильтруется.

Понятно, что так как исходящие соединения закрыты, то запущенная на сервере “троянская программа” не сможет простым способом передать какие-то данные внешнему узлу. Но можно передать данные через DNS. Типовой и универсальный способ – запрос A-записи для имени в доменной зоне, которая делегирована на авторитативные серверы, контролируемые “принимающей стороной”. Предположим, что нужно передать последовательность из нескольких байтов (с произвольными значениями), а “инструментальная” доменная зона – test.ru. Закодируем последовательность тем или иным способом в подмножество допустимых ASCII-символов и запросим в DNS имя, где получившаяся строка будет дописана на третьем (и ниже) уровне: JBQWY3DPFVUGC3DMN4QSCIIK.TEST.RU. Данное имя, через резолвер (или несколько резолверов) попадёт в составе запроса на авторитативный сервер зоны test.ru, где его можно обработать и извлечь данные. (При необходимости, можно разделить запись полезной нагрузки точками – это не повлияет на доставку.)

DNS-запросы, содержащие подобную “абракадабру”, далеко не всегда вызывают подозрения, потому что могут генерироваться не только какими-нибудь элементами ботнета, но и вполне штатными программами, которые таким образом пытаются, например, обнаружить подмену и перехват DNS. Однако, для повышения уровня скрытности, запросы могут кодироваться каким-нибудь другим, вполне “безобидным”, способом: table.is.unavail.fedora.test.ru. Но каждый шаг в сторону снижения уровня “подозрительности” будет снижать и пропускную способность канала передачи.

(В обратную сторону подобная схема тоже может работать, но с меньшей надёжностью, поскольку DNS-ответы могут быть подменены, в том числе, ответы с А-записями.)

Добавил (некоторое время назад) в DNS-зону dxdt.ru HTTPS-запись. Название записи может показаться странным в контексте DNS, тем не менее, именно так новая запись, описанная в черновике RFC, и называется. Я кратко упоминал эту запись в статье об использовании DNS для публикации вспомогательной информации:

Например, идёт работа над черновиком (draft) спецификации для DNS-записей с рабочим названием SVCB/HTTPS. Предполагается, что эти записи будут использоваться для публикации данных, определяющих начальные настройки доступа к интернет-ресурсам под данным доменным именем. Отличие от уже имеющихся типов записей (например, от адресных записей) весьма существенное: записи SVCB/HTTPS позволят публиковать сразу набор сведений о нескольких «фронтендах», ответственных за соответствующий сервис (например, веб) под заданным именем; в этот набор включаются разнообразные дополнительные параметры, например, определяющие нестандартные номера портов TCP/UDP, на которых отвечают серверы, или криптографические ключи, позволяющие установить соединение со скрытым сервисом.

Так как dxdt.ru не использует сложных настроек и каких-то дополнительных сервисов для доставки веб-страниц, то и соответствующая HTTPS-запись получилась максимально простой: она всего лишь информирует, что к веб-узлу следует сразу подключаться по HTTPS. То есть, клиент, который поддерживает SVCB/HTTPS, при получении ссылки на сайт с протоколом HTTP, не будет пытаться установить небезопасное подключение, чтобы прочитать HTTP-перенаправление на HTTPS, а сразу использует безопасный протокол. По крайней мере, такова цель размещения HTTPS-записи – реально, мало кто их пока что поддерживает.

А основные SVCB-записи, конечно, гораздо богаче по предоставляемым возможностям. В основном, из-за того, что позволяют публиковать криптографические ключи и сведения о точках входа, которые могут быть использованы для установления соединения в режиме “максимального сокрытия” метаинформации. Это развитие технологии ESNI.

В продолжение заметки про TLS-сертификаты и роль Certificate Transparency. Конечно, наличие меток логов Certificate Transparency может служить в качестве дополнительного признака при валидации сертификата браузером. Однако нужно учитывать тот факт, что сама по себе корректная SCT-метка в сертификате вовсе не означает, что данный сертификат был добавлен в лог. Дело в том, что для получения корректной метки достаточно знать сам исходный сертификат (чтобы вычислить значение хеш-функции) и знать секретный ключ лога (чтобы вычислить значение подписи). Собственно, сами SCT-метки появились для того, чтобы отделить вычислительно сложный процесс добавления сертификата в лог от процесса создания метки, предназначенной для включения в сертификат. Согласно планам применения, наличие метки означает, что оператор лога видел сертификат (и должен включить его в лог, иначе оператор нарушает некоторые правила). Если же посмотреть на этот процесс строго, то наличие метки в сертификате означает, что сертификат видела сторона, знающая секретный ключ лога. Поэтому, если клиентская программа, – например, браузер, – не проверяет наличие сертификата непосредственно в логе, а полагается лишь на корректную SCT-метку, полученную в сертификате, то и проверяет такая программа только дополнительную подпись на сертификате, не более того. То есть, для выпуска валидного сертификата с валидной меткой, стороне, которая выпускает такой сертификат, потребуется доступ к двум ключам – удостоверяющего центра и оператора лога (и не обязательно, что эти две роли играют совершенно разные организации). Не более того.

Естественно, проверять наличие сертификатов в логах можно отдельно и другими программами. Главное – получить сам сертификат. В теории, если обнаружен сертификат с меткой, который, тем не менее, отсутствует в соответствующем логе, данный лог должен быть исключен из списка доверенных браузера. И это очень напоминает историю с удостоверяющими центрами TLS.

В ноябре 2012 года, десять лет назад, регистраторы RU-CENTER и R01 включили поддержку DNSSEC для имён в доменных зонах .su, .com, .net. В этом перечне важен домен .su – открытое внедрение DNSSEC в российских реестрах началось именно с него. А включение поддержки означало, что все клиенты даных регистраторов смогут настроить DNSSEC для своих зон. (К сожалению, за прошедшие десять лет слишком многое изменилось, а в результате перемен – утрачена масса полезных исторических веб-страниц, поэтому не могу привести ссылку на текст исходной новости; впрочем, копию пока что можно найти в web.archive.ru.)

Вообще, если посмотреть на сайт под доменом nox.su, то там сказано, что “криптографическая информация, соответствующая домену nox.su, внесена в файл зоны .su 23.11.2011” – то есть, ровно 11 лет назад и годом ранее, чем доступ к DNSSEC появился у упомянутых регистраторов. Это объясняется тем, что с nox.su мне помогли специалисты ТЦИ и RU-CENTER (большая им благодарность!): соответствующую DS-запись в реестр внесли, так сказать, в обход общедоступного интерфейса.

За эти годы DNSSEC не обрела особой популярности. Не только в российских доменах, но и во всей глобальной DNS. Сейчас в зоне .ru лишь около 6 тыс. имён с DS-записью (статистика по другим TLD – картину улучшает не сильно). В моде другие направления и другие этапы доставки данных, а в качестве едва ли не единственного метода защиты информации, на прикладном уровне, используется TLS.

Например, если говорить про DNS, то это DoH (DNS-over-HTTPS) и DoT (DNS-over-TLS). Естественно, эти технологии не позволяют, на уровне клиента, проверить подлинность данных именно DNS-ответа, однако делают возможной аутентификацию узла-источника, который эти данные принёс (DNS-резолвер), защищают канал передачи от прослушивания и подмены. Обычно, всё это доступно только на “последней миле” (то есть, от резолвера до клиента). Использование DoH/DoT не отменяет, конечно, возможности проверки DNSSEC, как и не решает основной задачи DNSSEC – подтверждения подлинности адресной информации.

Выпустил ежегодное обновление технического описания протокола TLS. Каких-то больших дополнений в этом году не вышло, но актуализировал весь текст. (Есть, впрочем, очень краткое новое приложение (В), посвящённое ГОСТ-TLS.)

Certificate Transparency – это набор связанных с иерархией Удостоверяющих Центров (УЦ) TLS технологий, который позволяет вести специальные логи выпускаемых и выпущенных сертификатов. Предполагается, что логи общедоступны, а их наличие позволит обнаружить сертификаты, выпущенные с нарушением правил. Чтобы усилить действие Certificate Transparency (CT), браузеры (или другие программы, которые выполняют валидацию сертификатов) могут требовать подтверждения того, что конкретный сертификат был учтён в том или ином логе CT. Удобная реализация такого требования подразумевает наличие некоторых подписанных ключами логов меток в составе самого сертификата. Такие метки называются SCT – Signed Certificate Timestamp.

Метку SCT выдаёт оператор CT-лога в ответ на добавление сертификата в лог. Когда Certificate Transparency первой версии только проектировали, то этот момент, к сожалению, не учитывали. Поэтому проявилась проблема “курицы и яйца”: чтобы выпустить сертификат с SCT-меткой – нужно получить метку, а чтобы получить метку – нужно выпустить сертификат (для того, чтобы отправить его в лог). В качестве некоторого “обходного решения” (“костыля” – скажут те, кто “хорошо в теме”) предложили ввести пресертификаты.

Пресертификат – он такой же, как и TLS-сертификат, но содержит специальное расширение (Poison), которое отмечено как критически важное (Critical), но при этом не должно распознаваться обычным валидатором. Хитрость, на которую делается расчёт, состоит в том, что, согласно рекомендациям, в случае обнаружения неизвестного расширения с флагом Critical процедура валидации должна считать сертификат не валидным. Все прочие поля пресертификата в точности совпадают с соответствующими полями сертификата, в этом весь смысл. Однако “отравленный” пресертификат как бы нельзя использовать на практике для аутентификации. И, обычно, это работает. Но, конечно, полагать, что все разнообразные валидаторы строго следуют рекомендациям по обработке расширений – слишком смело.

Тем не менее, пресертификаты широко используются в CT: УЦ, готовясь выпустить сертификат с SCT-меткой, прежде генерирует и подписывает пресертификат с теми же параметрами (имя, серийный номер и т.д.), но с poison-расширением, отправляет пресертификат в CT-лог, получает в ответ метку с подписью лога, которую уже размещает в полноценный сертификат. Таким образом в логе возникает отметка о пресертификате, которая позволяет получить все содержательные данные о сертификате. В сертификате же появляется SCT-метка, подтверждающая, что оператор лога видел сведения о сертификате. Валидность метки может проверить валидирующая программа – для проверки используется ключ лога. Этот процесс нарушает рекомендации по работе УЦ, поскольку запрещено выпускать два сертификата с одним серийным номером (и одним именем УЦ), но этот момент принято выносить за скобки.

Впрочем, во второй версии Certificate Transparency от пресертификатов отказались – для размещения сведений о сертификате используются сообщения другого формата, их формирование не требует выпуска как бы настоящего, но “испорченного” сертификата.

Технический Центр Интернет (ТЦИ) открыл российский общедоступный удостоверяющий центр (называется “Центр сертификации”) TLS: https://tlscc.ru/ (бета-версия).

Центр позволяет выпускать TLS-сертификаты как с ECDSA, так и с ГОСТ-подписью. Чтобы заказать сертификат, требуется зарегистрироваться на сайте. Для подтверждения права управления доменным именем можно использовать DNS (размещается TXT-запись с кодом) или веб-сервер (публикуется текстовый файл). Однако нужно учитывать, что действующие корневые ключи УЦ не входят в дистрибутивы браузеров (возможно, пока что не входят), поэтому для использования сертификатов их придётся добавить вручную.

В продолжение предыдущей записки, про сертификаты от Let’s Encrypt. RSA и ECDSA – это распространённые в Интернете криптосистемы, которые используют различную математическую основу. ECDSA имеет целый ряд преимуществ. Однако в случае TLS-сертификатов существенный смысл в использовании ECDSA возникает тогда, когда вся цепочка сертификатов использует эту криптосистему.

Дело в том, что валидация (то есть, процесс установления подлинности) серверного сертификата подразумевает проверку подписи на одном или нескольких других сертификатах – это сертификаты удостоверяющих центров (УЦ). Технически, можно серверный (то есть, оконечный) сертификат с ECDSA-ключом подписать при помощи RSA. Именно так и делает Let’s Encrypt. При этом корневой доверенный сертификат с ECDSA у них уже есть, но вот оконечные сертификаты с ECDSA для обычных пользователей не выпускаются. Допускаю, что я не нашёл, где такую возможность включить, но, на мой взгляд, для оконечного сертификата с ECDSA автоматом должна выбираться вся цепочка с ECDSA – использование RSA, в этом случае, выглядит весьма странно (впрочем, учитывая, что сейчас 2022 год, RSA и в других случаях выглядит странно). Тем не менее, сертификат для dxdt.ru, который я вынужден был выпустить через Let’s Encrypt, содержит RSA-подпись. Ничего не поделать. Раньше, когда были доступны и другие УЦ, я использовал PositiveSSL, для которого есть ECDSA-цепочка.

Заметка на dxdt.ru из 2009 года, рассказывающая о том, как идентифицировать пользователя приложения по отметкам геолокации:

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

Теперь о том, как же вычислить пользователя. Вот как: фиксируются его места пребывания в рабочее время, и в не рабочее время. Приехал человек на работу, находится долго “на одном месте” – несложно вычислить и место, и, собственно, рабочее время, так как людям свойственно действовать по некоторому графику. Вычисляется всё автоматически, никакой “сложной эвристики”.

За прошедшие годы актуальность только выросла: вспомните про суперпопулярные нынче приложения для “анонимного отслеживания контактов”.

Если из браузера утекают сеансовые ключи, то расшифровывать TLS-трафик можно в пассивном режиме, и не потребуются никакие “перехватывающие удостоверяющие центры”. А намеренную утечку может организовать сам браузер. Или другой клиент TLS. А также и сервер. Довольно интересно в этом контексте выглядит распространённая сейчас в мире персональных компьютеров ситуация, когда TLS-трафик перехватывает и проксирует локальный антивирус.

Традиционно, подобные механизмы “контролируемых утечек” в криптологии основываются на “порче” алгоритма вычисления псевдослучайных чисел (см. хрестоматийный пример про DUAL_EC DRBG). Так, в современных реализациях TLS сеансовый секрет вычисляется по алгоритму Диффи-Хеллмана (DH). Если в результате утечки третьей стороне станет известен клиентский секрет DH (то есть, секрет браузера), то эта сторона сможет вычислить симметричные ключи защиты трафика и всё расшифровать в пассивном режиме. При использовании “испорченного” программного генератора псевдослучайных чисел браузеру достаточно передать третьей стороне состояние генератора, в котором он находился перед тем, как были запрошены случайные числа для секрета DH. Генератор, естественно, детерминированный, поэтому, зная его полное состояние, нетрудно вычислить вывод (то есть, секрет DH). Грамотный подход подразумевает, что авторизованная третья сторона знает некоторый дополнительный ключ, который даёт гарантию, что раскрыть данные утечки сможет только эта сторона, а не всякий, кто разгадал алгоритм и записал трафик (именно так было сделано в DUAL_EC DRBG).

Утечку можно организовать самыми разными способами. Например, начальные сообщения сеанса TLS содержат случайные значения, которые, конечно, могут быть “не совсем случайными”. Более ловкие варианты основаны на манипуляции длиной сообщений (или пакетов данных), на передаче дополнительных параметров и так далее. Главное – каким-то способом поставить измеримую характеристику трафика в зависимость от состояния генератора псевдослучайных чисел клиента. Самое занимательное, что наличие такой зависимости может быть неплохо обосновано “желанием замаскировать метаинформацию о соединении”.

А использование подменного УЦ – это довольно грубый метод. Который, во-первых, требует активного перехвата соединения; во-вторых – оставляет надёжные, хорошо заметные следы.

В “Яндекс.Браузер” добавили ограниченную (по именам) поддержку для TLS-сертификатов, выпущенных от российских корневых ключей, которые не входят в списки “хорошо известных” корневых ключей (сертификатов) браузеров. Собственно, поэтому “Яндекс.Браузер” тут и выделяется – в другие браузеры нужно добавлять соответствующие сертификаты вручную. Сделано это, понятно, для того, чтобы получить резервный механизм обеспечения HTTPS в свете отзыва сертификатов теми самыми “хорошо известными” удостоверяющими центрами (в рамках санкций). Подробнее – по ссылке (“Хабр”).