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

Официальная новость ТЦИ про добавление определения X25519Kyber768 на audit.statdom.ru (САБИУ). Цитата:

На серверной стороне поддержка реализована, например, на узлах Google и веб-фронтендах Cloudflare, одного из крупнейших мировых провайдеров веб-доступа. То есть существенная часть веб-трафика в Интернете уже защищена с помощью данной криптосистемы.

Вообще, этот момент почему-то сейчас упускают из виду: может, оно и прошло незаметно, но сейчас, если вы используете Google или Youtube через более или менее современный браузер из распространённых, TLS-трафик уже защищён при помощи ключей, полученных с использованием Kyber768 – то есть, постквантовой криптосистемы. А если сюда добавить, что очень многие мало-мальски популярные сайты используют Cloudflare, – в том числе, в Рунете этот сервис очень распространён, – то окажется, что немалая часть обычного TLS-трафика в Вебе, – точно больше трети, – уже перешла, так сказать, на “постквантовые ключи”. А момент довольно интересный, но почему-то про него не особо-то пишут даже технические СМИ.

(Кстати, по наличию поддержки на стороне сервера можно, – примерно, – судить, у кого насколько “свой” TLS-бэкенд. Тоже занимательно.)

Оказывается, многие жалуются на набеги ботов, – особенно, на тот самый ClaudeBot, – при помощи которых очередные AI-компании копируют доступный чужой веб-контент в свои синонимайзеры, чтобы потом использовать в своих целях на собственных информационных ресурсах (что, вообще-то, совсем не ново, но раньше иногда ссылки ставили и, хотя бы, не прикрывали такую деятельность “искусственным интеллектом”). На dxdt.ru трафик вообще минимальный, но от этого периодические массовые опросы, выполняемые AI-ботами, только заметнее. Странно, что они нередко запрашивают одни и те же страницы через минимальные промежутки времени, но с разных IP-адресов. Конкретно для ClaudeBot я, в порядке эксперимента, даже сделал специальную заглушку с редиректом и последующим кодом статуса HTTP 503 – вроде, это помогло.

Для OpenSSL переделали сайт, почему-то потеряв старые ссылки (например, блог, что не очень-то удобно). Зато добавлены Bouncy Castle и Cryptlib.

Однако главную часть новой основной страницы под openssl.org занимает текст “Миссия”, рассказывающий о доступности инструментария “для всех”, но если с данной страницы, прямо под текстом “Миссия”, кликнуть на большую кнопку-ссылку Cryptlib, то тут же окажется, что там доступ для российских IP-адресов заблокирован: “403 Forbidden” – говорит тамошний веб-сервер.

Практический пример того, как автоматизация процессов работы с исходным кодом и репозиториями (читать нужно: CI/CD) может легко и неожиданно “выйти боком”: токен с правами полного доступа к репозиториям Python и PyPI на GitHub долгое время находился в открытом доступе.

Разбор инцидента из первых рук позволяет понять, как так вышло: наружу отправился локальный файл .pyc, случайно оставшийся в локальной (общей для процесса сборки) директории, которая требовалась для работы приложения в Docker-контейнере; ну и не менее случайно – в этом .pyc-файле сохранился токен доступа.

Google убирает из Chrome доверие оконечным сертификатам, выпущенным Entrust/AffirmTrust, начиная с 1 ноября 2024 года.

Интересно, что, как написано, реализуется это всё по SCT-меткам в сертификатах: то есть, не важно, какие ещё параметры указаны в самом сертификате, учитываются только метки времени в SCT, выданных логами Certificate Transparency (такие метки от доверенных логов должны входить в состав сертификата, иначе он тоже будет считаться недоверенным). Очередная иллюстрация того, насколько процесс валидации серверного сертификата в браузере может отличаться от “обычной реализации”.

Сообщают про неожиданную замену кода JS-библиотеки Polyfill.io после смены администратора домена или администратора веб-сервера, раздающего код (насколько можно понять). Библиотека используется в качестве внешнего ресурса на многих сайтах, а в результате изменения кода некоторые браузеры пользователей перенаправляются на сторонние сайты. Это происходит без ведома веб-мастера, понятно, который может ничего и не замечать, поскольку для него перенаправлений нет.

Я, например, в 2019 году (но, конечно, и многим раньше) писал про внешние библиотеки на сайтах буквально следующее:

На первый взгляд может показаться, что библиотека выполняет только те функции, ради которых её использовал веб-разработчик. Но это не так: программный код библиотеки может быть изменён владельцем узла, с которого библиотека загружается (либо третьей стороной на пути до клиента), после чего она сможет реализовать какой угодно набор функций, например, собрать пользовательские данные со страницы, изменить её содержание, сделать просмотр недоступным, перенаправить браузер на произвольный адрес и так далее, и тому подобное. В некоторых современных браузерах существует механизм базовой защиты от подмены исходного кода встраиваемых библиотек под названием Subresource Integrity (SRI), но на практике этот механизм ни на каких сайтах не используется.

[…]

Администратор узла, с которого загружается библиотека, волен как угодно вмешиваться в её код. Реально передаваемый клиентскому браузеру файл может выбираться индивидуально, другими словами, атака, связанная с подменой библиотеки, может быть точно настроена на:

конкретные IP-адреса (т.е. конкретных пользователей);
конкретные типы браузеров;
определённое время;
любую комбинацию этих настроек.

То есть даже если администратор исходного веб-ресурса, test.ru в нашем примере, пытается как-то отследить корректность работы узлов, на которых находятся используемые библиотеки, он не в состоянии этого сделать: для IP-адресов, с которых проводится проверка, всё может работать корректно, при этом для других посетителей сайта картина окажется совсем другой.

(Отмечу, в скобках, что хотя бы SRI сейчас начали иногда использовать, но внедрение SRI – всё равно редкий случай.)

В продолжение предыдущей записки, про имена и TLS на веб-серверах, – хороший практический пример. Веб-сервер Nginx использует, обычно, OpenSSL в качестве библиотеки, реализующей TLS. Из-за особенностей кода и библиотечных вызовов, данный веб-сервер не может применять ограничения по версиям TLS для виртуальных хостов, сконфигурированных по SNI в блоках server. Это буквально происходит потому, что не согласованы области видимости имён и статусы TLS-соединения. Другими словами: для того, чтобы начать сопоставлять описания TLS-конфигураций из блоков server, Nginx должен знать имя хоста, по которому выбирается блок. Данное имя передаётся в ClientHello (SNI). Однако к моменту, когда Nginx это имя получает через соответствующий (обратный) вызов функции, в OpenSSL уже создан контекст с поддерживаемой версией TLS – ведь эта версия и выбирается по ClientHello.

Что это означает? Например, означает, что с именами в TLS нужно тщательно всё проверить. Так, если TLS-клиент (браузер) приходит с указанием поддерживаемой версии TLS 1.3 и такая версия указана для сервера по умолчанию, то отключить эту версию директивами ssl_protocol для прочих виртуальных хостов не выйдет – будет согласовываться TLS 1.3, а если согласовать 1.3 не получится, то возникнет ошибка. При этом сама директива ssl_protocol допускается в блоке server, однако в документации её низкая избирательность и, таким образом, относительная бесполезность, тоже отражены: указывать ssl_protocol нужно только для сервера по умолчанию (default/default_server).

Предположим, что для сервера Nginx указана полезная опция ssl_reject_handshake в блоке виртуального хоста по умолчанию (default_server). Это предотвращает успешные TLS-подключения с неверными именами. Соответственно, если в такой конфигурации попытаться указать для прочих виртуальных хостов какие-то иные наборы допустимых версий TLS в ssl_protocol, то применяться они не будут: сервер всегда раньше упрётся в default_server, хоть для этого варианта и прямо указана отмена TLS-хендшейка, не указано никаких уникальных имён хостов и, предположим, даже, – как обычно, – не указана директива ssl_protocol, которая будет инициализирована значениями по умолчанию. Это, конечно, выглядит не слишком логично, но происходит потому, что данный веб-сервер и не пытается обрабатывать имена из контекста TLS-сессии, “выгружая” задачу в сторону TLS-библиотеки (OpenSSL – см. выше).

Вернёмся к конкретной версии TLS – к 1.3. Если при наличии default_server с ssl_reject_handshake в конфигурации присутствуют виртуальные хосты, для которых поддержка 1.3 невозможна (например, с ГОСТ-TLS без совместимых шифронаборов), то, даже если в блоке server для этих имён прямо указаны только версии ниже 1.3, всё равно возникнет довольно занимательная проблема: некоторые клиенты-браузеры смогут подключаться к серверу по проблемному имени хоста, а некоторые – нет. Потому что с клиентом, который заявляет в ClientHello поддержку 1.3, сервер всё равно будет пытаться установить соединение 1.3 и, определив недоступность этой версии, возвратит ошибку (Alert в терминах TLS). А с клиентом, который 1.3 не заявляет, соединение будет успешно и без всяких проблем устанавливаться по версии 1.2 (например). Всё по причине игнорирования блока ssl_protocol веб-сервером. Решением является отключение 1.3 для сервера по умолчанию, то есть – для всех имён хостов сразу.

В TLS для веба важны имена. Например, при подключении по TLS для HTTPS серверу нужно отправить клиенту TLS-сертификат сервера. Если серверных сертификатов несколько, то сервер должен как-то выбрать подходящий по имени. Тут речь не про промежуточные сертификаты, которые добавляются в набор (bundle), а именно про оконечные сертификаты. Если TLS-cертификат не соответствует имени, которое ожидает клиент-браузер, то сессия не будет корректной на стороне клиента. Данный момент, вместе с желанием держать много виртуальных хостов на одном IP-адресе и под одним веб-сервером, является постоянным источником ошибок администрирования.

Посмотрим, что вообще происходит в ходе обработки HTTPS-сеанса и как сервер может определить соответствие имён. В начале TLS-сессии клиент (браузер) обычно передаёт имя сервера в специальном блоке данных – SNI (Server Name Indication). Сервер видит это имя и может использовать его для поиска нужного сертификата и нужного виртуального хоста. Однако клиент определяет имя из своих собственных соображений.

Типовой вариант: в контекст TLS-сессии имя узла SNI приходит из запроса пользователя через DNS. Почему “через DNS”? Потому что браузер должен был найти IP-адрес, к которому он подключается по TCP. При прочих равных, браузер получил IP-адрес из DNS по имени хоста из URL, заданного пользователем. Это действительно важный момент, который, почему-то, инженеры DevOps регулярно выкидывают из области рассмотрения, посчитав “элементарным”. Однако, во-первых, если пользователь ввёл имя, которое не удалось “разрезолвить” в IP-адрес, то и штатного TLS-соединения не случится, хоть бы такое имя и было указано в сертификате (такое вполне возможно). Это, предположим, “элементарная часть”, которая, тем не менее, никак не отменяет возможности указания в SNI имени без DNS-адреса, то есть, без A-, AAAA-записей. Во-вторых, кто угодно может настроить какое угодно допустимое DNS-имя так, чтобы оно показывало на заданный IP-адрес сервера, а потом отправить ссылки с этими именем хоста ничего не подозревающим пользователям. В этом случае, пользователь, штатно набрав это самое “какое угодно” имя хоста, успешно направит браузер на заданный сервер, но браузер обратится туда с “неожиданным” именем в SNI. Если это имя вдруг совпадёт с указанным в предоставленном по умолчанию валидном TLS-сертификате с успешным подтверждением, то браузер даже не выдаст предупреждения, а в сертификате может быть очень много разных имён. (Но, во многих случаях, можно смело считать валидный серверный TLS-сертификат с верным именем достаточной мерой защиты от “ложных” хостов для HTTPS. Особенно, если веб-сервер основного имени хоста доступен по выделенному IP-адресу.)

Основной вывод предыдущего абзаца такой: сервер ориентируется на SNI, но нельзя считать, что SNI, присланное клиентом, как-то привязано к серверным настройкам, соответствует DNS, “защищено сертификатом” и вообще укладывается в формат и ожидания, отражённые в конфигурационном файле веб-сервера. И SNI вообще может отсутствовать. (Кроме того, тут не рассматривается случай, когда данные SNI скрываются от третьей стороны – метод ECH и пр.) На стороне веб-сервера бывает возможность отклонить TLS-соединение, использующее “неожиданное” имя хоста.

На начальном этапе соединения, до получения HTTP-запроса, сервер видит только имя из сеанса TLS. Но это не означает, что и сами HTTP-запросы будут адресованы этому же имени хоста – в HTTP-запрос тоже можно вписать что угодно, TLS никак семантику HTTP не фиксирует. Конечно, ситуация не является типичной для браузеров, но она вполне возможна. Это тоже нужно учитывать при обработке разных внутренних переменных на серверной стороне: контекст TLS, контекст HTTP – разные контексты.

Как ни странно, но продолжает развиваться тестовый сервер TLS 1.3 – добавил поддержку ещё пары гибридных криптосистем с постквантовой стойкостью: P256Kyber768 и P384Kyber768. До этого сервер поддерживал только X25519Kyber768, которая есть в Chrome/Chromium (и на веб-серверах Google, например). Два новых варианта – совсем редкие.

Удивительно, но P384Kyber768, тем не менее, заявлена в свежих версиях браузера Microsoft Edge под Windows, где включение данной криптосистемы спрятано за флаг (chrome://flags). Да, Edge построен на базе Chrome/Chromium, однако в TLS-стеке там есть дополнительная постквантовая криптосистема. При этом, у P384Kyber768 пока нет индекса в реестре IANA, а у ещё более редкой, в плане поддержки, P256Kyber768 (то же самое, но кривая P-256) – индекс (0x639A) уже имеется.

Вообще, гибридные P256Kyber768 и P384Kyber768 устроены аналогично X25519Kyber768: тут часть Kyber768 вообще совпадает, а в качестве присоединяемого протокола Диффи-Хеллмана (DH) выступают, вместо X25519, ECDH/P-256 и ECDH/P-384.

На сервере я попутно исправил старую ошибку с обработкой точек кривой P-521, из-за которой поддержка DH на этой кривой была давно выключена (это не связано с постквантовыми криптосистемами). Теперь она снова включена – такую версию ECDH использует Firefox.

Изменена обработка TLS-записей, составляющих ответ. Теперь веб-страница с сервера, в большинстве случаев, приходит в нескольких TLS-записях. Это довольно занятный момент: из-за использования постквантовых криптосистем, HTML-ответ, в котором перечисляются ключи и сообщения, теперь может быть довольно большим. Представьте, что клиент приходит с заявленной поддержкой X25519Kyber768 и P384Kyber768, при этом сразу присылает ключи в X25519Kyber768 (1216 байтов). Однако сервер предлагает перейти к P384Kyber768, отправляя HelloRetryRequest, после чего клиент присылает уже ключи P384Kyber768 (ещё 1249 байтов). Всё это должно отразиться в результатах на странице. Чтобы, так сказать, выровнять результаты с постквантовыми криптосистемами и без них – я уменьшил максимальную используемую длину TLS-записи.

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

Google уже некоторое время назад для многих пользователей заменил поисковую выдачу на результаты некоторой системы ИИ (LLM), которая генерирует ответы на запрос, “синонимизируя” собранные в интернетах тексты. Не слишком довольные нововведением пользователи извлекли из новой системы массу неверных, абсурдных ответов. И из Google опубликовали разъяснение, что пользователи не совсем правы. В этом разъяснении, на примере запроса “How many rocks should I eat?” (“Сколько камней мне следует есть?”), объясняют, что причина абсурдных, неверных ответов в том, что, во-первых, это редкий запрос (!), во-вторых – для такого запроса в вебе опубликовано мало релевантных данных (да):

Prior to these screenshots going viral, practically no one asked Google that question. […]

There isn’t much web content that seriously contemplates that question, either. This is what is often called a “data void” or “information gap,” where there’s a limited amount of high quality content about a topic.

(До того, как эти скриншоты [т.е., с ответом ИИ про рекомендуемое к ежедневному поеданию количество камней] стали “вирусными”, практически никто не задавал Google такой вопрос. Кроме того, в вебе не много контента, который серьёзно рассматривает такой вопрос. Это то, что часто называют “лакуной в данных” или “информационным пробелом”, когда имеется ограниченное количество тематического контента высокого качества.)

Казалось бы, “интеллект” – он на то и “интеллект”, – тем более, в сервисе поиска информации, – что должен выдать ответ о наличии тут той самой лакуны (“data void” – называть можно так, или иначе, но смысл один), предупредить, что данные в вебе не позволяют судить о данном вопросе “со всей серьёзностью”. Но нет: ИИ LLM – не для этого.

Docker Hub заблокировал доступ с российских IP-адресов. Последовало множество насмешливых инструкций в стиле “простейшего перехода на зеркала и прокси”. Проблема тут, впрочем, привычная: в практике Docker, в сопутствующих скриптовых обвязках (всякий CI/CD), и так не всё хорошо с аутентификацией источников сборок и самих “контейнеров”. Методы, типа DCT (Docker Content Trust), конечно, есть, это известно. Вопрос в их эффективности и использовании на практике. А прокси и “разбегание” зеркал – тут только добавляют ненадёжных слоёв. Кстати, целевые манипуляции часто удобнее проводить именно с точками выхода прокси и точками входа зеркал (вспомните, как работает разное перемешивание и, скажем, onion routing – тут ситуация обратная).

(Update, 09/06/24: доступ вернули через несколько дней.)