OpenSSL

Продукт

Дата последнего релиза:	2023/03/015
Технологии:	ИБ - Средства шифрования

Содержание

2023
- OpenSSL 3.1.0 с реализацией протоколов SSL/TLS
- Устранение ошибки раскрытия памяти
2022
2021
- Устранена критическая уязвимость переполнения буфера
- Интеграция мультилинейного режима шифрования MGM в OpenSSL
2018
- OpenSSL 1.1.1
- В политики шифрования openssl внесены изменения
2017: OpenSSL 1.0.2n
OpenSSL 2.3.0
OpenSSL 1.0.0
Примечания

РЕШЕНИЕ НА БАЗЕ (1)

СМ. ТАКЖЕ (32)

Основные статьи:

2023

OpenSSL 3.1.0 с реализацией протоколов SSL/TLS

После полутора лет разработки состоялся релиз библиотеки OpenSSL 3.1.0 с реализацией протоколов SSL/TLS и различных алгоритмов шифрования. Об этом стало известно 15 марта 2023 года. Поддержка OpenSSL 3.1 будет осуществляться до марта 2025 года. Поддержка прошлых веток OpenSSL 3.0 и 1.1.1 продлится до сентября 2026 года и сентября 2023 года соответственно. Код проекта распространяется под лицензией Apache 2.0.

Основные изменения OpenSSL 3.1.0:

В модуле FIPS реализована поддержка криптографических алгоритмов, соответствующих стандарту безопасности FIPS 140-3. Начат процесс сертификации модуля для получения сертификата соответствия требованиям FIPS 140-3. До завершения сертификации после обновления OpenSSL до ветки 3.1 пользователи могут продолжить использование модуля FIPS, сертифицированного для FIPS 140-2. Из изменений в данной версии модуля отмечается включение алгоритмов Triple DES ECB, Triple DES CBC и EdDSA, которые пока не проверены на соответствия требованиям FIPS. Также в новой версии внесены оптимизации для повышения производительности и осуществлён переход на запуск внутренних тестов при каждой загрузке модуля, а не только после установки.
Переработан код OSSL_LIB_CTX. Обновленный вариант избавлен от излишних блокировок и позволяет добиться более высокой производительности.
Повышена производительность фреймворков кодировщика и декодировщика.
Проведена оптимизация производительности, связанная с использованием внутренних структур (хеш-таблиц) и кэшированием.
Повышена скорость генерации RSA-ключей в режиме FIPS.
Для различных процессорных архитектур в реализации алгоритмов AES-GCM, ChaCha20, SM3, SM4 и SM4-GCM внесены специфичные ассемблерные оптимизации. Например, код AES-GCM ускорен при помощи инструкций AVX512 vAES и vPCLMULQDQ.
В KBKDF (Key Based Key Derivation Function) добавлена поддержка алгоритма KMAC (KECCAK Message Authentication Code).
Различные функции "OBJ_*" адаптированы для использования в многопоточном коде.
Добавлена возможность использования для генерации псевдослучайных чисел инструкции RNDR и регистров RNDRRS, доступных в процессорах на базе архитектуры AArch64.
Переведены в разряд устаревших функции OPENSSL_LH_stats, OPENSSL_LH_node_stats, OPENSSL_LH_node_usage_stats, OPENSSL_LH_stats_bio, OPENSSL_LH_node_stats_bio и OPENSSL_LH_node_usage_stats_bio. Объявлен устаревшим макроc DEFINE_LHASH_OF^[1].

Устранение ошибки раскрытия памяти

OpenSSL устранила ошибку раскрытия памяти, обновить ПО нужно как можно скорее. Об этом стало известно 10 февраля 2023 года.

Всего исправлено 8 уязвимостей, позволявших злоумышленникам совершать вредоносные действия на скомпрометированных устройствах.«Вторые глаза» инспектора 4.1 т

Разработчики OpenSSL выпустили исправления для целого ряда уязвимостей, включая серьезную ошибку в инструментарии шифрования. Данная ошибка потенциально могла подвергнуть пользователей вредоносным атакам.

Уязвимость CVE-2023-0286 относится к разновидности «Type Confusion» («путаница типов»), которая может позволить злоумышленнику считывать содержимое памяти или вызывать отказ в обслуживании», — говорится в сообщении представителей OpenSSL.

В большинстве случаев атака требует, чтобы злоумышленник предоставил как цепочку сертификатов, так и CRL, ни один из которых не должен иметь действительной подписи. Если злоумышленник контролирует только один из этих входов, другой вход должен уже содержать адрес X.400 в качестве точки распространения CRL, — добавили в OpenSSL.

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

Проблема была исправлена в версиях OpenSSL 3.0.8, 1.1.1t и 1.0.2zg. Другие уязвимости, устраненные в рамках последних обновлений, включают: CVE-2022-4203 , CVE-2022-4304 , CVE-2022-4450 , CVE-2023-0215 , CVE-2023-0216 , CVE-2023-0217 , CVE-2023-0401 .

Успешное использование вышеуказанных уязвимостей может привести к сбою приложения, раскрытию содержимого памяти и даже восстановлению сообщений, отправленных по сети открытым текстом^[2].

2022

Устаревшая версия OpenSSL в прошивках Dell, HP и Lenovo ставит под удар цепочки поставок

Анализ прошивки от Dell, HP и Lenovo выявил наличие устаревших версий криптографической библиотеки OpenSSL, что создает дополнительные риски для цепочек поставок. Об этом стало известно 28 ноября 2022 года. Подробнее здесь.

Последние патчи для OpenSSL исправили две уязвимости, которые опаснее SSL Heartbleed

Последние патчи для OpenSSL исправили две уязвимости, которые опаснее SSL Heartbleed. Об этом стало известно 7 июля 2022 года.

Одну из них обнаружил обычный китайский студент.

Первая уязвимость, отслеживаемая как CVE-2022-2274 , была обнаружена аспирантом университета Сидянь 22 июня 2022 года. В своем последнем сообщении разработчики назвали CVE-2022-2274 серьезной ошибкой в реализации RSA и подтвердили, что уязвимость можно использовать для удаленного выполнения вредоносного кода на устройстве, выполняющем вычисления.

Вторая уязвимость, отслеживаемая как CVE-2022-2097, может привести к утечке данных при шифровании с помощью AES-OCB. В специальных инструкциях ускорения AES от Intel была допущена ошибка, которая при шифровании N блоков данных выполняет цикл не от 1 до N, а от 1 до N-1. Это означает, что последний блок данных не будет зашифрован и останется в исходном виде.

Обе уязвимости исправлены в последних версиях OpenSSL, поэтому разработчики проекта рекомендуют пользователям как можно скорее применить выпущенные обновления^[3].

QNAP предупредила об уязвимости бесконечного цикла в OpenSSL

Некоторые сетевые устройства хранения данных (NAS) тайваньской компании QNAP подвержены уязвимости бесконечного цикла в криптографической библиотеке OpenSSL с открытым исходным кодом. Подробнее здесь.

Уязвимость в OpenSSL могла привести к сбою в работе удаленных серверов

Разработчики OpenSSL выпустили исправление для опасной уязвимости в своей программной библиотеке. Ее эксплуатация позволяла злоумышленникам вызвать состояние «отказа в обслуживании» (DoS) при анализе сертификатов. Об этом стало известно 17 марта 2022 года.

Уязвимость (CVE-2022-0778) получила оценку в 7,5 балла по шкале CVSS и связана с синтаксическим анализом искаженного сертификата с недопустимыми явными параметрами эллиптической кривой, что приводит к так называемому «бесконечному циклу». Проблема заключается в функции под названием BN_mod_sqrt(), которая используется для вычисления модульного квадратного корня.

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

На март 2022 года нет никаких свидетельств того, что уязвимость использовалась в реальных атаках. Проблема затрагивает версии OpenSSL 1.0.2, 1.1.1 и 3.0 и была устранена в версиях OpenSSL 1.0.2zd (для клиентов с премиальной поддержкой), 1.1.1n и 3.0.2. Версия OpenSSL 1.1.0 также подвержена уязвимости, однако не получит исправления в связи с окончанием срока поддержки^[4].

Доступность TLS версии 1.3

14 марта 2022 года компания «Криптонит» сообщила о том, что ее специалисты совместно с сотрудниками компании «КриптоКом» завершили разработку открытой реализации протокола TLS версии 1.3, обеспечивающего защиту данных с использованием российских криптографических алгоритмов. Она доступна как расширение для OpenSSL 1.1.1. Подробнее здесь.

OpenSSL 3.0 получил статус LTS

Проект OpenSSL объявил о долгосрочной поддержке ветки криптографической библиотеки OpenSSL 3.0, выпуск обновлений для которой будет формироваться в течение 5 лет со дня релиза, т.е. до 7 сентября 2026 года. Предыдущая LTS-ветка 1.1.1 будет поддерживаться до 11 сентября 2023 года. Об этом стало известно 4 марта 2022 года.

Иллюстрация: govinfosecurity.com

Дополнительно можно отметить выпуск проектом OpenBSD переносимой редакции пакета LibreSSL 3.5.0, в рамках которого развивается форк OpenSSL, нацеленный на обеспечение более высокого уровня безопасности. Из изменений в представленной версии выделяется портирование из OpenSSL поддержки RFC 3779 (расширения X.509 для IP-адресов и автономных систем) и механизма Certificate Transparency (независимый публичного лога всех выданных и отозванных сертификатов, который даёт возможность проводить независимый аудит всех изменений и действий удостоверяющих центров, и позволяет сразу отслеживать любые попытки скрытого создания поддельных записей). Значительно улучшена совместимость с OpenSSL 1.1 и задействованы идентичные с OpenSSL имена шифров для TLSv1.3. Многие функции переведены на использование calloc. В libssl и libcrypto добавлена большая порция вызовов.^[5]

2021

Устранена критическая уязвимость переполнения буфера

Проект OpenSSL, занимающийся разработкой одноимённой криптографической библиотеки, объявил об исправлении одной критической и одной среднеопасной уязвимости в своём программном коде. Информация об этом появилась 1 сентября 2021 года.

Открытая библиотека OpenSSL используется во множестве веб-серверов и в большинстве сайтов, поддерживающих HTTPS. Уязвимость позволяет злоумышленнику вызвать ошибку переполнения буфера: для этого нужно подать на приложение для расшифровки контент, зашифрованный алгоритмом SM2; эти данные могут переполнить выделенный буфер памяти - как максимум, на 62 байта; тем самым может изменяться контент других данных, расположенных за этим буфером, что в теории может привести к изменению поведения приложения или его выходу из строя.

Расположение буфера зависит от приложения, но, как правило, он находится в куче - структуре данных, с помощью которой реализована динамически распределяемая память приложения.

Уязвимость, выявленная экспертом по имени Джон Оуянь (John Ouyang), получила индекс CVE-2021-3711. Ей присвоен критический индекс - 9,8 балла по шкале CVSS. Проблема устранена в версии OpenSSL 1.1.1l.

«Переполнение буфера - весьма типичная ошибка в программировании, встречающаяся повсеместно и регулярно в программных разработках любого уровня, - пояснил Дмитрий Кирюхин, эксперт по информационной безопасности компании SEC Consult Services. - Другое дело, что OpenSSL - чрезвычайно распространённая библиотека, вследствие чего тривиальный «баг» превращается в проблему для большей части интернета».

Кроме этого, разработчики проекта OpenSSL устранили ещё одну, менее опасную уязвимость, обозначенную как CVE-2021-3712. Этот «баг» позволяет раскрывать конфиденциальное содержимое памяти (в том числе, приватные ключи) или вызывать сбой приложения.

Уязвимость затрагивает версии 1.1.1-1.1.1k, а также 1.0.2-1.0.2y; исправления внесены в версиях 1.1.1j и 1.0.2za, соответственно.^[6]

Интеграция мультилинейного режима шифрования MGM в OpenSSL

Совместными усилиями «Криптоком» и «Криптонит» на базе OpenSSL 1.1.1 создана реализация с открытым исходным кодом, покрывающая все актуальные российские алгоритмы шифрования и режимы их использования. Об этом 16 июня 2021 года сообщили в НПК «Криптонит». Подробнее здесь.

2018

OpenSSL 1.1.1

11 сентября 2018 года организация OpenSSL Project анонсировала выход OpenSSL 1.1.1 – очередной версии библиотеки с продолжительным сроком поддержки (Long Term Support, LTS).

По словам представителей организации, самой главной появившейся функцией в OpenSSL 1.1.1 является версия протокола TLS 1.3. Поскольку OpenSSL 1.1.1 соответствует OpenSSL 1.1.0 по API и ABI, приложения, работающие со старой версией, могут обновиться до версии OpenSSL 1.1.1 и использовать все преимущества TLS 1.3.

OpenSSL 1.1.1 получила полностью переписанный генератор случайных чисел, поддержку нескольких криптографических алгоритмов, улучшенный механизм для отражения атак по сторонним каналам, поддержку расширения Maximum Fragment Length TLS и модуль STORE, обеспечивающий единый ридер на основе URI для хранилищ сертификатов, ключей, списков аннулированных сертификатов (CRL) и других объектов. Алгоритмы шифрования включают в себя SHA3, SHA512/224 и SHA512/256, EdDSA, X448, multi-prime RSA, SM2, SM3, SM4, SipHash и ARIA.

Как сообщили в OpenSSL Project, версия OpenSSL 1.1.1 будет поддерживаться в течение как минимум пяти лет. Версия 1.1.0 получит один год поддержки, начиная с 11 сентября 2018 года. Ветка 1.0.2, до недавнего времени являвшаяся LTS-релизом, будет полностью поддерживаться до конца 2018 года, а затем до конца 2019 года будет получать только обновления безопасности.^[7]

В политики шифрования openssl внесены изменения

По результатам прошедшей в начале 2018 года в Лондоне встречи Комитета управления OpenSSL (OMC) было объявлено о внесении изменений в политики шифрования. В частности, разработчики OpenSSL отключат по умолчанию незащищенные конфигурации^[8]^[9].

OMC решил, что нужно добавить возможность отключения новых алгоритмов в процессе компиляции, а новые алгоритмы шифрования должны взаимодействовать с OpenSSL только через EVP (цифровая библиотека EnVeloPe) API.

В будущем каждый новый алгоритм должен быть разработан национальным или международным органом по стандартизации, а для активирования шифров на уровне TLS они должны будут указываться во время выполнения.

Помимо изменений в политиках шифрования, в работу проекта также были внесены другие коррективы. К примеру, было решено отказаться от новостной рассылки для разработчиков (openssl-dev). Одной из причин послужило частое совпадение публикаций, предназначенных для разработчиков и для пользователей (openssl-users). Кроме того, OMC решил сделать GitHub основной площадкой для обсуждения разработок.

Для обсуждения политик OpenSSL была создана отдельная рассылка (openssl-project). Подписаться на рассылку может любой желающий, однако делать публикации могут только OMC и разработчики. Также планируется приложить новые усилия по сокращению сроков для удаления старых задач и рефакторинга кода^[10].

Теперь новые релизы проекта будут выходить каждую неделю по вторникам в случае отсутствия опасных уязвимостей с известными эксплоитами.

2017: OpenSSL 1.0.2n

7 декабря 2017 года OpenSSL Project сообщил о выпуске апдейта OpenSSL 1.0.2n, в составе которого исправление двух уязвимостей.

Проблему в SSL обнаружил Дэвид Бенжамин (David Benjamin), исследователь Google, посредством сервиса Google OSS-Fuzz.

Уязвимость CVE-2017-3737 связана с механизмом «состояния ошибки», представленным в OpenSSL 1.0.2b. Если в случае возникновения фатальной ошибки продолжаются попытки продлить режим согласования протокола, данный механизм вызывает немедленный сбой. Проблема заключается в том, что при непосредственном вызове функций SSL_read() или SSL_write(), механизм не срабатывает должным образом.

Если SSL_read() / SSL_write() впоследствии вызываются приложением для одного и того же объекта SSL, данные будут передаваться в незашифрованном виде непосредственно с уровня записи SSL / TLS.

OpenSSL Project

Поскольку для успешной эксплуатации уязвимости целевое приложение должно содержать ошибку, вызывающую SSL_read() или SSL_write() после возникновения фатальной ошибки, уязвимость отмечена как «средней опасности».

Вторая уязвимость (CVE-2017-3738) связана с переполнением буфера и позволяет атакующему получить доступ к коммуникациям, защищенным с помощью TLS. Выполнить атаку на практике довольно сложно, поэтому уязвимость отмечена как «низкой опасности». Проблема затрагивает ветки OpenSSL 1.0.2 и 1.1.0. Тем не менее, из-за низкой опасности уязвимости ветка 1.1.0 не получила обновление. Проблема будет исправлена с выходом OpenSSL 1.1.0h в свое время^[11].

OpenSSL 2.3.0

Начиная с версии 2.30, в данном стандарте представлены российские криптографические алгоритмы. Для того чтобы токены можно было использовать в программах OpenSSL, компанией "ЛИССИ" разработан специальный lissi_engine, обеспечивающий подключение токенов через их «родные» библиотеки PKCS#11 для стандарта 2.30. Такое подключение практически работает для библиотек eToken GOST, Рутокен ЭЦП и ШИПКА. В отличие от штатного ENGINE ccgost, lissi_engine сам не выполняет никаких криптографических операций, а служит лишь посредником между прикладной программой и библиотекой токена PKCS#11.

Поскольку lissi_engine в своей реализации использует некоторые экспериментальные средства OpenSSL, то для его работы создана специальная версия данной системы – LirSSL2. Новый программный комплекс является дальнейшим развитием традиций, заложенных в известном СКЗИ `LirSSL` компании "ЛИССИ".

Таким образом, lissi_engine позволяет использовать токен в программах OpenSSL в качестве полноценного хранилища ключей и сертификатов. При этом обеспечивается функция генерации ключевой пары самим токеном без возможности извлечения закрытого ключа. Кроме того, обеспечиваются возможности сохранения сертификатов, листания и выборки объектов и т.д.

К сожалению, многие аппаратные токены поддерживают стандарт PKCS#11 лишь частично, накладывая существенные ограничения реализации. Более того, и быстродействие аппаратных токенов зачастую недостаточно высокое. Поэтому компания "ЛИССИ" разработала библиотеку LirCryptoki2, достаточно полно реализующую поддержку стандарта PKCS#11 для программных токенов.

В результате, прикладная программа имеет возможность загрузить два экземпляра lissi_engine, один из которых связан с аппаратным токеном, а другой - с программным. Операции с ключевым материалом на аппаратном токене выполняются аппаратным токеном, а все остальные - программным. Использование такой комбинации обеспечивает как безопасность ключевого материала, так и высокую производительность выполнения тех криптографических операций, которые не требуют доступа к закрытому ключу на аппаратном токене. При этом, все операции производятся через стандартные интерфейсы OpenSSL, что позволяет применять в прикладных программах множество мощных и гибких высокоуровневых функций.

Немаловажной особенностью библиотек компании "ЛИССИ" является их кроссплатформенность. И lissi_engine, и LirCryptoki2 работают и в Windows, и в Linux, как в 32-битных, так и в 64-битных конфигурациях. Поскольку штатные средства OpenSSL сами по себе успешно функционируют на множестве платформ, то и прикладные программы можно также разрабатывать кроссплатформенными.

OpenSSL 1.0.0

Известная программная система OpenSSL обеспечивает широкие возможности использования различных криптографических алгоритмов в прикладных программах. Начиная с версии 1.0.0, OpenSSL поддерживает и российские криптографические алгоритмы (ГОСТ 28147-89, ГОСТ Р34.11-94, ГОСТ Р34.10-2001).

Поддержка тех или иных криптографических алгоритмов осуществляется в OpenSSL 1.0.0 с помощью, так называемых, ENGINE - плагинов, динамически подключаемых к прикладной программе. В составе OpenSSL 1.0.0 имеется специальный ENGINE ccgost, разработанный компанией КриптоКом для поддержки российских криптографических алгоритмов.

Одним из важных вопросов, решаемых при организации информационной безопасности, является способ хранения криптографических ключей. В традиционных программах OpenSSL ключи хранятся в файлах, зашифрованных на пароле. Это означает, что в процессе работы программы ключ расшифровывается и какое-то время присутствует в памяти в открытом виде, что создает возможность его похищения.

Более надежный способ хранения ключевого материала предоставляют аппаратные токены, которые принципиально не отдают ключи наружу, а сами способны генерировать ключи и производить с ними криптографические операции. Для работы с токенами создан специальный международный стандарт PKCS#11 (Cryptoki), определяющий протоколы и интерфейсы взаимодействия программы с токенами.