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

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

Предположим, что сертификаты начали впускать на 48 часов максимум, а базовым удостоверяющим центром для них всё так же является один централизованный сервис, типа Let’s Encrypt. Например, основная доля веб-узлов зоны .RU “подписана” этим УЦ. Если потребуется быстро отозвать миллионы сертификатов штатным образом, – что через обязательные CRL, что через опциональный OCSP, – то возникнет большая сопутствующая нагрузка на системы УЦ. В случае же с короткоживущими сертификатами – никакой дополнительной нагрузки не возникает, более того, нагрузка уменьшается: отзывать ничего не требуется, а УЦ просто перестаёт выпускать новые сертификаты для заданных имён (и IP-адресов).

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

Шестидневные TLS-сертификаты Let’s Encrypt планирует выпускать и для IP-адресов, что несколько необычно. Тут имеется в виду, что такие сертификаты будут валидными при обращении к узлу без использования DNS-имени, а только по IP-адресу. Такие сертификаты являются редкостью, но выпускались они и раньше – например, сертификат, выпущенный DigiCert 02.01.2025 для сервиса Cloudflare 1.1.1.1, содержит несколько IP-адресов в поле SAN (Subject Alternative Name). Этот сертификат выпущен не на шесть дней, а на срок более года: он действует до 21.01.2026.

Понятно, что DNS для подтверждения управления IP-адресами не подходит. Поэтому проверяется только факт управления узлом под заданным IP-адресом. Let’s Encrypt будет проводить такую проверку по HTTP и через TLS-ALPN (а это довольно экзотический метод, реализующий “прозрачную” проверку на уровне TLS: то есть, на уровне веб-сервера её даже не видно; возможно, я как-нибудь напишу про этот протокол подробнее).

Активный перехват трафика, адресованного некоторому IP, конечно, возможен, – в том числе, через BGP-атаки, – но тогда он же, формально, закрывает и все прочие случаи: например, для DNS-проверки можно перехватывать трафик в направлении авторитативных серверов. Другое дело, что в DNS, обычно, серверов несколько и они даже должны бы находиться в разных автономных системах. Это кроме того, что можно проверять DNSSEC (но это редкость).

Однако сертификаты на IP-адреса позволяют запускать доверенные сервисы, обращение к которым не раскрывает имён уровня приложений. Представьте, что некоторая “точка входа” постоянно мигрирует по IPv6-адресам, автоматически выпуская “короткие” сертификаты с подтверждением через TLS-ALPN – то есть, HTTP там вообще нет. Получается гибкое и скрытное решение. В общем, интересное развитие технологий.

(Я недавно подробно описывал то, как срок действия сертификатов в TLS связан с проблемой компрометации ключей.)

Небольшое пояснение к предыдущей записке, что там имелось в виду: так как в результате “очередного сбоя” для большинства затронутых пользователей фильтровались соединения 80/tcp (udp, вероятно, тоже) и 443/tcp (udp, вероятно, тоже), то у этих пользователей не открывались привычные веб-сайты – причина понятна: веб штатно работает на этих номерах портов (номера – только один из признаков, но для веба – достаточно). Сервисы, использующие другие номера – оказались не затронуты. Но кто ж про эти сервисы знает, и задумывается, что они тоже “через Интернет”?

А “Интернет” – равно “веб”. Отсюда и странные восклицания: «не работает “Интернет”, но работает Telegram» (приложения последнего могли использовать другие номера портов). Конечно, работал не только Telegram, но и, скажем, Jabber. Ходил ICMP (ping, грубо говоря), что, с одной стороны, затрудняло быструю диагностику, но, с другой стороны, позволяло быстрее же понять, что именно происходит “на сетевом уровне”.

(Да, понятно, что это никак не нивелирует значение самого сбоя, а Интернет в целом, конечно, при этом поломался ещё больше, поскольку штатная работа протоколов оказалась нарушена. Но так-то Интернет сломан уже давно.)

На примере очередного масштабного сбоя (в Рунете) можно очередной же раз убедиться, что за “Интернет” – пользователи повсеместно принимают веб, поэтому СМИ и пишут, что “работал только Telegram”.

А тип криптосистемы ML-KEM (она же – Kyber) на русском лучше писать так: “модуль-решёточная криптография”.

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

То есть, как ни крути, а решётки имеют определяющее значение, но с точки зрения базовой задачи, которая напрямую в ML-KEM не используется. Так же, кстати, написано и в стандарте NIST, где термин “решётка”, если не считать употребление его в названии, используется всего пару раз. (При этом, кстати, не совсем корректно писать, что используемая криптография “основана на задачах из теории решёток” – на этих задачах основаны предположения о стойкости, а не криптографические алгоритмы; не то чтобы радикальное изменение смысла, но существенные детали теряются.) И необходимо учитывать, что математический термин “решётка” (русский) и математический термин lattice (английский) – различаются в трактовках, даже если смотреть узкую интерпретацию, поэтому для строгих определений всё равно потребуются уточнения.

“Модулярная решётка” – явно не подходит, поэтому пусть будет “модуль-решёточная”. Ведь главное тут – чтобы криптосистема не оказалась решетчатой, но от слова “решето”.

Исследователями из Watchtowr опубликовано подробное описание того, как обнаружили возможность и реализовали удалённое исполнение кода (RCE) в свежей CVE-2025-0282 (Ivanti Connect Secure – это, как нередко случается, корпоративный продукт для “защищенного корпоративного VPN”).

Описание по ссылке выше – довольно техническое, требует специальных знаний для понимания. Если кратко, то основой данной уязвимости является типовое переполнение буфера из-за перепутанных в исходном коде значений максимального размера массива, но вот для успешной реализации – потребовались не самые прямолинейные техники.

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

Прямолинейной эксплуатации через перезаписывание стека помешало наличие в этом стеке указателя на блок памяти, который должен был освобождаться перед возвратом из атакуемой функции (то есть, вызов конструкции с free() приводил бы к преждевременному возникновению исключения). Но исследователи смогли найти точку модификации таблицы Vtable, которая содержит указатели на функции (это типовая конструкция для “виртуализации” “методов” в C++), а потом ещё успешно нашли в коде гаджет*, модифицирующий указатель стека. Причём, поиск гаджета был затруднён тем, что требовалось найти точку для входа, которая совпадала бы не только по подобранному значению указателя, но и по значению смещения, жёстко зафиксированного в исполняемом коде. А это стало возможно потому, что исследуемое приложение использует много библиотек: “It’s a good thing that the Ivanti web binary contains so many libraries”. Как говорится, принцип разработки с созданием минималистичного и простого собственного кода мог бы здесь помочь. Ну, раз не помог стат. анализатор.

* – дополнение от 13.01.2025: гаджет – фрагмент машинного кода с нужными свойствами, оканчивающийся командой передачи управления, см. комментарии к записке.

Чуть более пяти лет назад, в декабре 2019 года, я опубликовал на dxdt.ru небольшой текст про перспективы квантовых компьютеров в разрезе прикладной криптографии: “Постквантовый мир прикладной криптографии“. “Хайп” про квантовые компьютеры был уже тогда, пусть и меньше, чем сейчас.

Что поменялось за прошедшие пять лет? Самое главное – не поменялось: универсальных квантовых компьютеров как не было пять лет назад, так и сейчас нет, даже близко. Тут просто ничего не изменилось. Даже “хайп” начал спадать (под давлением AI/LLM, возможно).

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

Посмотрим на другие моменты. Ниже – некоторые цитаты и комментарии к ним.

“Например, когда говорят о задаче криптографии с открытым ключом, речь идёт об алгоритме Шора”.

С алгоритмами и общими принципами – тоже ничего не изменилось: алгоритм Шора так и остаётся единственным двигателем, к этому алгоритму даже предложены важные улучшения.

“Считается, что время ещё есть, но криптосистемы с открытым ключом, обладающие стойкостью к криптоанализу на квантовом компьютере, хорошо бы получить заранее”.

Именно этот подход сейчас и применён на практике – постквантовые криптосистемы внедрены сильно заранее.

“NIST уже несколько лет выполняет программу по выбору постквантовых криптосистем”.

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

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

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

“Тем не менее, на данный момент, массово внедрённых постквантовых криптосистем с открытым ключом – нет. Существуют только экспериментальные варианты”.

Пять лет спустя – есть такие, массово внедрённые, криптосистемы: см. выше про ML-KEM в Chrome, например. Это очень быстро, по меркам данной области.

“Скорее всего, на практике будет использован тот или иной вариант криптосистемы на эллиптических кривых”.

Пока не сбылось, к сожалению: первыми массово внедрёнными стали криптосистемы “на решётках”, как их принято называть сейчас. Но ещё может сбыться позже. Посмотрим.

“Третья фундаментальная часть практической криптографии – симметричные шифры — не столь подвержена квантовым атакам”.

Ничего не изменилось. Есть различные незначительные улучшения теоретических атак на конкретные шифры, как и ожидалось, в целом – симметричные шифры стойкость сохраняют.

“Первыми будут вводиться в строй криптосистемы, позволяющие получить общий секрет (распределение ключей). […] Не предполагается быстрый переход исключительно на постквантовые системы. Напротив, их будут вводить в качестве дополнительного инструмента, работающего вместе с классическими, хорошо проверенными”.

Именно так и сделано (но это, конечно, довольно очевидный вариант): ML-KEM – схема для распределения ключей, в браузерах для TLS внедрена в составе “гибридов” с классическими X25519 и ECDH.

В общем, прогресс в данной области за пять лет большой, выразился он в том, что постквантовые криптосистемы уже используются на практике, а квантовые компьютеры для атак на классические криптосистемы – нет, не используются, и пока не видны.

(Кстати, вот ещё тематически близкая записка – про кванты и квантовую криптографию с компьютерами.)

На тестовом сервере TLS tls13.1d.pw, который я недавно перенёс на виртуальную машину класса “Эконом”, но всё ещё поддерживаю, есть небольшой трафик успешных соединений с гибридной криптосистемой X25519MLKEM768 (это новый вариант, с индексом 0x11EC по реестру IANA). Например, за сутки 07/01/2025 – десять успешных соединений с обменом ключами по X25519MLKEM768 (всего, примерно, 4500 успешных соединений за те же сутки; там, вообще, достаточно большой трафик, но основное количество попыток соединений – не совместимы с TLS 1.3). А вот SecP256r1MLKEM768, которая тоже поддерживается сервером, в январе не встречалась вовсе.

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

На Youtube заблокировали, а потом разблокировали популярное видео про работу биткойн-сети на широко известном канале 3Blue1Brown. Конечно, блокировали по жалобе на “нарушение авторских прав”, но, после разбирательства, оказалось, что претензий к данному видео нет – жалоба ошибочная.

То, что Youtube позволяет блокировать всё подряд – это не новость, да и относится не только к Youtube. Но тут занимательно выглядит механизм возникновения “ошибки”. Описание механизма The Register предоставила компания, подавшая жалобу. Оказывается, компания весьма продвинутая, использует ИИ и прочие технологии автоматизации, но сотрудник скопировал не тот URL, потому что в браузере был открыт сайт Youtube с включённым автопроигрыванием – “было открыто “правильное видео”, однако сотрудник отвлёкся, а сайт Youtube в это время автоматически переключил браузер на URL другого видео, этот URL и скопировали в форму жалобы”.

P.S. То есть, на конференциях и в бравурных анонсах рассказывают разное про “автоматизацию автоматизации” и внедрение ИИ-систем, но на практике, получается, даже для каналов Youtube с миллионами подписчиков и видео с миллионами просмотров – отсутствуют элементарные функции проверки и подтверждения.

Немного о статусе постквантовой криптографии в TLS. Постквантовые криптосистемы обмена ключами для TLS планируется поддерживать только в TLS 1.3. По крайней мере, так сейчас выглядит тенденция: скорее всего, TLS 1.2 сперва “заморозят”, а потом, достаточно скоро, объявят нерекомендуемым, как уже сделано в RFC 8996 для версий 1.0, 1.1. Обратите внимание, что в RFC прямо сказано: “MUST NOT be used” – в терминах этих документов MUST NOT именно и означает, что строго запрещено использовать, без вариантов. Конечно, если ваше приложение соответствует данному RFC – так-то все спецификации носят рекомендательный характер.

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

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

Технически, принести постквантовые криптосистемы можно и в TLS 1.2 – там достаточно механизмов для расширения протокола. Но смысл в поддержке TLS 1.2 можно найти только такой, что сохраняется совместимость со старыми программами и средами, которые невозможно обновить. Однако, если исходить из этого, то не стоит ожидать и добавления реализаций постквантовых криптосистем в эти программы и среды. При этом, TLS 1.3 лучше со всех сторон, – в том числе, в плане программной реализации, – поэтому продолжать тянуть ещё одну версию, за вычетом требований исторической совместимости, несколько странно. Да, можно предположить, что если вдруг в 1.3 обнаружится какой-то удивительный и фатальный архитектурный дефект, то использование 1.2 позволит избежать одномоментного обвала всего и вся. Но на уровне протоколов TLS – это сильно вряд ли, а учитывая архитектурную выверенность TLS 1.3, что-то подобное скорее произойдёт с 1.2. А вот поверить в какие-то дефекты распространённых реализаций – нетрудно. Но, опять же, не факт, что поломается именно 1.3, в котором меньше мест, где можно споткнуться. Поэтому-то развитие, в виде добавления постквантовых криптосистем, и относится только к 1.3.