Постквантовый TLS приехал в прод: X25519MLKEM768 включился сам — у кого что сломалось?

[hacker_lena]

Заметил, что у нас на части сервисов в браузере в деталях соединения вместо привычного X25519 теперь висит X25519MLKEM768 — постквантовый гибрид включился по умолчанию после обновления браузеров и ставится сам, где сервер умеет.

Повод хороший: ключевой обмен теперь устойчив к 'собери сейчас, расшифруй потом' (harvest now, decrypt later) — трафик, который пишут сегодня, не вскроют квантовым компьютером через 10-15 лет. Подписи пока классические, но обмен ключами прикрыли.

У кого уже в проде? Что-нибудь сломалось? Слышал про проблемы со старыми железками-инспекторами на раздутом ClientHello.

[valru]

У нас сломалось ровно в одном месте, но красиво. ClientHello с ML-KEM пухнет: постквантовый ключ — это уже не 32 байта, а за килобайт, и hello перестаёт влезать в один пакет, его приходится фрагментировать на уровне TLS-рекордов.

И вот старый балансировщик и одна inline-железка для разбора трафика на это споткнулись: они молча предполагали, что ClientHello целиком в первом сегменте, и роняли хендшейк, когда он приезжал двумя кусками. Симптом мерзкий — часть клиентов коннектится, часть нет, в зависимости от того, какие группы они предлагают. Полдня ловили, потому что в логах балансировщика ничего внятного.

Лечится обновлением прошивки и софта на тех узлах (свежие NGINX/HAProxy с актуальным OpenSSL переваривают нормально), либо как временный костыль можно на сервере не анонсировать PQC-группу, пока легаси не обновят. Но это именно костыль, отключать защиту насовсем смысла нет. Так что прежде чем включать на периметре — проверьте всю цепочку, которая трогает ClientHello, особенно DPI и инспекцию трафика.

[qcdeed]

@corvet, Любопытно, как это ляжет на нашу специфику с ГОСТовой криптографией. На госконтуре и в банках свои наборы (ГОСТ TLS), и там вопрос постквантовой стойкости решается отдельно и своим регулятором, а не через ML-KEM из браузера. Так что у многих в СНГ будет зоопарк: наружу — гибридный X25519MLKEM768, внутрь по требованиям — ГОСТ. Кто-нибудь уже видел постквантовые анонсы по ГОСТ-стеку?

[tomcruz]

Уточню, чтобы не было завышенных ожиданий: защищён пока только обмен ключами. Подписи в вебовом PKI всё ещё классические (RSA/ECDSA), постквантовых сертификатов в массе нет — ML-DSA в публичных CA ещё не раскатан, там и размеры подписей кусаются, и сроки у CA/Browser Forum растянуты на годы.

То есть от 'harvest now, decrypt later' гибридный обмен спасает уже сегодня, а вот от будущей подделки подписей квантовым компом — это отдельная и более долгая история. Но конфиденциальность важнее: подпись надо ломать в моменте, а перехваченный сегодня трафик лежит и ждёт.

[corvet]

Да, суть именно в этом гибриде: X25519 (классика) плюс ML-KEM-768 (он же Kyber, теперь FIPS 203). Берут оба, секрет комбинируют — если квантовый компьютер когда-нибудь сломает X25519, постквантовая часть всё равно держит, а если в новом ML-KEM найдут дыру, классика подстрахует. Поэтому гибрид, а не чистый PQC.

Поддержка уже широкая: OpenSSL 3.5 умеет ML-KEM из коробки, BoringSSL давно, в браузерах включено по умолчанию. Сервер обновил — и оно само согласуется при хендшейке.

[kingpaul]

Я в лагере умеренных скептиков по срокам 'квантового апокалипсиса' — криптографически значимого квантового компьютера всё ещё нет и в ближайшие годы вряд ли будет. Но именно для обмена ключами аргумент 'harvest now, decrypt later' железобетонный: запись трафика стоит копейки, а лежать он может десятилетиями. Так что гибрид по умолчанию — это правильно и почти бесплатно. А вот переписывать всё на чистый PQC прямо сейчас точно рано.