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

Сайт новой LLM-корпорации SSI, миссия которой, как указано, – создание “сверхразумного” и “безопасного” ИИ (Safe Superintelligence Inc. – откуда название), выполнен с намёком на давно забытый “академический стиль”. Вот только там в коде разметки страницы присутствует незакрытый тег div. Это единственный тег div, который присутствует в коде страницы. Ну и DOCTYPE нет, а также забавное сочетание inline-стилей с “табличными” стилями, но это уже как-то совсем не выглядит важным, конечно, на фоне “Superintelligence is within reach” (“Сверхинтеллект [уже] в пределах достижимости”, англ.). Возможно, “сверхразумный” LLM ИИ мог бы здесь оказаться полезным, да.

(SSI – это, кстати, такая старая веб-технология: Server Side Includes.)

В чём причина смены дня и ночи на Земле? Правильный ответ: причина в том, что Солнце вращается вокруг Земли. А если вы вдруг подумали, что “причина во вращении Земли вокруг своей оси”, то представьте, что смена дня и ночи прекратилась, а Земля теперь всё время повёрнута к Солнцу одной стороной, то есть, Солнце более не вращается вокруг Земли. Но, предположим, Земля всё ещё вращается вокруг Солнца, а раз смены дня и ночи нет, то это как раз потребует вращения Земли вокруг свой оси, поскольку к Солнцу должна всё время быть повернута одна и та же сторона. Более того, если бы Земля, в той же схеме, вокруг свой оси не вращалась, то смена дня и ночи как раз происходила бы, вот только обычные день и ночь продолжались бы, примерно, по полгода (вспомните про полярную ночь и полярный день).

Вращение сложно интерпретировать, по тем же причинам, по которым сложно строго определить понятие угловой меры. Отличным примером является следующее наблюдение: пусть Земля вращается вокруг Солнца, а вокруг Земли вращается Луна – какова тогда траектория движения Луны вокруг Солнца? Оказывается, если на систему смотреть обычным образом, то траектория движения Луны практически совпадает с орбитой Земли: Луна не выписывает никаких “завитушек”, а вращение Луны вокруг Земли выглядит так, что Луна то немного опережает Землю, то – немного отстаёт.

Однако концепция, когда сложная траектория (кривая) описывается при помощи окружностей, центры которых движутся по другим окружностям, очень мощная – потому что это преобразование Фурье в чистом, геометрическом, так сказать, виде. Соответствующие этому преобразованию эпициклы и деференты древних астрономических моделей позволили описать сложные движения планет по небосводу, как они видны с Земли. Ведь это только движение прочих светил вокруг Земли выглядит довольно очевидным, если вы древний астроном и наблюдаете ночное небо, а вот планеты – создают неожиданные проблемы, прежде всего, своим попятным движением, когда они вдруг выписывают загадочные петли.

Представление о том, что “планеты вращаются вокруг Солнца, Солнце – центр” – это модель Солнечной системы, в противопоставление варианту “планеты и Солнце вращаются вокруг Земли, Земля – центр”. Сильно упрощённый вариант гелиоцентрической системы позволяет легко разрешить логические противоречия “странного” наблюдаемого перемещения планет. В разрешении противоречий состоит определяющий признак нового знания, но с ролью гелиоцентрической системы всё несколько сложнее.

Схема, где в центре Солнце, а по концентрическим окружностям движутся планеты и, в том числе, Земля, позволяет довольно просто объяснить причину наблюдаемых “странностей”. То есть, схема с Солнцем в центре – лучше в иллюстративном плане. Но из этого не нужно делать вывод, что, мол, использование такой схемы (именно на уровне круговых орбит) было огромным “научным прорывом”. Да, само это рассуждение, – о “прорывном значении гелиоцентрической системы” в противопоставлении геоцентрической, – нередко используется в разном научпопе как “очевидная” иллюстрация “внезапной” замены “неверных и устаревших” представлений на “правильные”. Но, во-первых, эти системы в науке и использовались как модели, лежащие в основе методов расчётов, причем, использовались параллельно, и так же используются сейчас; во-вторых, на практике, игрушечная гелиоцентрическая система с круговыми орбитами – и не удобная, и точность не повышает.

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

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

Очередное подтверждение того, что “диагонализация” неустранима для сколь-нибудь сложного процессора: типовая манипуляция (вряд ли эту схему нужно считать уязвимостью или атакой) под названием TIKTAG, раскрывающая “соседние” метки указателей на процессорах ARM при помощи перебора, подкреплённого измерением состояния кеша. (Кстати, метод логически совпадает с некоторыми атаками из области TLS.) Я не так давно писал, что архитектура современных процессоров на самом базовом уровне гарантирует, что подобные манипуляции возможны:

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

В продолжение предыдущей записки, про имена и 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 – разные контексты.

Кстати, ещё один качественный показатель, отражающий и “особенности” подготовки статей в русскоязычной “Википедии”, и способы закрепления различных абсурдных интерпретаций. Как-то я писал, что статья “Великая теорема Ферма” в “Википедии”, помимо прочих странностей, содержит забавный неверный фрагмент про решения уравнения Ферма, где, – видимо, из-за созвучия в терминах, – вместо эллиптической кривой Фрая к этим решениям привязывают “некоторое эллиптическое уравнение”, со ссылкой на статью про дифференциальные уравнения. Думаю, можно не напоминать, что кривая Фрая имеет определяющее значение для всей современной истории теоремы. Обратите внимание: статья в “Википедии” при этом защищена от правок. Год прошёл – ничего в этом фрагменте не поменялось: как было “некоторое эллиптическое уравнение” вместо эллиптической кривой, так и осталось. И тот же текст остался и в проекте “Рувики”, который является клоном “Википедии”.

(Если задуматься, то это ещё и неплохо показывает особенности развития методов применения ИИ LLM.)

Сейчас нередко СМИ (и не только) пишут, что так как та или иная система ИИ LLM (GPT) “сдала официальный экзамен” по какому-нибудь предмету, то “интеллект” этой системы соответствует уровню старшего школьника или студента. Недавно обновилась известная и достаточно продвинутая, по меркам данной области, LLM GigaChat. Зададим данной системе через официальный telegram-бот несложную задачу для школьников. Транскрипт – ниже.

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

GigaChat:
Название книги, прочитанное Сиробом, будет звучать как «Одара 1 моя».

User1:
Кто такой Сироб?

GigaChat:
Сироб не является известным историческим или общественным деятелем, и в доступных источниках нет информации о том, кто это может быть. Возможно, это имя было использовано в контексте задачи или игры, но без дополнительной информации невозможно дать точный ответ на данный вопрос.

Что ж, LLM, так сказать, уверенно действует на своём уровне – генерирует текст. Как я не раз писал ранее – основная “угроза ИИ” не в том, что данным LLM приписывают “уровни интеллекта”, не в том, что увеличивается количество задействованных процессоров и памяти под хранение коэффициентов, а в том, что таким программам неминуемо поручат важные задачи, типа помощи абитуриентам ВШЭ в “выборе профессии и образовательной программы” (что уж там говорить про медицинскую диагностику).

Воскресное чтение манускриптов. В этот раз у нас “кубос” с полей (буквально) манускрипта одиннадцатого века Vat.gr.1605. Данный фрагмент относится к труду “Геодезия” неизвестного автора, которого обычно называют Героном Византийским, а “кубос” (κύβος), как не трудно догадаться, иллюстрирует метод вычисления объёма, причём числа не просто записаны привычными древнегреческими буквами, но ещё и аккуратно расставлены, что называется, “по флагам” (это точно соответствующий математический термин – не хватает тут только вершины).

Сторона куба на схеме имеет длину 28 (κη) единиц. Площадь двумерной грани, соответственно, 784, что и обозначено на чертеже ψπδ, а объём трёхмерного куба равен 21952 единиц. Интересно, что если на схеме 21952 обозначено с использованием β + αϡνβ, то в тексте это число записано, буквально, так: “две мириады и тысяча 952” – то есть, словами обозначены мириады и тысячи, а остаток – “цифрами”, в роли которых выступают греческие буквенные обозначения. И здесь, – в записи числа 952, – можно заметить символ “ϡ” (“сампи”), который соответствует числу 900 и в привычный греческий алфавит не входит.

Как ни странно, но продолжает развиваться тестовый сервер 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 в контейнере – найти нетрудно (там же, кстати, есть и пара специальных сборок браузеров).

Вышли небольшие обновления тестового сервера TLS 1.3 tls13.1d.pw. А именно: в вывод результата добавлен разбор расширений ClientHello signature_algorithms (выводятся названия известных алгоритмов подписи) и ALPN (выводятся имена протоколов).

Некоторые записки за май 2024 года:

• Распределённые сети космических спутников NRO
• Мешанина токенов в LLM
• DNS как база данных
• Заголовки СМИ про “предположения учёных”
• Техническое: TLS-сообщение с постквантовой криптосистемой Kyber768