Перейти к содержимому
>_ITDITDПлатформа веб-безопасности

Глоссарий

Что такое OpenSSL — библиотека под HTTPS и как её защищать

OpenSSL — открытая библиотека, на которой держатся HTTPS (TLS/SSL) и шифрование. Большинство серверов используют её косвенно — через веб-сервер или ОС, — поэтому одна дыра расходится по миру (Heartbleed). Защита: знайте версию, избегайте EOL, мониторьте CVE, патчите быстро.

Опубликовано 2026-06-29 Обновлено 2026-06-29 4 мин чтения

Если вы отдаёте HTTPS, ваш сервер почти наверняка работает на OpenSSL (или совместимой реализации). Вы никогда не касаетесь его напрямую, но его дыры достают до всех — вот что это за фундаментальная библиотека и как её защищать.

Где он расположен — фундамент, который вы «наследуете»

Каверзность OpenSSL в том, что вы используете его, ни разу его не выбрав. Ваше приложение делегирует TLS веб-серверу, веб-сервер делегирует криптографию OpenSSL, а этот OpenSSL поставляется с ОС — вложенный стек.

Ваше приложение
↓ делегирует TLS
Веб-сервер (Nginx / Apache) · среда выполнения языка
↓ делегирует криптографию
OpenSSL (поставляется с ОС)
OpenSSL — нижний «фундамент». Каждый слой выше делегирует криптографию ему — поэтому одна дыра расходится во все из них.

Обычно это благо — криптографию доверяют общей реализации, написанной экспертами. Но когда в этом общем фундаменте есть дыра, все, кто сидит поверх него, оказываются под ударом разом. Вот что значит «у дыры в фундаментальной библиотеке огромный радиус поражения».

Почему это страшно: один баг угрожал ключам по всему миру

Heartbleed 2014 года (CVE-2014-0160) возник из небольшой ошибки реализации в OpenSSL (доверие к заявленной длине без её проверки), которая позволяла постороннему понемногу читать память сервера — а в ней могли оказаться приватные ключи и данные сессий. Поскольку OpenSSL использовался настолько широко, огромное число серверов по всему миру стало мишенями одновременно (полная история → Heartbleed).

Урок прямолинеен: чем фундаментальнее зависимость, тем шире радиус поражения. Так что дело не только в зависимостях, которые ваше приложение импортирует напрямую, — фундаментальные библиотеки вроде OpenSSL, работающие внизу, заслуживают той же серьёзности в мониторинге и патчах.

Как защищаться: избегайте EOL, мониторьте фундамент

1

Знайте, какой OpenSSL использует ваш стек

Нельзя защитить то, чего не видишь. Составьте инвентарь, от какого OpenSSL (линия выпусков и версия) зависят ваши серверы, базовые образы контейнеров и среды выполнения языков.

2

Не работайте на версиях с истёкшей поддержкой (EOL)

Как только линия выпусков выходит из поддержки, новые найденные в ней уязвимости уже не исправляются. Работа на EOL — это оставленная дверь, которую не закроют даже после обнаружения дыры. Планируйте переход на поддерживаемую линию.

3

Включайте фундамент в мониторинг CVE

Зависимости приложения легко отслеживать с помощью osv-scanner и подобных инструментов, но поставляемый с ОС OpenSSL легко упустить. Убедитесь, что новые CVE в фундаментальных библиотеках тоже всплывают (→ плейбук по устранению CVE).

4

Патчите без промедления, когда дело серьёзное

Баги уровня Heartbleed атакуют в момент раскрытия. Держите путь обновления достаточно лёгким, чтобы фундаментальные патчи можно было выкатить в тот же день, когда того требует серьёзность, — а не «при следующем плановом обновлении».

Наш взгляд: следите за фундаментом машинами

Уязвимости фундаментальных библиотек нельзя отслеживать на человеческой памяти. Этот сайт держит собственные зависимости и фундаменты под машинным мониторингом CVE. Сертификаты, которые вы отдаёте через Let's Encrypt, всё равно прогоняют свою криптографию через реализацию из семейства OpenSSL внизу — поэтому инвентаризация «невидимого фундамента» и постановка его под наблюдение — кратчайший путь к предотвращению инцидентов с большим радиусом поражения.

Читать дальше

FAQ

QЯ никогда не устанавливал OpenSSL — мог ли я всё равно его использовать?
A

Почти наверняка да. OpenSSL — фундаментальная библиотека, которую внутри используют веб-серверы (Nginx/Apache), операционные системы и среды выполнения языков. Даже если вы нигде не ссылаетесь на неё в коде, при отдаче HTTPS внизу с высокой вероятностью работает OpenSSL (или совместимая реализация). Допущение «я им не пользуюсь» — ровно то, из-за чего фундаментальные уязвимости остаются незамеченными.

QЧем он отличается от LibreSSL или BoringSSL?
A

Оба — форки OpenSSL. LibreSSL создал проект OpenBSD после Heartbleed, чтобы вычистить кодовую базу; BoringSSL — вариант Google для собственных нужд. Большинству пользователей не нужно выбирать между ними — куда важнее держать ту реализацию, что поставляется с вашей платформой, на поддерживаемой и актуальной версии.

QКак проверить версию или обновить её?
A

На многих системах версию показывает `openssl version`, а обновляют его через пакетный менеджер ОС или пересборкой базового образа контейнера. Главное — не оставаться на версии с истёкшей поддержкой (EOL): как только линия выпусков достигла EOL, новые найденные в ней уязвимости уже не получают исправлений. Отслеживайте фундаментальные зависимости так же, как зависимости своего приложения.