OpenSSL

Продукт
Дата последнего релиза: 2018/09/11
Технологии: ИБ - Средства шифрования

Содержание

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 года будет получать только обновления безопасности.[1]

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

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

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

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

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

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

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

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 в свое время[5].

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), определяющий протоколы и интерфейсы взаимодействия программы с токенами.

Примечания

  1. Новая версия OpenSSL получила поддержку TLS 1.3
  2. В политики шифрования openssl внесены изменения
  3. Another Face to Face: Email Changes and Crypto Policy
  4. Рефакторинг – изменение исходного кода программы без изменения его внешнего поведения. В экстремальном программировании и других гибких методологиях рефакторинг является неотъемлемой частью цикла разработки ПО: разработчики попеременно то создают новые тесты и функциональность, то выполняют рефакторинг кода для улучшения его логичности и прозрачности.
  5. В OpenSSL исправлены две уязвимости