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

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

(Надо заметить, что Google, в сходном “порыве монетизации”, старые аккаунты GoogleApps, которые идут ещё с какой-то там “закрытой бета-версии”, всё же пока оставил бесплатными – по крайней мере, в моём случае. Не ясно, конечно, останется ли оно так и дальше.)

Надо заметить, что на экспериментальном сервере TLS подключений с постквантовой криптосистемой Kyber768 – пока что единицы, очень мало. Что, в общем-то, понятно: в различных распространённых утилитах эта криптосистема ещё не поддерживается (как минимум, нужно пересобирать с самой современной версией библиотек типа BoringSSL, потому что в OpenSSL пока что поддержки нет), и даже в браузере Chrome нужно отдельно переключать флаг, чтобы X25519Kyber768 заработала. Посмотрим, что будет, когда (и если) в Chrome поддержка станет доступной по умолчанию.

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

Переделал вывод открытого ключа Kyber768 на экспериментальном TLS-сервере – см. скриншот ниже. Открытый ключ Kyber768 состоит из трёх полиномов (256 коэффициентов, которые превращаются в 384 байта для каждого полинома) и дополнительного параметра в 32 байта (в выдаче сервера он называется Rho). То есть, ключ существенно отличается по представлению, например, от RSA, где открытый ключ можно представить как пару натуральных чисел, одно из которых большое (модуль), или от ECDSA, где открытый ключ – точка на кривой, а поэтому его можно представить как пару натуральных чисел, а если в “сжатом” виде, то как одно. Здесь речь о том, как максимально близко к математическим свойствам вывести значения ключей, так-то понятно, что в этой области всё можно отобразить в виде натурального числа (или в виде полинома, кому как нравится). В принципе, полиномы Kyber768 можно было бы распаковать и отобразить так, чтобы они и выглядели как полиномы, но тогда получится совсем уж мешанина на странице.

Продолжаем небольшую серию записок про TLS-сервер на tls13.1d.pw. Этот сервер передаёт несколько сертификатов, в том числе и один необычный сертификат, увидеть который можно только в выдаче той или иной специальной утилиты (например, s_client из OpenSSL) или упомянутым сервисом SSLLabs. Этот сертификат сервер генерирует (и даже подписывает, но это тут не важно) в самом начале установления соединения, а в поля Subject и Issuer записываются, соответственно, IP-адрес с номером порта клиента и имя выбранной криптосистемы обмена ключами. Это такой экзотический способ “посигналить” в (закрытой) части TLS-сообщений. Клиенты должны бы игнорировать неподходящий сертификат в процессе валидации (но могут и ошибку выдать, конечно).

Очень полезный тест SSLLabs для TLS пока что не умеет обнаруживать поддержку криптосистемы X25519Kyber768 сервером – см. фрагмент результатов для tls13.1d.pw на скриншоте ниже (Supported Named Groups). Это, собственно, понятно и логично: использование данной криптосистемы всё ещё находится в экспериментальном статусе, а поддержка на стороне сервера совсем не распространена.

(Кстати, в результатах указано, что имена групп/криптосистем выведены в порядке предпочтений сервера, но для tls13.1d.pw это не так – сейчас “предпочтение” есть только для X25519Kyber768, остальные криптосистемы выбираются по наличию клиентских key_share, перечню поддерживаемых групп, но при этом ещё и случайным образом отправляется HelloRetryRequest – именно из соображений, что иногда нужно отправить HelloRetryRequest, а не по составу полученных клиентских параметров; обычные TLS-серверы так вряд ли делают.)

Всё же я пока восстановил свой экспериментальный сервер TLS 1.3 – tls13.1d.pw (некоторое время назад я писал, что собираюсь его совсем отключить). А чтобы восстановление выглядело поинтереснее, я реализовал на сервере поддержку постквантовой схемы получения общего секрета (KEM) X25519Kyber768. TLS с Kyber768 там реализован вручную, но я, впрочем, использовал криптопримитивы из удобной библиотеки Cloudflare.

Криптосистему с постквантовой схемой KEM Kyber768 в конце августа Google внедрил в браузер Chrome (в порядке эксперимента), так что можете проверить – на сервере у X25519Kyber768 повышен приоритет, поэтому, при наличии соответствующего открытого ключа в сообщении клиента, выбираться она должна довольно часто.

Вообще, открытый блок клиентского KeyShare в X25519Kyber768 весит аж 1216 байтов (32 + 1184, потому что это ключ X25519, 32 байта, плюс ключ постквантовой части Kyber768, который большой). Тем не менее, я всё же пока что сделал вывод этого ключа без сокращений, что, возможно, выглядит тяжеловато, но видно будет только в браузере с поддержкой данной криптосистемы. (Дополнение, 12/09/2023: технические подробности об использовании криптосистемы.)

Поддержка есть только в самых свежих версиях Chrome (>=116), а включать её нужно через флаги: chrome://flags, набрать “TLS13” в поиске, флаг называется “TLS 1.3 hybridized Kyber support”.

(Не знаю, будет ли у меня возможность поддерживать сервер далее, так что в какой-то момент он может отключиться, теперь уже даже и без предупреждения, но посмотрим; ошибки подключения, естественно, могут быть и по другим причинам – это, всё ж, экспериментальный сервер.)

Записок в августе 2023 года вышло достаточно, чтобы некоторые отметить отдельно:

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

“Нормализация символов Unicode и доменные имена” – полезное описание одной весьма тонкой технической особенности применения Unicode в тех редких случаях, где применять Unicode не стоило бы;

“STARTTLS и SMTP” – как TLS “приспособительным” способом прицепляется к SMTP;

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

“Широкие проблемы применения ИИ” – из совсем свежих записок: интерпретация “перебора коэффициентов” в современной практике ИИ.

Вот так представляется бот, собирающий веб-страницы для разновидностей ChatGPT: “Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.0; +https://openai.com/gptbot)”. В августе бот почему-то особенно активен на dxdt.ru, где, собственно, и был мной замечен в логах.

Записок, которые вышли на dxdt.ru в июле 2023 года, снова достаточно, чтобы некоторые из них отметить отдельно, а именно:

• “Лазейки” вокруг неравенства Белла;
• “Инспекция” трафика с сохранением конфиденциальности;
• Бункеры в Fallout;
• Уровни сигнатур клиентских подключений;
• Общее представление о шифрах и бэкдоры.

В 2018 году я разработал и опубликовал по адресу tls13.1d.pw тестовый сервер для проверки приложений, поддерживающих TLS 1.3. Строго говоря, тогда именно TLS 1.3 (в смысле обозначения версий) ещё не было, а был черновик спецификации, которую, в экспериментальном режиме, поддерживали некоторые распространённые клиенты, например, браузеры Chrome и Firefox. На серверной стороне дело обстояло похуже – поддержки в стабильных версиях распространённых веб-серверов не было совсем.

Сейчас TLS 1.3 стал типовой, очень распространённой версией TLS, используемой в вебе (и не только в вебе), поэтому, думаю, тестовый сервер больше не нужен: отключение tls13.1d.pw я запланировал на конец августа 2023 года (возможно, раньше).

Собственно, всякий современный TLS-сервер для HTTPS должен поддерживать TLS 1.3 в качестве основного, а TLS 1.2 – в качестве “запасного” варианта. Прочие версии можно отключить, ну, кроме весьма редких случаев, когда требуется совместимость с очень старыми приложениями – к сожалению, некоторым веб-сервисам приходится тянуть поддержку старых клиентов. Однако для остальных – можно даже оставить только TLS 1.3: этот протокол портировали на самые старые и экзотические системы. Кроме того, TLS 1.3, на данный момент, лучшая версия, которая архитектурно превосходит все предыдущие.

(Update, 09/09/2023: сервер пока что восстановлен и работает – подробности.)