OpenSSL под капотом: как я попал в LFX Mentorship

Как я попал в LFX Mentorship и при чём тут OpenSSL

Помню, как утром проверил почту и увидел тему письма: «Congratulations LFX Mentorship». Перечитал дважды, прежде чем осознал. Из всех подавших заявки взяли меня — работать над CBOMKit, проектом, который я лишь смутно понимал несколько недель назад, когда впервые прочитал о пост-квантовой криптографии и подумал: «Погодите, всю нашу нынешнюю шифровку когда-нибудь взломают?» Огромное спасибо Адитье Коранге (моему ментору) за выбор.

Это был один из лучших дней в году. Не потому, что менторства редки — их много. А потому что это менторство было конкретным. Я читал про PQC из чистого любопытства, без подсказок с занятий — и вдруг получил ментора, реальный код и настоящую задачу вместо статей.

Этот пост — о том, что это за задача, что я узнал и чего пока не понимаю. Честно: много чего.

Что я думал про OpenSSL и что это на самом деле

До начала я искренне считал OpenSSL одной библиотекой с одной задачей. Оказалось, это четыре отдельных части, которые просто путешествуют вместе:

• libcrypto — математика (хеши, цифровые подписи, шифры);
• libssl — построена поверх libcrypto для TLS и DTLS (например, шифрование звонков в Zoom);
• командная строка;
• EVP API — современный интерфейс, который стоит использовать в серьёзных кодовых базах, отчасти потому что он спроектирован с поддержкой пост-квантовых алгоритмов.

Есть ещё BoringSSL — форк OpenSSL, созданный Google после Heartbleed в 2014 году. Google хотел более лёгкий и агрессивно обновляемый набор примитивов, без поддержки устаревшего кода. Chrome работает на BoringSSL. Bun — тоже. Node.js по-прежнему использует OpenSSL напрямую, и последние версии поддерживают пост-квантовые алгоритмы через OpenSSL 3.5+.

Где OpenSSL живёт в реальном мире

Всё стало понятно, когда я увидел, где OpenSSL тихо сидит внутри привычных инструментов:

• Nginx — для TLS и Server Name Indication (один сервер, много сертификатов);
• PostgreSQL — шифрует трафик между БД и клиентом, плюс расширение pgcrypto для шифрования внутри БД;
• JWT-библиотеки — используют OpenSSL для HMAC-подписи.

Ничего удивительного, но раньше я об этом не задумывался.

Что я долго не мог оценить

Java-крипто-API чисты: Cipher.getInstance("AES") — и всё. OpenSSL — полная противоположность. Одна и та же операция может быть размазана по структуре, макросу и вызову инициализации в трёх строках, иногда в разных функциях.

Когда я услышал, что наш детектор может пропустить часть реального использования, потому что информация не лежит в одном очевидном месте — это был не гипотетический вопрос. Никто в команде не может сказать, какая часть OpenSSL API покрыта. Теперь это моя работа на ближайшие две недели. И мне это нравится.

Есть и приземлённая проблема: OpenSSL 3.6 изменил структуру заголовочных файлов, сломав наивное разрешение путей. C/C++ часть просто не находила нужные заголовки. Исправление — перенаправление на системные заголовки OpenSSL — звучит просто, но потребовало реальной отладки.

Где мы сейчас

Поддержка C/C++ интегрирована в sonar-cryptography. Модуль обнаружения OpenSSL уже работает и даёт осмысленное покрытие для существующих правил. Полного покрытия всех возможностей OpenSSL пока нет. Юнит-тесты есть, но только для написанных правил — так что покрытие тестов отражает покрытие правил.

Мы сознательно не поддерживаем старые версии OpenSSL. Узкий фокус важнее попыток объять необъятное.

Моя реальная задача сейчас

Первая задача звучит обманчиво просто: найти реальные открытые C/C++ проекты, использующие OpenSSL, и протестировать на них наш плагин.

Звучит легко, пока не поймёшь, что цель — не просто запустить сканер. Nginx, PostgreSQL, curl, OpenSSH, HAProxy, Apache httpd, Redis, OpenVPN, Postfix — кандидаты. Нужно найти те, что нагружают разные углы API: X.509, HMAC, EVP-шифры, DTLS. Для каждого записать: legacy или EVP API, размер кодовой базы, почему это полезный тест.

Маленький практический трюк: клонируйте репозиторий одной веткой, а не полным зеркалом. Кто-то ранее зеркалировал OpenSSL — клонирование заняло больше 30 минут. Одна ветка (лучше shallow) решает проблему.

После составления списка начинается работа: запускаю плагин на каждом проекте, затем вручную ищу реальные вызовы OpenSSL (EVP_*, SSL_CTX_*, RSA_*, HMAC_*) и сравниваю с отчётом инструмента. Совпадения — хорошо, расхождения — пробелы, которые нужно заметить. Всё записываю в простую таблицу: проект, используемые API, что обнаружено, примечания. Медленная, негламурная работа. Но именно она превращает «покрытие» из расплывчатого слова в конкретное число.

После того как PR с детектором OpenSSL будет принят, я подключу его к cbomkit-lib — чтобы модуль C/C++ правильно разрешал зависимости и мог подавать C/C++ исходники через in-memory сервер. Для C/C++ это сложнее, чем для Java или Python: нужен контекст сборки (compile commands, include paths) для корректного парсинга.

Параллельно разворачиваю полный SonarQube через Docker, устанавливаю плагин и прогоняю на одном из проектов (скорее всего, Nginx или curl). Это отдельный путь от cbomkit-lib, хотя движок обнаружения общий — нужно проверить оба.

Чего я ещё не знаю

Не знаю, сколько пробелов мы найдём, когда начну тестировать реальные проекты. Может, пару, может, много. Честно, судя по разбросанности конфигураций OpenSSL, их будет больше, чем хотелось бы.

Есть и долгосрочная цель. Ментор прислал статью BF-CBOM из Университета Берна: авторы запустили несколько CBOM-генераторов на одних и тех же кодовых базах — и они почти не совпали. Неудобный результат для разработчика таких инструментов, но именно такие честные результаты мы хотели бы вносить сами. Статей по CBOM-инструментам пока мало — это реальная ниша, которую стоит попробовать заполнить до конца менторства.

Но пока моя задача проще и конкретнее: найти проекты, запустить тесты, записать, что правда, а не что мы предполагали.

Я напишу об этом в любом случае.