Привет, Хабр!
JEP 527 добавляет в JDK 27 поддержку post-quantum hybrid key exchange для TLS 1.3. Если приложение на стандартном JSSE-стеке через javax.net.ssl, то после перехода на JDK 27 с JEP 527 оно сможет использовать новый гибридный key exchange в TLS 1.3.
Что будет в статье
Что такое TLS
Проблема “harvest now, decrypt later”
Что добавляет JEP 527
Почему key exchange гибридный
Что меняется для разработчика
Что может сломаться
1. Что такое TLS
TLS - это протокол для защищенного сетевого соединения. Он используется в HTTPS, подключениях к базам, внешним API и во внутреннем mTLS.
Handshake - это начальная фаза TLS-соединения. В ней клиент и сервер договариваются о версии протокола, параметрах безопасности, проверяют сертификаты и подготавливают ключи.
TLS negotiation - это согласование параметров внутри handshake: версии TLS, алгоритмов, supported groups и других настроек, которые обе стороны умеют использовать.
Key exchange - часть handshake, где стороны получают общий секрет. Потом из этого секрета выводятся ключи, которыми шифруется прикладной трафик.
2. Проблема “harvest now, decrypt later”
Классический TLS 1.3 обычно использует ECDHE(Ephemeral Elliptic-Curve Diffie-Hellman) привычный и широко используемый механизм key exchange. Он дает forward secrecy. Если через год утечет приватный ключ сертификата сервера, старые TLS-сессии не должны автоматически раскрыться. Секреты для этих сессий создавались временными ключами во время handshake, а не напрямую приватным ключом сертификата.
Но у классических алгоритмов на эллиптических кривых есть неприятная перспектива. Достаточно мощный квантовый компьютер сможет атаковать такую математику иначе, чем обычный компьютер. Это не значит, что завтра утром весь HTTPS сломается, но есть угроза harvest now, decrypt later. Злоумышленник может записывать зашифрованный трафик сейчас, расшифровать он его сейчас не может. Но если данные ценны через пять или десять лет, то появляется вопрос: что будет, когда появятся более сильные квантовые атаки? Для одноразового кода на 30 секунд это не имеет значения. Для медицинских или персональных данных, финансовых документов и коммерческих контрактов - уже интереснее. Именно поэтому криптографическую миграцию начинают заранее, когда еще есть время спокойно обновлять платформы, протоколы и инфраструктуру.
3. Что добавляет JEP 527
JEP 527 добавляет в JDK поддержку трех гибридных TLS 1.3 named groups:
X25519MLKEM768
SecP256r1MLKEM768
SecP384r1MLKEM1024
Самый важный для прикладного разработчика вариант - X25519MLKEM768. Именно он включается в default-список named groups и ставится первым. Грубо говоря, Java-клиент начинает говорить серверу:
Я умею X25519MLKEM768.
Еще умею обычный x25519.
Если можешь, давай выберем гибридный вариант.
Если нет, договоримся по старому варианту.
Это изменение не в HTTP, REST или коде HttpClient, а внутри TLS-handshake. Если сервер тоже поддерживает X25519MLKEM768, стороны могут выбрать hybrid key exchange. Если не поддерживает, должен сработать fallback на обычную группу, например x25519. Но из-за прокси, WAF, TLS-терминаторов, старых библиотек и кастомных настроек это все равно надо проверять на своей инфраструктуре.
4. Почему key exchange гибридный
Гибридный здесь значит: используется и классический ECDHE, и постквантовый ML-KEM. ML-KEM - это стандартизованный постквантовый KEM. Раньше этот алгоритм был известен как Kyber. В Java строительные блоки уже появились раньше:
JEP 452 добавил KEM API;
JEP 496 добавил ML-KEM;
JEP 527 использует это в TLS 1.3.
Почему не перейти сразу на чистый post-quantum key exchange? Потому что криптографические миграции лучше делать осторожно. Классические алгоритмы давно изучены и хорошо оптимизированы. Постквантовые алгоритмы новее. У них другие размеры ключей и сообщений. У них другой профиль производительности. Их еще надо массово обкатать в инфраструктуре. Гибридный подход использует оба механизма сразу. Если когда-нибудь ECDHE станет проблемой из-за квантовых атак, остается ML-KEM. Если в новом постквантовом алгоритме найдут неприятную проблему, остается классическая часть. Это не абсолютная защита от всего. Но это разумный переходный режим для огромной TLS-экосистемы.
5. Что меняется для разработчика
Если вы используете стандартный Java TLS через javax.net.ssl, то прикладной код может вообще не измениться. Например:
HttpClient client = HttpClient.newBuilder()
.version(HttpClient.Version.HTTP_2)
.build();
В этом коде нет ни ML-KEM, ни X25519MLKEM768. Но TLS-handshake делает JDK. Значит, после обновления runtime поведение handshake может измениться. Это главный практический момент.
6. Что может сломаться
TLS negotiation должен дать обратную совместимость. Клиент предлагает гибридную группу и обычные группы. Сервер выбирает то, что поддерживает. Если гибрид не поддерживается, выбирается обычный x25519. Проблемы начинаются там, где инфраструктура ведет себя странно. Например:
старый proxy не любит большой
ClientHello;WAF(Web Application Firewall) криво парсит новые named groups;
TLS-терминатор(nginx или load balancer) не обновлялся несколько лет;
в приложении жестко задан список groups без fallback;
используется не JSSE, а другой TLS provider;
разные сервисы в mTLS-контуре работают на сильно разных runtime.
Большой practical point: post-quantum key exchange увеличивает размер key share. ClientHello может стать больше. Современная инфраструктура должна это переваривать. Но старые proxy, WAF или TLS-терминаторы могут не справиться с таким handshake. Симптомы обычно такие:
handshake timeout;
SSLHandshakeException;connection reset;
ошибка только через конкретный proxy;
из одной сети работает, из другой нет.
Вывод
JEP 527 обновляет TLS 1.3 key exchange в стандартной Java-реализации JSSE. Прикладной код для HTTP-клиента из-за этого обычно менять не нужно. Меняется поведение TLS-handshake на уровне JDK.
После перехода на JDK 27 Java-клиент сможет предпочитать X25519MLKEM768, если сервер это поддерживает. Если сервер не поддерживает гибридную группу, должен использоваться fallback на классические группы, например x25519.
Перед миграцией стоит проверить jdk.tls.namedGroups, кастомные SSLParameters, критичные endpoint-ы, прокси и TLS-терминаторы. Еще важно понимать, где реально завершается TLS: в Java-приложении, на nginx, в load balancer или в другом компоненте.
JEP 527 не делает систему полностью защищенной от квантовых атак. Он добавляет в Java поддержку гибридного post-quantum key exchange для TLS 1.3. Для прикладной команды это повод проверить TLS-handshake при переходе на JDK 27.
Ссылки
JEP 527: Post-Quantum Hybrid Key Exchange for TLS 1.3 - https://openjdk.org/jeps/527
JEP 452: Key Encapsulation Mechanism API - https://openjdk.org/jeps/452
JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism - https://openjdk.org/jeps/496
Если статья понравилась, то велкам в мой блог!
Безопасных Вам Релизов!