Постквантовое будущее Let's Encrypt: что нужно знать веб-разработчику

1. Квантовые часы тикают

3 июня 2026 года Let's Encrypt объявила о планах внедрения Merkle Tree Certificates (MTC) — принципиально нового подхода к TLS-аутентификации, созданного для постквантовой эры. Это не очередное обновление протокола; это первая фундаментальная перестройка Web PKI (инфраструктуры открытых ключей) с тех пор, как HTTPS стал повсеместным.

Let's Encrypt обслуживает около 300 миллионов активных сертификатов — это крупнейший в мире удостоверяющий центр (CA). Когда они меняют то, как работают сертификаты, каждый разработчик, управляющий веб-сервером, обращает внимание.

Это объявление сигнализирует: постквантовая готовность перешла из разряда «когда-нибудь» в «мы строим это прямо сейчас». В этой статье разбираем, что происходит, почему это важно и что нужно делать разработчику.

2. Почему сейчас? Ускорение сроков перехода на постквантовую криптографию

Долгое время считалось, что постквантовое шифрование требует срочного внимания (из-за атак «собрал сейчас — расшифрую потом»), а постквантовая аутентификация (цифровые подписи) может подождать — квантовому компьютеру нужно было бы подделать подпись в реальном времени. Теперь этот расчёт изменился.

2.1 Государственные мандаты устанавливают жёсткие дедлайны

График резко уплотнился:

• NSA CNSA 2.0 (2022) — предписал системам национальной безопасности переход на постквантовые алгоритмы в 2030–2035 гг.
• NIST (проект рекомендаций) — намерен объявить RSA-2048 и P-256 устаревшими после 2030 г., запретить после 2035 г.
• Дорожная карта ЕС по квантово-устойчивой криптографии — нацелена на системы повышенного риска к концу 2030 г., массовая миграция к 2035 г.
• Google — объявил 2029 год целевым для своих сервисов, ссылаясь на ужесточение оценок сроков появления CRQC
• Cloudflare — подтвердил аналогичный дедлайн 2029 года
• Go 1.27 — добавил ML-DSA (стандартизированный NIST постквантовый алгоритм подписи) прямо в стандартную библиотеку

2.2 Реальная срочность: долгоживущие ключи

Корневые ключи CA, ключи подписи кода и системы идентификации имеют срок службы в несколько лет. Атакующий, который перехватит подпись корневого CA сегодня, сможет подделывать подчинённые CA годами. Стандарты принимаются годами. Браузеры, библиотеки и ACME-клиенты нуждаются в обновлении. Масштабные изменения инфраструктуры занимают минимум 2–3 года. Работу нужно начинать сейчас.

3. Проблема размера: почему постквантовые подписи не вписываются в сегодняшний Web PKI

3.1 Цифры не врут

Типичное TLS-рукопожатие сегодня несёт 5 подписей + 2 открытых ключа. Наивная замена существующих алгоритмов на ML-DSA увеличила бы одно рукопожатие до 10+ КБ.

3.2 Что показало тестирование Cloudflare

Исследования Cloudflare продемонстрировали, что при таких размерах:

• Заметная доля TLS-соединений падает в реальных сетях
• Оставшиеся соединения ощутимо медленнее
• Стоимость платит каждое TLS-соединение
• Особенно критично для мобильных устройств, IoT и развивающихся регионов

Итог: Наивная замена на ML-DSA ухудшила бы пользовательский опыт во всём вебе. Вот почему нужен новый подход — и именно здесь появляются Merkle Tree Certificates.

4. Merkle Tree Certificates: другой подход

4.1 Как работает традиционный X.509 сегодня

Сегодня каждый сертификат подписывается CA индивидуально. Certificate Transparency (CT) добавляется отдельным шагом: выпусти сертификат, отдельно залогируй его, затем добавь лишние SCT-подписи в каждое TLS-рукопожатие. Каждая подпись в цепочке должна быть передана во время рукопожатия.

4.2 Как MTC меняют правила игры

MTC переворачивают эту модель:

Пакетная подпись: CA выпускают сертификаты пакетами. Единая постквантовая подпись (называемая «landmark» — ориентир) покрывает весь пакет. Браузеры получают актуальные ориентиры по отдельному каналу — не во время TLS-рукопожатия.

Два режима работы:

• Обычный (оптимистичный): Рукопожатие несёт 1 подпись + 1 открытый ключ + 1 доказательство включения. Меньше, чем сегодняшнее рукопожатие Web PKI, несмотря на использование постквантовых алгоритмов.
• Автономный (запасной): Немного большее рукопожатие для клиентов с устаревшими ориентирами.

4.3 Встроенный Certificate Transparency

Поскольку каждый сертификат является частью опубликованного дерева Меркла:

• Сертификат не может существовать вне дерева — CT является неотъемлемым свойством
• Это устраняет сложную часть сегодняшней экосистемы CT (валидация SCT, gossiping, доказательства включения)
• Let's Encrypt управляет CT-логами с 2019 года — у них есть производственный опыт работы с деревьями Меркла в масштабе

4.4 Текущий статус

• Cloudflare + Chrome уже проводят эксперимент по проверке MTC на реальном интернет-трафике
• IETF PLANTS WG (PKI, Logs, And Tree Signatures) стандартизирует дизайн
• Chrome объявил MTC предпочтительным путём добавления постквантовых сертификатов в публичный веб

5. Дорожная карта внедрения Let's Encrypt

5.1 График

5.2 Что нужно изменить в стеке Let's Encrypt

• Инфраструктура выпуска — создание пакетов сертификатов, подпись ориентиров
• Протокол ACME — возможность запрашивать и получать MTC
• Инструменты отзыва — новые механизмы для отзыва на уровне пакета и на уровне сертификата
• Инфраструктура прозрачности — MTC расширяют существующие CT-логи LE

5.3 Зависимости от стандартов

• Подписи ML-DSA в X.509 → RFC 9881 (октябрь 2025) — финализирован
• Подписи ML-DSA в TLS → draft-ietf-tls-mldsa — в разработке
• ML-DSA в стандартной библиотеке Go → Go 1.27 — выпущен
• Спецификации PLANTS WG — в разработке

5.4 Влияние на разработчиков (сегодня = никакое)

Let's Encrypt ясно говорит: «Сегодня ничего не меняется. Ваши текущие сертификаты Let's Encrypt будут выпускаться и обновляться как обычно.»

Когда постквантовые сертификаты появятся, они будут:

• Бесплатными (как и текущие)
• Автоматизированными (тот же ACME-клиент)
• Доступными каждому (те же условия получения)

6. Что нужно сделать разработчику

6.1 Немедленные действия (сделать в этом году)

Включите постквантовый обмен ключами ПРЯМО СЕЙЧАС:

• Настройте серверы на поддержку X25519MLKEM768 (гибридный постквантовый обмен ключами)
• Это защищает от атак «собрал сейчас — расшифрую потом» — самой срочной угрозы
• Основные браузеры уже поддерживают его; администраторам серверов нужно включить поддержку
• OpenSSL 3.5+ поддерживает X25519MLKEM768

Конфигурация nginx:

ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;

Конфигурация Apache:

SSLOpenSSLConfCmd Curves X25519MLKEM768:X25519:prime256v1:secp384r1;

6.2 Среднесрочная подготовка (2026–2027)

• Изменений на стороне клиента пока не требуется — обратная совместимость сохраняется
• Следите за прогрессом PLANTS WG для финальных спецификаций MTC
• Мониторьте certbot, acme.sh и Caddy на предмет поддержки ACME MTC-расширений
• Операторам CDN стоит протестировать сертификаты размером с ML-DSA в staging
• Устройствам IoT с ограничениями может потребоваться особое внимание (обновление прошивок)

6.3 Долгосрочная перспектива (2028+)

• Ожидайте, что браузеры начнут прекращать поддержку RSA-2048 / P-256 после 2030 года
• Планируйте полную миграцию внутренней PKI (не только сертификатов Let's Encrypt)
• Ключи подписи кода, S/MIME и подпись документов также потребуют постквантового обновления

6.4 Совместимость с OpenSSL и библиотеками

• OpenSSL 3.5+ поддерживает ML-DSA через провайдерную модель
• Go 1.27 включает ML-DSA в crypto/mlkem и crypto/mldsa
• Библиотеки Python (cryptography), Node.js и Java следят за стандартами NIST

7. Связь с другими статьями по безопасности

Эта статья развивает темы, затронутые в более ранних руководствах на maximov.by:

Доверие в Web PKI: Статья BadHost CVE-2026-48710 рассказывает, как ошибочная выдача сертификатов подрывает доверие. MTC решают эту проблему, делая Certificate Transparency неотъемлемым свойством — MTC не может существовать вне дерева Меркла, что устраняет целый класс атак с ошибочной выдачей.

Верификация через дерево Меркла: Точно так же, как атаки на цепочку поставок npm требуют верификации происхождения пакетов, Web PKI нуждается в прозрачной и проверяемой выдаче сертификатов. MTC применяют тот же принцип верификации через дерево Меркла к цепочке TLS-сертификатов.

Встроенная защита vs внешняя: Наш анализ отравления кэша GitHub Actions показывает, что встраивание верификации в структуру данных (а не добавление внешней защиты) устраняет целые поверхности атак. MTC делают то же самое для сертификатов — существование в дереве равнозначно валидному выпуску.

8. Ключевые выводы

9. Часто задаваемые вопросы

10. Дополнительные материалы

Первичные источники

1. Официальное объявление Let's Encrypt (3 июня 2026)
2. Обсуждение на Hacker News (313 баллов)
3. RFC 9881 — идентификаторы алгоритма ML-DSA для X.509
4. IETF PLANTS Working Group
5. draft-ietf-tls-mldsa — ML-DSA в TLS (в разработке)

Техническая база

6. NIST FIPS 204 (ML-DSA)
7. NIST FIPS 203 (ML-KEM)
8. CNSA 2.0 (NSA, 2022)
9. Дорожная карта ЕС по квантово-устойчивой криптографии
10. Блог Cloudflare по постквантовой криптографии

Сообщество и реализация

11. Cloudflare нацелен на 2029 год для полной постквантовой безопасности
12. Cordon — open-source MTC CA сервер
13. Блог Soatok о гибридных постквантовых конструкциях (апрель 2026)
14. Let's Encrypt управляет CT-логами с 2019 года

Планируете миграцию или строите новый проект? Нужна помощь с настройкой — услуги по настройке серверов и веб-разработке.