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

Немного поправил внутренний код и 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 – подтверждения подлинности адресной информации.

Выпустил ежегодное обновление технического описания протокола 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-цепочка.

Поскольку добывать платные долгоживушие сертификаты от “хорошо известных УЦ”, корни которых есть в браузерах, стало очень неудобно, да ещё и по совсем неадекватным ценам (это связано с общим современным состоянием интернетов и, в частности, применимо к российским пользователям и доменам внутри .RU), поменял сертификат dxdt.ru на Let’s Encrypt. В этом бесплатном УЦ пока что .RU не заблокировали. Не факт, конечно, что это надолго (не заблокировано), но там и сертификаты-то по три месяца. Кстати, довольно занятно будет, когда сертификаты .RU перестанет выдавать и Let’s Encrypt – почти вся зона .RU, в смысле веб-серверов, использует сертификаты именно этого УЦ.

При переходе на Let’s Encrypt удалось даже без проблем применить особый ключ ECDSA, который я специально подобрал (запись открытого ключа содержит некоторую hexspeak-подстроку в самом начале; если вы, вдруг, интересуетесь экзотической занимательной арифметикой на эллиптических кривых и умеете смотреть серверные ключи TLS-сертификатов (это несложно сделать браузером), то обратите, как говорится, внимание). Но всю цепочку в ECDSA Let’s Encrypt делать отказался – этим пришлось пожертвовать.

(Заметка первоначально опубликована в Facebook, 19/05/2020.) Я вот так устроил, что один сервис, проверяющий TLS, использует специально сконструированное сообщение ClientHello TLS 1.3 (см. скриншот) с посланиями внутри. Небольшая хитрость состоит в том, что там не только поля SessionID и ClientRandom с сообщениями, но и ключ для Диффи-Хеллмана (ECDH) на кривой P-256 – с посланием. Ключ – это два числа, но они должны задавать точку кривой, и хорошие реализации TLS проверяют, что ключ принадлежит кривой. Конечно, вычисление второй координаты Y по известной X-координате – никакой проблемы не составляет, но пришлось урезать пару символов, так как число приводится по порядку базового поля. У тех, кто знаком с ECDH, сразу возникнет вопрос – решил ли я попутно задачу дискретного логарифмирования для P-256? Но нет (а если бы решил, то сообщил бы об этом более занятным способом). Дело в том, что реально в этом сканере общий секрет не нужен, поэтому ответный ключ сервера просто игнорируется. (Конечно, вряд ли кто-то ещё это всё видит в трафике. Но при отладке – помогает.)