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

Цитата из моего технического описания TLS:

Весьма полезной практикой является разумное выравнивание стойкости используемых криптосистем. Например, в подавляющем большинстве случаев не имеет смысла использовать RSA-ключ длиной в 4096 бит, если ваш TLS-сервер всё ещё поддерживает SSLv3, а в качестве симметричного шифра применяет DES с 56-битным ключом.

Детали зависят, конечно, от модели угроз, но что здесь имеется в виду? Предположим, что серверный TLS-сертификат использует криптосистему RSA с длинным ключом, при этом для согласования сеансового симметричного ключа тоже используется RSA (то есть, исходные данные ключа зашифровываются RSA – устаревший метод, который широко применялся в TLS ранее). Защищает ли этот факт дополнительно трафик, зашифрованный нестойким шифром, для которого нетрудно вычислить секретный ключ? Понятно, что не особенно: проще раскрыть действующий симметричный ключ при помощи криптоанализа шифра, не касаясь RSA. Невозможность прочитать исходный секрет этому не помешает (естественно, считаем, что реализация RSA сохраняет стойкость). Можно было бы предположить, что задача другая: например, требовалось надёжно защитить узел от подмены, а передаваемый трафик, напротив, сделать доступным для чтения “подготовленной стороной”. Но в случае только что описанного сценария TLS это не сработает.

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

В TLS 1.3 криптосистема RSA для зашифрования не используется, а процесс получения сеансовых ключей (за некоторыми исключениями) основывается на протоколе Диффи-Хеллмана и состоит из нескольких этапов. Тем не менее, раскрытие сеансовых симметричных ключей и тут приводит к тому, что активный атакующий может подменить трафик, выступив вместо одной из сторон после того, как соединение установлено.

Наберём в консоли (в терминале) ping 010.010.010.010 и запустим выполнение – что произойдёт? Результат теперь многим и многим, – далеко не пользователям, а даже системным администраторам, – кажется неожиданным: “пинги” отправляются на один из адресов Google – 8.8.8.8. Проверьте самостоятельно (в экзотических ОС результат может отличаться, но в привычных линуксах, например, – всё вполне корректно, а экзотические ОС ещё предстоит подобрать).

Почему так вышло? Потому что старое системное соглашение, о котором нынче забывают, гласит: если запись октета IP-адреса (здесь – четвёртой версии) начинается с символа нуля и не содержит, следом, буквы, то это запись в восьмеричной системе! (Относится, конечно, не только к ping и не только к IP-адресам.) 10 в восьмеричной системе – это восемь, так что: 8.8.8.8. Неплохо взглянуть и на другие варианты: ping 010.8.010.8, например. А попытка вызвать ping 010.080.010.010 приведёт, скорее всего, к сообщению о том, что адрес для имени обнаружить не удалось (или Name or service not known – в типичном случае).

А оговорка насчёт буквы в предыдущем параграфе, конечно, это для 0x08, например. Но такая запись мало кого вводит в заблуждение.

В ТЦИ запущен сервис просмотра данных российских логов Certificate Transparency. На сервере используется TLS-сертификат, выпущенный ЦС ТЦИ. Соответствующий корневой сертификат ECDSA можно взять на сайте ЦС (SHA-1: 4E877AC027A63D8514C0B4CBFA0F6F58F6C17696).

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

(Это, собственно, версия известного сервиса crt.sh, но с поддержкой только российских логов – в crt.sh они не учитываются автоматически.) Самое простое применение – поиск (пре)сертификатов TLS по доменному имени (см. скриншот для livejournal.com ниже).

Кстати, о трафике на веб-узлах. Я поддерживаю тестовый сервер 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.