Если вы отдаёте HTTPS, ваш сервер почти наверняка работает на OpenSSL (или совместимой реализации). Вы никогда не касаетесь его напрямую, но когда в нём находят уязвимость, затронутыми оказываются огромное число серверов. Разберём, что делает эта библиотека и как её защищать.
Где он используется
Каверзность OpenSSL в том, что вы используете его, ни разу его не выбрав. Ваше приложение делегирует TLS веб-серверу, веб-сервер делегирует криптографию OpenSSL, а этот OpenSSL поставляется с ОС; получается вложенный стек.
Обычно это удобно: криптографию доверяют общей реализации, написанной экспертами. Но когда в этой общей библиотеке есть уязвимость, все, кто её использует, оказываются под ударом разом. Вот что значит, что у изъяна в фундаментальной библиотеке широкие последствия.
OpenSSL, SSL/TLS и сертификаты
Названия звучат похоже, поэтому их путают, но у каждого своя роль.
| Термин | Что это | Пример |
|---|---|---|
| SSL / TLS | Правила (протокол) шифрования соединения. SSL — старая версия; сегодня используют TLS 1.2 / 1.3 | HTTPS — это HTTP, обёрнутый в TLS |
| OpenSSL | Программа (библиотека), которая фактически выполняет TLS и криптографические операции, плюс входящий в комплект инструмент командной строки | Nginx и Apache вызывают её внутри |
| Сертификат | Данные, в которых удостоверяющий центр подтверждает, что вы владеете доменом. Содержит открытый ключ | Let's Encrypt выдаёт их бесплатно |
Итак, OpenSSL — один из инструментов, реализующих правила TLS, а сертификат — данные, которые этот инструмент использует при соединении. TLS реализуют и другие библиотеки (LibreSSL, BoringSSL, Windows Schannel и другие), и какая из них используется, зависит от ОС и ПО.
Почему последствия так широки: один баг поставил под угрозу ключи множества серверов
Heartbleed 2014 года (CVE-2014-0160) возник из небольшой ошибки реализации в OpenSSL (доверие к заявленной длине без её проверки), которая позволяла постороннему понемногу читать память сервера — а в ней могли оказаться приватные ключи и данные сессий. Поскольку OpenSSL использовался настолько широко, огромное число серверов по всему миру стало мишенями одновременно (полная история → Heartbleed).
Урок ясен: чем ниже в стеке находится зависимость, тем шире последствия. Так что дело не только в зависимостях, которые ваше приложение импортирует напрямую, — фундаментальные библиотеки вроде OpenSSL, работающие внизу, заслуживают той же серьёзности в мониторинге и патчах.
Как защищаться: избегайте EOL, мониторьте фундаментальные библиотеки
Знайте, какой OpenSSL использует ваш стек
Нельзя защитить то, чего не видишь. Составьте инвентарь, от какого OpenSSL (линия выпусков и версия) зависят ваши серверы, базовые образы контейнеров и среды выполнения языков.
Не работайте на версиях с истёкшей поддержкой (EOL)
Как только линия выпусков выходит из поддержки, новые найденные в ней уязвимости уже не исправляются. Если продолжать работать на EOL, уязвимости остаются неисправленными даже после их обнаружения. Планируйте переход на поддерживаемую линию.
Включайте фундаментальные библиотеки в мониторинг CVE
Зависимости приложения легко отслеживать с помощью osv-scanner и подобных инструментов, но поставляемый с ОС OpenSSL легко упустить. Убедитесь, что новые CVE в фундаментальных библиотеках тоже всплывают (→ плейбук по устранению CVE).
Патчите без промедления, когда дело серьёзное
Баги уровня Heartbleed атакуют в момент раскрытия. Держите путь обновления достаточно лёгким, чтобы фундаментальные патчи можно было выкатить в тот же день, когда того требует серьёзность, — а не «при следующем плановом обновлении».
Поддерживаемые версии (на октябрь 2026 года)
Проект OpenSSL выпускает версию с долгосрочной поддержкой (LTS) в апреле нечётных лет и поддерживает её не менее пяти лет. Версии без LTS, выпущенные после 3.5, поддерживаются 13 месяцев с момента выпуска.
| Линия | Тип | Окончание поддержки |
|---|---|---|
| 4.0 | Обычная | 14 мая 2027 |
| 3.6 | Обычная | 1 ноября 2026 |
| 3.5 | LTS | 8 апреля 2030 |
| 3.4 | Обычная | 22 октября 2026 |
| 3.0 / 1.1.1 / 1.0.2 | — | Завершена (только платная расширенная поддержка от OpenSSL Corporation) |
С OpenSSL, поставляемым вашей ОС, ситуация другая. Многие дистрибутивы Linux, в том числе основанные на Red Hat, включают исправления, не повышая номер версии (бэкпортирование). В течение срока поддержки ОС пакет, который по-прежнему показывает 3.0, может продолжать получать исправления от вендора ОС. Не судите «старое — значит уязвимое» или «новое — значит безопасное» только по номеру; сверяйтесь с бюллетенями безопасности вендора ОС.
Как проверить свою среду
Проверьте OpenSSL в ОС
openssl version -a, чтобы увидеть версию. Версию пакета покажет dpkg -l 'libssl*' openssl в Debian/Ubuntu или rpm -q openssl в системах на основе Red Hat. Сравните версию пакета с бюллетенями безопасности вендора ОС, чтобы понять, включено ли исправление.Проверьте, что фактически используют приложения
nginx -V для Nginx, python3 -c "import ssl; print(ssl.OPENSSL_VERSION)" для Python и node -p process.versions.openssl для Node.js.Проверьте и образы контейнеров
Подпишитесь на объявления безопасности OpenSSL
Как читать серьёзность уязвимостей
Проект OpenSSL сам оценивает свои уязвимости по четырём уровням и в зависимости от этого меняет способ выпуска исправлений.
| Серьёзность | Примерный смысл | Как выпускается исправление |
|---|---|---|
| Critical | Затрагивает распространённые конфигурации и легко эксплуатируется (значительная утечка памяти сервера, кража приватных ключей и т. п.) | Исправление сразу выпускается для всех поддерживаемых версий |
| High | Менее рискованно, чем Critical, но всё же серьёзно (менее распространённые конфигурации, только клиентская сторона и т. п.) | Готовится закрыто, затем выпускается для всех поддерживаемых версий |
| Moderate | Ограничено отказом в обслуживании, редкими протоколами и т. п. | Включается в следующий плановый выпуск |
| Low | Только инструменты командной строки, маловероятные сочетания условий и т. п. | Включается в следующий плановый выпуск |
Изъян вроде Heartbleed, при котором память сервера можно читать извне, соответствует определению Critical. Для Critical и High начинайте готовить обновление, как только увидите предварительное уведомление.
Наш взгляд: мониторьте фундаментальные библиотеки машинами
Уязвимости фундаментальных библиотек нельзя отслеживать на человеческой памяти. Этот сайт держит собственные зависимости и фундаменты под машинным мониторингом CVE. Сертификаты, которые вы отдаёте через Let's Encrypt, всё равно прогоняют свою криптографию через реализацию из семейства OpenSSL внизу, поэтому составить список фундаментальных библиотек, о которых вы обычно не думаете, и мониторить их — самый прямой способ предотвратить инциденты с широкими последствиями.
Читать дальше
- Учитесь на инциденте: Heartbleed (изъян в OpenSSL, поставивший под угрозу приватные ключи множества серверов)
- По теме: Что такое Let's Encrypt (бесплатные TLS-сертификаты + автопродление) / Глоссарий: Что такое CVE
- На практике: плейбук по устранению CVE / мониторинг зависимостей с osv-scanner
Источники (первичные)
- OpenSSL Library, «Release Strategy» — openssl-library.org (политика LTS, даты окончания поддержки каждой линии)
- OpenSSL Library, «Security Policy» — openssl-library.org (четыре уровня серьёзности, предварительное уведомление)
- Red Hat, «Backporting Security Fixes» — access.redhat.com (почему по одному номеру версии нельзя понять, уязвимы ли вы)
- NIST NVD, «CVE-2014-0160» — nvd.nist.gov (Heartbleed)