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

Ещё о пресертификатах в Certificate Transparency (CT) и странных “свойствах”, которые возникают вокруг. TLS-сертификаты превращаются в пресертификаты после того, как добавлено специальное расширение Poison. Может показаться, что с этим расширением тоже связана проблема “курицы и яйца”, поскольку нарушать процесс валидации poison-расширение должно потому, что оно помечено как Critical (критическое), но имеет тип, неизвестный валидатору – неизвестные критические типы, согласно рекомендациям, должны приводить к тому, что сертификат считается невалидным (а вот расширения неизвестного типа, которые не помечены как критические, можно игнорировать). Если же валидатор знает тип poison-расширения, то флаг Critical уже не должен препятствовать валидации. Это так, однако проблемы тут нет: в том случае, когда валидатор распознал poison-расширение, он не должен принимать сертификат на правах валидного, так как, грубо говоря, видит, что это пресертификат (ну или можно интерпретировать иначе: наличие poison-расширения означает, что сертификат не должен использоваться так же, как и сертификат без Poison). В общем, всё же появляется неплохой шанс выстроить однозначный процесс валидации.

С пресертификатами связано множество весьма неочевидных аспектов. Так, единственный смысл в пресертификатах – это создание “костыля” для получения метки времени от сервиса CT-лога, чтобы включить эту метку в сертификат. Метка (она называется SCT) связана с конкретным пресертификатом и подписывается лог-сервисом. Но включается метка уже в сертификат, который от пресертификата отличается в некоторых деталях. Напрмер, сертификат не должен содержать poison-расширение. При валидации сертификата проверяется и SCT-метка (ну, если валидирующая сторона, – скажем, браузер, – хочет проверить метку). Понятно, что если подпись вычислена для другого набора данных (пресертификат), то она не сойдётся. Как же устроены процессы подписывания и проверки подписи SCT-метки? Они устроены непросто.

При вычислении подписи для пресертификата сервис CT-лога использует в качестве входных данных не весь сертификат, а только его “содержательную часть” (некоторое зафиксированное в структуре подмножество полей), из которой, к тому же, удаляется poison-расширение. Это, что называется, первый “сюрприз”: poison-расширение должно присутствовать в составе поступающего пресертификата не только потому, что оно и делает сертификат пресертификатом, но и потому, что иначе не сойдётся подпись УЦ на пресертификате, а подпись должен проверить сервис лога. Дописать какие-то данные в сертификат не выйдет. Однако поскольку в сертификате Poison удаляется, то и подпись в SCT нужна на данных без poison-расширения. Второй “сюрприз”: при проверке подписи SCT в сертификате – нужно восстановить содержательную часть пресертификата в точно таком виде, какой передавался в сервис CT-лога, но с учётом удаления Poison – то есть, нужно удалить “лишние” расширения (SCT-метки), а те расширения, которые останутся, должны совпасть с конфигурацией пресертифката. А поскольку такое преобразование снова удаляет из состава сертификата значение подписи, к данным сертификата, перед проверкой, вместе с другими служебными параметрами SCT, нужно присоединить отпечаток открытого ключа УЦ. Понятно, что то же самое делается и на стороне CT-лога, при формировании SCT. Так что общий алгоритм местами “макаронный”, но, тем не менее, используется. Не удивительно, что в новой версии CT пресертификатов нет.

Омоглифы – это символы, совпадающие по начертанию, но различные по значению (интерпретации). Например, Н, H и Η, а именно – заглавная кириллическая “н”, заглавная “h” английского алфавита и заглавная “η” греческого алфавита. Пришлось тут столкнуться с забавной “программной” интерпретацией данного явления. Пакет Gitea (это пакет для работы с исходным кодом в git, с веб-интерфейсом и прочими полезными функциями) при попытке посмотреть некий русскоязычный текстовый файл из репозитория на сервере – показывал мне в браузере предупреждение, что “This file contains ambiguous Unicode characters!” (“Этот файл содержит “неоднозначные” символы Unicode!”). И действительно, встроенный фильтр подсвечивал буквы вроде “a”, “T” и “о”, но не во всех случаях. Так, целиком подсвечивалось сочетание букв “То” из “То есть”. А в другом месте этого же текста подсвечивалась одинокая буква “а”, при помощи которой обозначался союз “а”.

Сперва показалось, что это действительно в текст прокрались “омоглифы”. Такое случается, особенно, когда используешь несколько раскладок клавиатуры: английская “C” прокрадывается и занимает место “С”, предположим. Однако попытка исправить эти буквы в исходном файле и отправить изменения к успеху не привела: выяснилось, что ничего-то там не меняется – буквы уже использованы кириллические, в файле всё записано верными буквами. Хитрость оказалась в том, что пакет Gitea, руководствуясь настройками “локали” в браузере (а у меня использовалась англоязычная), самостоятельно делал вывод, что данного пользователя могут ввести в заблуждение сочетания кириллических букв, похожие на английские слова, о чём и предупреждал. То есть, “То” в этом “То есть”, выглядит английским “to”, а “а” – неотличима от артикля. В общем, как говорится в тексте, содержащем исходную формулировку знаменитой, – но известной только специалистам, – проблемы Винни-Пуха: “зачем эта хта обязательно та, а жерка, как правило, эта?”. Кто бы мог подумать.

(Уточнение: под “словами” подразумеваются последовательности омоглифов, обособленные пробелами.)

Можно ли в вебе на стороне сервера определить, какой именно версии браузер устанавливает TLS-соединение, в самом начале этого соединения? Например, для того, чтобы выбрать сертификат от подходящего УЦ (см. ниже). Хитрость в том, что привычный способ, когда браузер определяется по HTTP-заголовку User-Agent, тут не подходит: на начальном этапе установления соединения никаких HTTP-заголовков ещё нет, а вот серверный сертификат передавать нужно. И речь не про выбор сертификата на основе перечня поддерживаемых криптосистем, как это делается при настройке параллельной работы ГОСТ-алгоритмов и “обычных” алгоритмов в TLS/HTTPS – эта задача как раз решается весьма просто. Вообще, проблема находится на другом уровне: строго говоря, узнавать нужно даже не столько браузер, сколько конкретную библиотеку, реализующую TLS (так, для Firefox это будет NSS), и конкретный профиль данной библиотеки. Вообще, сделать выбор иногда можно на основе анализа состава TLS-сообщений, но так как набор этих сообщений не велик, а сам перечень может изменяться, то и точность не велика. Тем не менее, конкретная разновидность браузеров могла бы сигналить серверу, что именно такой браузер подключается. Это реализуется через дополнение TLS-сообщений, но внедрение потребует доработки TLS-стека как на стороне сервера, так и на стороне браузера.

А вот что касается именно списка поддерживаемых УЦ, то в TLS уже есть встроенный механизм, в версии 1.3 он так и называется – “certificate_authorities”. Это расширение, которое клиент может включить в состав сообщения ClienHello (начальное сообщение TLS-соединения), а сервер может обработать и – выбрать нужный сертификат, в том числе, для одной и той же криптосистемы. Вот только распространённые браузеры данное расширение не поддерживают, а если бы и поддерживали, то туда пришлось бы вписывать слишком много имён УЦ, так как в типичный дистрибутив браузера их входят многие десятки. Так что доработка, как минимум, браузера – всё равно потребуется.

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

Что же касается реальных технических моментов, то тут можно было бы предложить, что, начиная с некоторого порога сложности, все эти нагромождения взаимосвязей регистров компьютерной памяти входят в соприкосновение с некоторыми непонятными пока что свойствами “окружающего мира”, результатом соприкосновения становится “нечеловеческий интеллект“. Ну, в том случае, если концентрация большого количества значимых бит в небольшом объёме пространства не приведёт к схлопыванию всего массива в одну частицу типа позитрона, как описано в известном фантастическом произведении.

Вообще, соприкосновение с неизвестными свойствами действительно могло бы происходить на уровне электроники, элементы которой должны быть достаточно миниатюрными: с малой пространственной шкалой и электромагнитным взаимодействием может быть связан какой-нибудь неожиданный временной эффект, который проявляется только на очень больших числах взаимосвязей – сами взаимосвязи не обязаны быть “физическими”. Аналогичное рассуждение применимо к аппарату квантовой механики: например, откуда можно узнать, что известные модели действительно работают для пространств состояний порядка 2^1000? А узнать можно, попытавшись построить квантовый компьютер соответствующей разрядности (ну или другую экспериментальную машину, сходную по расчётным свойствам). А в случае больших машинных ИИ на тысячах специализированных процессоров можно было бы ожидать проявления обратных свойств. При этом, если самосознание (self-awareness), – настоящий интеллект, – оказывается принципиально невычислимым (откуда и все “проблемы” с интерпретацией времени), то это вовсе не запрещает нечеловеческий, – но вычислимый “неожиданным образом”, – искусственный “интеллект”, пусть и тоже в кавычках.

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

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

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

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

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

Samsung официально описывает, как некоторые смартфоны этой корпорации дорисовывают изображение Луны “методами машинного обучения” – процесс называется Scene Optimizer. Про это, в общем-то, известно давно. А проблема тут не столько в том, что дорисовывают, а в том, как именно процесс преподносится – “улучшение детализации”. В результате, выдачу подобных камер считают за отражение реальности.

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

Основная особенность этих программных “дорисовывалок”, неограниченно “повышающих разрешение”, такая: они приносят на конкретный снимок результаты, собранные по другим снимкам (из “обучающей выборки”) и приведённые к некоторому заданному, типовому представлению об изображённой сцене (о Луне, в данном случае). Детали в такой схеме как раз не особо и важны – детали уже заранее записаны в память смартфона, а поэтому НЛО он просто закрасит правильным фрагментом лунной поверхности, потому что “компьютер не может ошибаться”. Тенденция эта грозит большими проблемами, так как цифровые снимки, выполненные смартфонами, могут, предположим, использоваться в качестве доказательств тех или иных событий. И даже дорисованная Луна способна повлиять на суждения о времени и месте съёмки, если таковые будут выноситься по изображению. Впрочем, зачем тратить на это время? Ведь в файле же и так записаны “верные” координаты и время GPS.

Я уже писал об этом раньше, например, в 2021 году: “Нейросети из пикселей“.

Наберём в консоли (в терминале) 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, например. Но такая запись мало кого вводит в заблуждение.

Генераторы текстов на заданную тему сейчас вновь популярны. Пример, естественно, ChatGPT. Можно ли автоматическим способом и с высокой точностью определить, что некоторый обозримый текст на естественном языке написан таким качественным компьютерным генератором, а не человеком?

Если эту задачу рассматривать “в максимальной общности”, то она тут же превращается в весьма занятную, почти что философскую, проблему: допуская, что можно надёжно различить тексты, написанные подобной программой и человеком, придётся допустить и то, что программа может выдать текст, который человек написать не смог бы – не смог бы сымитировать. То есть, в тексте, который написал генератор текстов, должно быть проявление некоторого “нечеловеческого интеллекта”.

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

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

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

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

Вообще, эта особенность, с сортировкой массивов, касается всех текстов, представляющих собой обозримые наборы простых фактов. Попробуйте, например, детектировать, человек или автоматический генератор текстов собрал адресный справочник для того или иного района мегаполиса. Особенно, если это вымышленный мегаполис, да. Для подобных результатов, если они, конечно, не слишком объёмные, надёжный детектор невозможен.

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

Предположим, что мы зашифровали некоторый небольшой текст (десяток слов) на естественном языке, используя самый обычный способ – кодирование UTF-8 и какой-нибудь стойкий симметричный шифр, например, AES с 256-битным ключом (32 байта). Но ключ выбран специальным способом: 30 байтов из 32 зафиксированы и известны, а два байта (то есть, 16 бит) выбираются случайно. Потом получившийся шифротекст отправляется в некоторую программу, программа перебирает значения двух “секретных” байтов ключа и пытается расшифровать данные, каждый раз проверяя, получились ли в результате словарные слова в кодировке UTF-8 (если хотите более “криптологический” вариант, то можно брать биграммы/триграммы – это как раз детали, которые здесь не важны). Если получились слова, похожие на ожидаемый язык, то программа считает, что удалось успешно расшифровать данные и выдаёт открытый текст.

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

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

На одном из серверов, certbot, запускаемый по таймеру systemd, неожиданно сумел обновить сертификаты. Почему неожиданно? Потому что, как показало исследование логов, раньше этому certbot-у успешно мешал работающий там же веб-сервис: этот веб-сервис занимает 80/tcp, на который настроен и “респондер ACME/DCV” (проверка права управления доменом) в certbot; так что certbot, вообще-то, не мог штатным образом обновлять сертификаты (упомянутый веб-сервис имеет собственное подобие веб-сервера, которому не ведомо понятие web root, кроме прочего); попытка certbot-а поднять собственный веб-сервер, чтобы ответить на запрос из Let’s Encrypt, наталкивалась на занятость соответствующего интерфейса по нужному номеру порта. И поэтому сертификаты обновлялись совсем другим способом, хоть и через certbot. Но таймер-то продолжал работать. А тут на днях штатный веб-сервис отвалилися, 80/tcp стал доступен и – certbot успел самостоятельно перевыпустить сертификаты. Вот как бывает. Прописывайте, как говорится, параметры в конфигурационные файлы правильно, корректно настраивайте таймеры, это позволит избежать неожиданных проявлений деятельности “искусственного интеллекта”.

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