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

На сервисе ТЦИ audit.statdom.ru добавлена проверка поддержки криптосистемы X25519Kyber768 на TLS-узлах (HTTPS).

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

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

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

[…]

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

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

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

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

На скриншоте ниже – график частотности слова delves в текстах корпуса 2019 года по версии полезного сервиса Google Ngrams (период: 1800 – 2019 годы, английский язык):

Английское delve означает “копать”, “рыть”, но и “рассматривать” – в значении “тщательно разбирать и изучать предмет, исследовать”. Форма delves здесь специально, это не опечатка – см. ниже.

Вообще, delve – родное для современного английского языка слово, однако редкое даже для классического литературного английского (который существенно отличается и от разговорного, и от “академического” – см. ниже). Тем не менее, в контексте “исследований” delve встречается в комедии Шекспира The Tragedie of Cymbeline: “I cannot delve him to the root”. У Диккенса можно найти в A Tale of Two Cities, но тоже придётся покопаться: “men and women here, to dig and delve”. В общем, слово выразительное (это нормально для английского, который больше аналитический), а для “академического языка”, если только речь не о языкознании, может быть признано слишком выразительным. (Delves – это ещё и фамилия. Нельзя забывать и delve into.)

Вернёмся к графику, на котором, – для delves, – отлично виден рост, но, если обратить внимание на вертикальную шкалу, общая доля не слишком велика. (Оси, к сожалению, в Google подписывать не умеют, что, как бы, существенно снижает доверие к результату, тем более, что не подписывают не только оси, но и шкалы, да и сами графики; всё же, воспользуемся этим вариантом.)

Выбор слова и вся эта предыстория могут показаться странными, – пусть и позволяют поставить тег “Лингвистика“, – однако в свежей научной работе (препринт [*]) по пикам на графиках частотности слов определяют влияние ChatGPT и прочих LLM на текстовый состав аннотаций научных (опять же) работ. И delves там используется непосредственно, см. второй скриншот:

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

В работе исследована статистика слов из аннотаций (“абстрактов”) научных публикаций PubMed – около 14 млн “абстрактов” за период с 2010 по 2024 год (представьте, кстати, сколько научных работ публикуется ежегодно; и это ещё LLM только начали разворачиваться). Выделены “резкие скачки” на графиках по некоторым словам, что связывается с влиянием использования ChatGPT и других LLM, которые могли быть задействованы при подготовке текстов. Действительно, LLM, являясь синонимайзерами переростками, выводят редкие слова в генерируемый текст, часто – невпопад. Но вот почему может быть верным обратное утверждение, – что “выбросы” редких слов в аннотациях свидетельствуют о “вмешательстве” LLM, – из исходной работы не очень понятно (кроме, конечно, указания на странное совпадение по времени). Предположим, кто-то из авторов прочих публикаций использовал новое слово в статье. Другие авторы, которым слово понравилось, тоже стали его использовать. На графике Google (с неподписанными осями) delves резко растёт ещё с 1981 года – свидетельствует ли это о возвращении дополнительных произведений Диккенса в школьную программу (в Англии, конечно)? Не факт, но всякое может совпасть по времени. Естественно, корпус сервиса Google Ngrams отличается от выборки PubMed, это тоже понятно.

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

Необходимо, впрочем, признать, что авторам исходной работы совсем не чужд профильный юмор. Цитата:

We hope that future work will meticulously delve into tracking LLM usage more accurately and assess which policy changes are crucial to tackle the intricate challenges posed by the rise of LLMs in scientific publishing.
(Смысла переводить нет, потому что это, очевидно, аллюзия к общей теме работы: “meticulously delve”, “tackle the intricate challenges” и др.)

[*] Dmitry Kobak, Rita González Márquez, Emőke-Ágnes Horvát, Jan Lause;
Delving into ChatGPT usage in academic writing through excess vocabulary
arXiv:2406.07016

Если (вдруг) появился универсальный “квантовый компьютер” нужной мощности, то как именно будут выглядеть технические шаги по раскрытию ранее записанного TLS-трафика? Под “квантовым компьютером” здесь подразумевается аппарат, выполняющий алгоритм Шора. А в роли взламываемой криптосистемы выступает алгоритм Диффи-Хеллмана на эллиптической кривой (ECDH – типовой алгоритм для современного состояния TLS). Шаги потребуются следующие.

1.

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

Из начального сообщения клиента выделяется блок с открытой частью клиентского обмена ECDH. Например, если используется ECDH на кривой P-256, то в специальном и легко обнаруживаемом блоке данных будет содержаться пара координат точки P на кривой P-256, представляющей собой открытую часть обмена ECDH. Это 64 байта (плюс дополнительные байты с указанием на используемый формат), то есть, два блока по 32 байта: координаты X и Y.

2.

Клиентская часть ECDH представляет собой результат умножения базовой точки на секретный скаляр – значение скаляра и есть секретная часть ECDH клиента: это натуральное число n. Открытая часть ECDH, точка P, это результат [n]G, где G – точка-генератор, заданная в параметрах криптосистемы.

Полученные координаты точки P “загружаются” в квантовый компьютер, который уже должен быть настроен на параметры соответствующей криптосистемы, то есть, содержать схему, реализующую алгоритм Шора (нахождения периода функции) для подгруппы кривой P-256, образованной точкой G. Как именно загружаются значения в квантовый компьютер – пока что не известно, поскольку никаких практических квантовых компьютеров создано пока что не было (ну или, если хотите, не было опубликовано их содержательных описаний). Вероятно, у этого компьютера должен быть некоторый классический интерфейс, воспринимающий значения байтов координат точек, и переходные схемы, которые преобразуют эти значения в коммутацию и состояния квантовых “гейтов/триггеров” и кубитов. Неизвестно даже, сколько этих “кубитов и гейтов” будет нужно: несколько миллионов или несколько триллионов. Что уж там говорить про схемы коммутации.

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

После того, как квантовый компьютер настроен, запускается итерация квантовых вычислений. Если итерация успешна, то результат позволяет быстро вычислить n на классическом компьютере. Использование классического компьютера тут означает, что у компьютера квантового, – а он, даже если создан, то бесполезен без классического, – есть и другой интерфейс, который выводит итоговое измеренное состояние квантовых схем в виде набора байтов, интерпретируемого как целое число. В случае с ECDH это будет пара чисел, по которым классический компьютер быстро вычислит секретный клиентский параметр n.

Аналогичная схема сработает и для открытого параметра ECDH, который отправил сервер. Для раскрытия ключей защиты трафика – достаточно знать один из секретов: клиентский или серверный.

3.

Общий секрет в ECDH образуется путём умножения точки-генератора на произведение секретов сторон. В рассмотренном только что случае, достаточно умножить открытый параметр DH сервера Q на секрет клиента, вот так: [n]Q (именно эту операцию проделывает клиент в ходе штатного процесса установления TLS-соединения). Секрет клиента, как мы только что выяснили, был раскрыт при помощи квантового компьютера. Результат умножения даёт точку на кривой, координата X которой используется в качестве задающего значения для генерирования секретных симметричных сеансовых ключей защиты трафика TLS. Функция, генерирующая сеансовые ключи, известна. Так как защищённые записи содержат коды аутентификации, сторона, взломавшая секрет ECDH, может тут же легко проверить, что найденный секрет соответствует записанному трафику. Симметричные ключи позволяют расшифровать трафик сеанса, используя шифр, номер которого тоже записан в начальных сообщениях: эти сообщения как раз и нужны для того, чтобы, кроме прочего, стороны согласовали используемый шифр.

*

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

Официальные сопроводительные документы, касающиеся запрета продуктов “Лаборатории Касперского” в Штатах, уже доступны (на странице по ссылке – блок внизу, справа). Однако все моменты, которые могли бы оказаться минимально интересными с технической точки зрения (Appendix A) – аккуратно вырезаны (с пометкой “Business Confidential Information”). Поэтому ничего содержательно нового там всё равно не просматривается, но тенденция – показательная.

(Дополнение: о чём-то, типа предполагаемой “сборки из исходников”, можно догадаться по контексту, но, всё же, это было и так понятно.)

Сайт новой 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.)