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

Кстати, о трафике на веб-узлах. Я поддерживаю тестовый сервер TLS 1.3 (https://tls13.1d.pw/) с HTTPS – это специальный сервер, написанный на языке Go и предназначенный, как нетрудно догадаться, для тестирования разных свойств TLS версиии 1.3. Cервер был запущен около пяти лет назад, когда спецификация TLS 1.3 ещё была черновиком. Надо заметить, что сейчас сервер принимает и обрабатывает примерно одно соединение в секунду (немало), часть из этих соединений – это TLS, а часть из TLS-соединений – это соединения версий 1.3 (“версий” – потому что иногда встречаются и draft-версии). Впрочем, по какой-то не совсем ясной причине, большинство успешных соединений инициируют клиенты, которые представляются как боты сервисов мониторинга доступности интернет-узлов. Представляются эти боты через строку User-Agent: сервер ориентирован на HTTPS, поэтому реализует минимальную логику обработки HTTP-заголовков, так что User-Agent – виден (но только для успешного TLS-соединения, понятно).

В конце 2018 года я добавил к тестовому серверу поддержку технологии ESNI, которая тогда находилась в состоянии эксперимента. Собственно, исходная версия ESNI поддерживается на tls13.1d.pw и сейчас, вот только поддержку ESNI удалили из браузеров и с серверов провайдера Cloudflare. Причина в том, что сама технология с тех пор была полностью переработана и теперь даже называется иначе – ECH. Так что, возможно, отключу поддержку ESNI. Тем более, что и ключи в DNS устарели. Конечно, надо бы взамен дописать реализацию ECH, но таких планов у меня нет, как и планов по развитию тестового сервера.

Подписи DNSSEC в глобальном корне DNS появились в 2010 году. Это подписи криптосистемы RSA, которая сейчас считается устаревшей. Ввод DNSSEC прошёл в таком режиме, который не содержал даже механизма обновления корневых ключей – этот механизм внедрили существенно позже. Корневой ключ заменили, но криптосистема осталась той же – RSA. И вот, в 2023 году ICANN “планирует начать процесс подготовки” внедрения новых криптосистем в корневой зоне DNS: на днях опубликовали сообщение о создании рабочей группы. Можно предположить, что в корне DNS появится ECDSA, а может быть даже и что-то из разряда EdDSA (но этот вариант, конечно, вряд ли).

Процитирую заметку из 2016 года, про MITM для TLS:

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

Уточнить, пожалуй, тут можно вот что: во-первых, если перехватывающий узел не проверяет подлинность “внешних” узлов по сертификатам (а нужно считать, что не проверяет), то этот самый узел точно так же может оказаться под атакой MITM, затянув туда и все “внутренние” узлы, которые через него работают; во-вторых, если за MITM-прокси стоит большое количество ничего не подозревающих пользователей, то для третьей стороны повышается привлекательность своего собственного MITM (см. предыдущее предложение) даже с подменными сертификатами от хорошо известного УЦ – просто потому, что такая атака будет направлена на единственный узел (на MITM-прокси) и гораздо больше шансов, что никто не заметит (при этом пользователей, которые попадут под “двойной перехват” – сразу много).

К модному потоку автоматических говорилок подключился Google, который грозится встроить ответы, сгенерированные вероятностным способом по “синтаксическим” конструкциям, в результаты поиска. То есть, если следовать описанию по ссылке, то в выдаче поиска, – вместо, предположим, “Википедии”, – Google станет генерировать пространные объяснения собственными силами. Основное преимущество, как можно предположить, тут в том, что содержание ответа можно автоматически подстраивать под профиль пользователя и прочие актуальные параметры – это будет забавно, так как нетрудно применить (ложную) максиму “компьютер не может ошибаться”, тем более, если это компьютер Google.

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

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

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

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

Переход сети ARPANET на TCP/IP состоялся 01/01/1983 – то есть, в 2023 году Интернету исполнилось 40 лет. Почему отсчёт связан именно с этой датой? Потому что Интернет, как глобальная сеть, это именно ARPANET c TCP/IP и связанные технологии, к которым, прежде всего, отсносятся механизмы IP-маршрутизации между компьютерными сетями. Интернет составляют автономные системы. Логические инструменты, позволяющие определить автономную систему (в терминах Интернета и маршрутизации), это следущие понятия:

• межсетевая граница контроля над связностью узлов;
• пограничный маршрутизатор;
• алгоритм маршрутизации и схема межсетевой адресации узлов.

Межсетевая граница – позволяет разделить сетевые узлы внутри и сетевые узлы снаружи, с точки зрения структуры связности; ключевой аспект: локальная администрация сети контролирует и самостоятельно определяет связность локальных узлов (то есть, “какой компьютер куда и как подключен”), а на “коммутацию” внешних узлов повлиять не может и об их реальной связности ничего априори не знает.

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

Алгоритм маршрутизации и межсетевой адресации узлов – это универсальный и эффективный способ адресовать сети и узлы так, чтобы можно было строить практические маршруты доставки пакетов через межсетевые границы при помощи пограничных узлов-маршрутизаторов, абстрагируясь от свойств физических каналов и конкретных протоколов электросвязи. Это и есть IP (префиксы и адреса узлов) и необходимый, в современной сети, BGP (Border Gateway Protocol).

Второй важнейший составляющий элемент Интернета – DNS. Но здесь он оставлен за скобками.

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

Немного поправил внутренний код и CSS темы оформления WordPress, которая используется на dxdt.ru сейчас. Визуальных изменений очень мало, но если показывается неправильно (что-нибудь уехало и т.д.) в браузере, то нужно нажать Ctrl+F5 или Ctrl+Shift+R (относится только к десктопным браузерам, понятно).

Кстати, нередко для обновления страницы предлагают использовать Ctrl+R (F5). Но, в случае изменений на строне разработки, это не лучший вариант, по крайней мере, для Firefox и Chrome: Ctrl+R действительно вызывает повторную загрузку страницы, но разрешает использование собственного кеша браузера, так что какие-то элементы могут читаться из кеша. А вот Ctrl+F5 или Ctrl+Shift+R – это загрузка страницы со сбросом состояния кеша.

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

Добавил (некоторое время назад) в 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.

На тестовом сервере TLS 1.3, который я реализовал и некоторое время поддерживаю по адресу tls13.1d.pw, пришлось тоже перейти на TLS-сертификаты Let’s Encrypt. А это привело к замене цепочки с ECDSA на цепочку с RSA, что, конечно, не очень хорошо. Вообще, так как сервер экспериментальный и полностью самописный, замена сертификатов требует ручного вмешательства, поэтому “долгие” сертификаты удобнее, чем трёхмесячные. Но, в принципе, можно процесс автоматизировать.

Я как-то перестал описывать изменения тестового сервера на dxdt.ru: прошлая записка на эту тему датирована январём 2020 года. При этом сервер продолжают использовать, он даже помогает находить ошибки и неточности в реализациях 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 – подтверждения подлинности адресной информации.