Вышел OpenSSL 4.0 — выпилены engines, SSLv3 и ASN1_STRING

Если в вашей сборке крутится что-то линкованное с OpenSSL — посмотрите, не сломает ли вас переход на 4.0: релиз выкидывает engine-интерфейс (на нём держится gost-engine для ГОСТ-криптографии), поддержку SSLv3, скрипт c_rehash и делает непрозрачной структуру ASN1_STRING. Следом едут новые фичи — Encrypted Client Hello, гибридный постквант-обмен и FFDHE в TLS 1.2.

14 апреля 2026 года OpenSSL Project выпустил OpenSSL 4.0 — первый мажорный релиз со времён 3.0 (сентябрь 2021). За четыре с половиной года накопилось много удалений и чуть поменьше новых возможностей. Разбираем, что именно сломается при апгрейде и ради чего всё это затевалось.

Что выпилили: список для миграции

OpenSSL 3.0 в 2021 году ввёл архитектуру providers и одновременно объявил engine-интерфейс устаревшим. Четыре года переходного периода закончились: engines больше нет в коде, опция сборки no-engine всегда включена, макрос OPENSSL_NO_ENGINE — всегда определён. Это самое болезненное для тех, кто держал кастомный крипто-плагин: GOST, аппаратные HSM, PKCS#11-токены со старым драйвером.

Из публичных API в 4.0 пропали или стали непрозрачными:

• Engine-интерфейс целиком — providers теперь единственный способ подключить внешнюю криптографию.
• Поддержка SSLv2 Client Hello и SSLv3. SSLv3 деприкейтнули ещё в 2015 году (RFC 7568), в 1.1.0 выключили по умолчанию в 2016-м, теперь удалили из кода.
• Структура ASN1_STRING стала непрозрачной. Прямой доступ к полям — через функции-аксессоры.
• ERR_get_state(), ERR_remove_state(), ERR_remove_thread_state() — объект ERR_STATE теперь непрозрачный.
• Кастомные методы EVP_CIPHER, EVP_MD, EVP_PKEY, EVP_PKEY_ASN1 — устаревшие API удалены.
• X509_cmp_time() и семейство деприкейтнуты в пользу X509_check_certificate_times().
• Скрипт c_rehash — использовать openssl rehash.
• BIO_f_reliable() — был сломан с 3.0 и без жалоб прожил все эти годы.
• Опция msie-hack в команде openssl ca.
• Таргеты сборки darwin-i386 и darwin-ppc.
• Устаревшие эллиптические кривые в TLS (RFC 8422) выключены в сборке по умолчанию — включаются флагом enable-tls-deprecated-ec.
• Explicit EC curves — аналогично, флаг enable-ec_explicit_curves.

Отдельно изменилось поведение глобальной очистки. libcrypto больше не ставит обработчик на atexit(); OPENSSL_cleanup() теперь вызывается как глобальный деструктор при выходе процесса — значит, освобождение памяти по умолчанию происходит позже и в непредсказуемом порядке относительно других деструкторов. Если вам нужна детерминированная очистка до завершения процесса (например, чтобы выявлять утечки под valgrind), вызывайте OPENSSL_cleanup() явно.

Что это значит для ГОСТ-криптографии

gost-engine — основной проект, который даёт OpenSSL понимание российских алгоритмов (ГОСТ Р 34.10-2012, ГОСТ Р 34.11-2012, «Кузнечик» и «Магма» по ГОСТ Р 34.12-2015). Как понятно из названия, он реализован именно как engine и без engine-слоя собраться и загрузиться в OpenSSL 4.0 не сможет.

Альтернатива — gostprov, провайдер от того же сообщества на новом API. На 15 апреля 2026 года gostprov покрывает базовые примитивы — ГОСТ Р 34.10-2012 (подпись), ГОСТ Р 34.11-2012 (хеш «Стрибог») и блочный шифр «Магма»/«Кузнечик» (ГОСТ Р 34.12-2015). Что ещё не закрыто по сравнению с gost-engine: часть схем шифрования CMS (ГОСТ-обёртки ключей), VKO KEK-2012 и ряд нишевых TLS-свитов. Если ваш продукт сертифицирован по требованиям ФСБ или продаётся в госсектор — апгрейд на 4.0 нужно планировать заранее, с пересертификацией.

Ветки 3.x продолжают поддерживаться: 3.5 — LTS до апреля 2030 года, 3.4/3.3 — обычные релизы с обновлениями безопасности. Если с 4.0 спешить некуда — остановитесь на 3.5 и дождитесь, пока gostprov покроет нужные вам примитивы.

Что добавили

Encrypted Client Hello (ECH)

ECH — это RFC 9849, принятый в марте 2026 года. В обычном TLS-рукопожатии первый Client Hello содержит SNI — имя сайта, к которому вы подключаетесь — в открытом виде. Провайдер видит его и по нему можно фильтровать трафик или собирать метаданные. ECH делит Client Hello на две части: ClientHelloOuter с именем фронтового домена идёт в открытую, а ClientHelloInner с настоящим SNI шифруется публичным ключом, опубликованным через DNS (HTTPS-запись).

OpenSSL 4.0 — первая мажорная версия с ECH в основной ветке. Серверная и клиентская стороны поддерживают draft-final в полном объёме. Документация проекта — doc/designs/ech-api.md.

Гибридный постквант: SM2+ML-KEM-768

OpenSSL поддерживает ML-KEM (Module-Lattice Key Encapsulation Mechanism, FIPS 203 — постквантовый обмен ключами) и гибриды с ним с версии 3.5. В 4.0 добавили ещё один гибридный обмен — curveSM2MLKEM768: китайский SM2 (RFC 8998) плюс ML-KEM-768 в качестве постквантовой части. Комбинация адресная — она нужна прежде всего для рынка КНР, где SM2 обязателен по национальному стандарту. Плюс новый алгоритм цифровой подписи ML-DSA-MU — вариант ML-DSA с внешним префиксом (prehash) для больших сообщений.

Для остального мира в релизе также появился cSHAKE (SP 800-185 — customizable SHAKE, версия SHAKE с доменным разделением). cSHAKE используется как строительный блок в новых стандартах NIST — именно на нём построен KMAC, а также часть постквантовых подписей. Плюс KDF для SNMP и SRTP — узкие штуки, но их в OpenSSL долго не было.

FFDHE в TLS 1.2 и прочие мелочи

FFDHE (finite-field Diffie-Hellman) по RFC 7919 — способ согласовывать группы для классического DH из фиксированного списка, а не из того, что сервер пришлёт. В TLS 1.3 это сделали сразу, в TLS 1.2 OpenSSL годами поддерживал только «пришли мне параметры». 4.0 закрыл этот пробел.

• FIPS self tests теперь можно откладывать до реального использования — флаг -defer_tests в openssl fipsinstall.
• На Windows можно выбирать статическую или динамическую линковку VC Runtime.
• Нижние границы параметров PKCS5_PBKDF2_HMAC теперь проверяются при работе в FIPS-провайдере.
• Проверка AKID добавлена при установленном X509_V_FLAG_X509_STRICT.
• CRL-верификация получила несколько дополнительных проверок корректности.

Как мигрировать на OpenSSL 4.0

1. Не обновляйтесь в лоб. Сначала прогоните вашу сборку с 3.5 и флагами -Wdeprecated-declarations и OPENSSL_NO_DEPRECATED_3_0, чтобы увидеть, где висит engine-API или структурный доступ к ASN1_STRING.
2. Составьте карту зависимостей: какие ваши библиотеки линкуются с OpenSSL и какие из них делают что-то нестандартное. Особое внимание — ко всему, где в коде встречается ENGINE_*.
3. Если используете ГОСТ — ставьте параллельно gostprov на 3.x, проверьте, что покрываются все ваши примитивы, и только после этого двигайтесь к 4.0.
4. Проверьте, как ваше приложение освобождает ресурсы OpenSSL. Если вы полагались на atexit()-финализацию или ранний OPENSSL_cleanup() в середине работы — добавьте явный вызов в точку, где очистка действительно нужна.
5. Пересоберите статические пакеты. OpenSSL 4.0 несовместим по ABI с 3.x — пакетные менеджеры дистрибутивов ближайшие месяцы будут подтягивать зависимости.

Выводы

OpenSSL 4.0 — релиз не столько про новые фичи, сколько про дочистку хвостов. За четыре с половиной года команда вывела из эксплуатации несколько слоёв устаревшего API и зафиксировала архитектуру providers как единственный способ подключать внешнюю криптографию. Цена — несовместимость по исходникам и ABI. На 15 апреля 2026 года крупные пакеты Debian, Ubuntu, RHEL и Fedora ещё линкуются с 3.x; пересборка экосистемы займёт месяцы, а для продуктов на engines (HSM-адаптеры, gost-engine, старые PKCS#11-драйверы) — ещё дольше.

Практический совет: если у вас нет конкретной нужды в ECH или SM2+ML-KEM-768, ближайший год можно спокойно сидеть на 3.5 LTS и следить за тем, как пересобираются ваши зависимости. Когда пакетные менеджеры дистрибутивов начнут подтягивать 4.0 автоматически — это и будет момент серьёзной миграции.

Полный changelog, downloadable tarballs и ключи для проверки подписи — на странице релиза на GitHub. Сам файл CHANGES.md — хорошее чтение на вечер для всех, кто хоть раз линковал с OpenSSL.