Безопасность интернет-соединений сегодня является одной из ключевых проблем, стоящих перед разработчиками и пользователями. Одним из краеугольных камней обеспечения защищенных коммуникаций являются TLS-библиотеки, а наиболее распространенной среди них исторически остается OpenSSL. Однако за годы существования OpenSSL породил множество форков, имеющих собственные особенности и сферы применения. Расскажем о семи основных форках OpenSSL и о влиянии, которое они оказывают на экосистему интернет-безопасности и проекты вроде curl. Истоки и развитие первоначальной библиотеки начались с SSLeay, которая появилась в середине 1990-х годов и стала первопроходцем в реализации SSL-технологий.
Именно на базе SSLeay был добавлен первый HTTPS-поддерживаемый функционал в популярный утилитарный инструмент curl. SSLeay поддерживал только SSL, а уже позже к этому протоколу добавилась поддержка TLS, причем SSLeay уходила на второй план в пользу более развиваемого форка — OpenSSL. OpenSSL возник в конце 1998 года как прямой наследник SSLeay и фактически заменил его. С самого начала OpenSSL выделялся своим огромным и весьма неоднородным API, что создавало затруднения для пользователей и разработчиков. Документация по OpenSSL всегда оставляла желать лучшего, и часто требовалось глубоко погружаться в исходный код, чтобы разобраться во всех тонкостях применения.
Несмотря на подобные сложности, OpenSSL долгое время удерживал статус ведущей TLS-библиотеки в опенсорс-пространстве, однако в последние годы встречается критика, связанная с производительностью и медленным внедрением современных возможностей протоколов, например поддержки QUIC и ECH. В 2014 году с появлением уязвимости Heartbleed произошел раздел основной ветви OpenSSL — породился форк LibreSSL. Его создатели поставили целью очистить библиотеку от ненужных и устаревших компонентов, облегчить кодовую базу и улучшить безопасность. LibreSSL со временем стал основой TLS-библиотеки, используемой Apple для macOS, что помогло популяризировать и расширить использование этого форка. Тем не менее, LibreSSL часто отставал в плане внедрения новейших технологий вроде QUIC, поддержки SSLKEYLOGFILE и ECH, но при этом успешно работал в проектах вроде curl с момента своего создания.
Параллельно с LibreSSL в те же самые Heartbleed-дни Google создал другой форк — BoringSSL. Этот проект был рассчитан в первую очередь на нужды компании Google и ее продуктов, таких как Android. BoringSSL отличается чистотой кода, аккуратным управлением типами и активным продвижением нового API поддержки протокола QUIC, который был внедрен значительно раньше, чем у других форков. Несмотря на отсутствие официальных релизов и общественного управления проектом, BoringSSL стал образцом для современных реализаций TLS-библиотек, и curl с момента его появления отлично с ним взаимодействует. Менее известен AmiSSL — специализированный форк OpenSSL, адаптированный для работы в операционной системе AmigaOS.
Он представляет собой в основном порт OpenSSL с минимальными изменениями, позволяя использовать функционал TLS на нишевой платформе. Несмотря на скромную востребованность, AmiSSL дополняет картину многообразия форков и расширяет географию применения семейства OpenSSL. В начале 2020-х годов разочарование относительно медлительности основной ветви OpenSSL в плане запуска QUIC API привело к созданию еще одного форка — QuicTLS. Этот проект был инициирован Microsoft и Akamai и представлял собой легковесное ответвление с самой собой задачей внедрения поддержки QUIC, стараясь оставаться максимально близким к исходным кодам OpenSSL. Однако с выходом версии OpenSSL 3.
5, которая представила свой уникальный QUIC API, QuicTLS был вынужден пересмотреть свои планы относительно дальнейшего развития, и ситуация еще остается в стадии формирования. Отдельное внимание заслуживает AWS-LC — форк, созданный на базе BoringSSL и поддерживаемый Amazon. В отличие от Google, Amazon придерживается политики частых и официальных релизов, делая AWS-LC более доступным и предсказуемым для внешних пользователей. Задачей AWS-LC является создание надежной и безопасной криптографической библиотеки, оптимизированной для эксплуатации в облачных сервисах AWS, при этом сохраняя совместимость и расширяя функционал. Последние бенчмарки демонстрируют значительное превосходство AWS-LC над OpenSSL по производительности, что подчеркивает успехи проекта и его актуальность для промышленного использования.
Проект поддерживается curl с начала 2023 года. Поддержка столь разнообразных форков в curl — не простая задача. Каждый из них обладает своими особенностями API и функциональными различиями, что требует постоянного ухода за состоянием кода. В curl это реализовано через использование единой кодовой базы, в которой применяются многочисленные условные компиляции. По словам разработчика Daniel Stenberg, они активно проверяют возможности каждого форка при помощи непрерывной интеграции, хотя и с ограниченным набором версий.
Несмотря на некоторое сращивание и отличия, пока что существует пограничная совместимость, хотя в будущем возможно потребуется более серьезная работа над архитектурой для учёта глубокой диверсификации форков. Сложившаяся ситуация, когда вокруг OpenSSL существует своеобразное «семейство форков», отражает тенденции современного развития программного обеспечения с открытым исходным кодом, где проекты растут и разделяются, чтобы лучше удовлетворять индивидуальные требования и заказчиков. Однако это порождает вопросы об эффективности дублирования усилий и расходах на поддержку множества веток. Одновременно подобное разнообразие расширяет выбор и позволяет использовать библиотеку, максимально подходящую под конкретные задачи и инфраструктуру. В качестве резюме можно сказать, что OpenSSL и его многочисленные форки продолжают играть критическую роль в формировании экосистемы интернет-безопасности.
