OpenSSL

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

Содержание

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

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

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

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

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

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

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

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

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 внесены изменения
  2. Another Face to Face: Email Changes and Crypto Policy
  3. Рефакторинг – изменение исходного кода программы без изменения его внешнего поведения. В экстремальном программировании и других гибких методологиях рефакторинг является неотъемлемой частью цикла разработки ПО: разработчики попеременно то создают новые тесты и функциональность, то выполняют рефакторинг кода для улучшения его логичности и прозрачности.
  4. В OpenSSL исправлены две уязвимости