stringtranslate.com

OpenSSL

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

OpenSSL содержит реализацию протоколов SSL и TLS с открытым исходным кодом . Основная библиотека , написанная на языке программирования C , реализует основные криптографические функции и предоставляет различные служебные функции. Доступны оболочки, позволяющие использовать библиотеку OpenSSL на различных языках программирования.

OpenSSL Software Foundation (OSF) представляет проект OpenSSL в большинстве правовых аспектов, включая лицензионные соглашения участников, управление пожертвованиями и т. д. OpenSSL Software Services (OSS) также представляет проект OpenSSL по контрактам на поддержку.

OpenSSL доступен для большинства Unix-подобных операционных систем (включая Linux , macOS и BSD ), Microsoft Windows и OpenVMS .

История проекта

Проект OpenSSL был основан в 1998 году для предоставления бесплатного набора инструментов шифрования для кода, используемого в Интернете. Он основан на форке SSLeay Эрика Эндрю Янга и Тима Хадсона, который неофициально завершил разработку 17 декабря 1998 года, когда Янг и Хадсон оба перешли на работу в RSA Security . Первоначальными членами-основателями были Марк Кокс, Ральф Энгельшалл, Стивен Хенсон, Бен Лори и Пол Саттон. [4]

В 2018 году нумерация версий OpenSSL была пропущена с 1.1.1 до 3.0.0, при этом 2 была исключена из основного номера версии, чтобы избежать конфликта с одним из модулей OpenSSL. Версия 3.0.0 была первой, в которой использовалась лицензия Apache .

По состоянию на май 2019 года [ 5] комитет управления OpenSSL состоял из семи человек [6] , и семнадцать разработчиков [7] имели доступ к коммиту (многие из которых также являются частью комитета управления OpenSSL). Всего двое штатных сотрудников (научных сотрудников), а остальные — волонтеры.

Бюджет проекта составляет менее 1 миллиона долларов США в год, и он в основном полагается на пожертвования. Разработка TLS 1.3 спонсировалась Akamai . [8]

Основные выпуски версий

Алгоритмы

OpenSSL поддерживает ряд различных криптографических алгоритмов:

Шифры
AES , Blowfish , Camellia , ChaCha20 , Poly1305 , SEED , CAST-128 , DES , IDEA , RC2 , RC4 , RC5 , Тройной DES , ГОСТ 28147-89 , [38] SM4
Криптографические хэш-функции
МД5 , МД4 , МД2 , ША-1 , ША-2 , ША-3 , RIPEMD-160 , МДК-2 , ГОСТ Р 34.11-94 , [38] BLAKE2 , Whirlpool , [39] SM3
Криптография с открытым ключом
RSA , DSA , обмен ключами Диффи–Хеллмана , Эллиптическая кривая , X25519 , Ed25519 , X448 , Ed448 , ГОСТ Р 34.10-2001, [38] SM2

( Совершенная прямая секретность поддерживается с использованием эллиптической кривой Диффи-Хеллмана, начиная с версии 1.0. [40] )

Проверка FIPS 140

FIPS 140 — это федеральная программа США по тестированию и сертификации криптографических модулей. Ранний сертификат FIPS 140-1 для OpenSSL FOM 1.0 был отозван в июле 2006 года, «когда возникли вопросы о взаимодействии проверенного модуля с внешним программным обеспечением». Модуль был повторно сертифицирован в феврале 2007 года, прежде чем уступить место FIPS 140-2. [41] OpenSSL 1.0.2 поддерживал использование модуля объектов OpenSSL FIPS (FOM), который был создан для предоставления одобренных FIPS алгоритмов в проверенной среде FIPS 140-2. [42] [43] OpenSSL спорно решила классифицировать архитектуру 1.0.2 как «конец жизненного цикла» или «EOL», вступившую в силу 31 декабря 2019 года, несмотря на возражения, что это была единственная версия OpenSSL, которая в настоящее время была доступна с поддержкой режима FIPS. [44] В результате окончания срока действия лицензии многие пользователи не смогли должным образом развернуть FOM 2.0 и перестали соответствовать требованиям, поскольку не обеспечили расширенную поддержку архитектуры 1.0.2, хотя сама FOM оставалась проверенной еще восемь месяцев.

FIPS Object Module 2.0 оставался проверенным на соответствие FIPS 140-2 в нескольких форматах до 1 сентября 2020 года, когда NIST объявил устаревшим использование FIPS 186-2 для стандарта цифровой подписи и обозначил все несоответствующие модули как «исторические». Это обозначение включает предупреждение федеральным агентствам о том, что они не должны включать модуль в какие-либо новые закупки. Все три проверки OpenSSL были включены в устаревание — OpenSSL FIPS Object Module (сертификат № 1747), [45] OpenSSL FIPS Object Module SE (сертификат № 2398), [46] и OpenSSL FIPS Object Module RE (сертификат № 2473). [47] Многие «частные» проверки на основе OpenSSL и клоны, созданные консультантами, также были перемещены в исторический список, хотя некоторые проверенные FIPS модули с заменой совместимости избежали устаревания, такие как BoringCrypto от Google [48] и CryptoComply от SafeLogic. [49]

Управляющий комитет OpenSSL объявил об изменении схемы управления версиями.

Из-за этого изменения основной номер следующей основной версии удвоился бы, поскольку модуль OpenSSL FIPS уже занимал этот номер. Поэтому было принято решение пропустить номер версии OpenSSL 2.0 и продолжить с OpenSSL 3.0.

OpenSSL 3.0 восстановил режим FIPS и прошел тестирование FIPS 140-2, но со значительными задержками: работа была впервые начата в 2016 году при поддержке SafeLogic [50] [51] [52] и дальнейшей поддержке Oracle в 2017 году, [53] [54], но процесс оказался сложным. [55]

20 октября 2020 года OpenSSL FIPS Provider 3.0 был добавлен в список тестируемых реализаций CMVP, что отражало официальное взаимодействие с испытательной лабораторией для продолжения проверки FIPS 140-2. Это привело к множеству сертификаций в последующие месяцы. [56]

Лицензирование

OpenSSL был лицензирован по двойной лицензии OpenSSL License и SSLeay License, что означает, что могут использоваться условия любой из лицензий. [57] OpenSSL License — это Apache License 1.0, а SSLeay License имеет некоторое сходство с 4-пунктной BSD License . Поскольку OpenSSL License была Apache License 1.0, но не Apache License 2.0, она требует, чтобы фраза «этот продукт включает программное обеспечение, разработанное OpenSSL Project для использования в OpenSSL Toolkit» появлялась в рекламных материалах и любых перераспределениях (разделы 3 и 6 OpenSSL License). Из-за этого ограничения OpenSSL License и Apache License 1.0 несовместимы с GNU GPL . [58] Некоторые разработчики GPL добавили исключение OpenSSL в свои лицензии, которое специально разрешает использование OpenSSL с их системой. GNU Wget и climm используют такие исключения. [59] [60] Некоторые пакеты (например, Deluge ) явно изменяют лицензию GPL, добавляя дополнительный раздел в начало лицензии, документирующий исключение. [61] Другие пакеты используют GnuTLS под лицензией LGPL , Botan под лицензией BSD или NSS под лицензией MPL , которые выполняют ту же задачу.

В августе 2015 года OpenSSL объявила, что от большинства участников потребуется подписать Лицензионное соглашение участника (CLA), и что OpenSSL в конечном итоге будет перелицензирован в соответствии с условиями Apache License 2.0 . [62] Этот процесс начался в марте 2017 года [63] и был завершен в 2018 году [64].

7 сентября 2021 года OpenSSL 3.0.0 был выпущен под лицензией Apache License 2.0. [65]

Известные уязвимости

Отказ в обслуживании: анализ ASN.1

OpenSSL 0.9.6k имеет ошибку, при которой определенные последовательности ASN.1 запускали большое количество рекурсий на машинах Windows, обнаруженную 4 ноября 2003 года. Windows не могла правильно обрабатывать большие рекурсии, поэтому OpenSSL в результате аварийно завершал работу. Возможность отправки произвольно большого количества последовательностей ASN.1 в результате аварийно завершала работу OpenSSL.

Уязвимость сшивания OCSP

При создании рукопожатия клиент мог отправить неправильно отформатированное сообщение ClientHello, что приводило к тому, что OpenSSL анализировал не только конец сообщения. Проект CVE присвоил идентификатор CVE - 2011-0014, это затрагивало все версии OpenSSL от 0.9.8h до 0.9.8q и OpenSSL от 1.0.0 до 1.0.0c. Поскольку анализ мог привести к чтению по неверному адресу памяти, злоумышленник мог вызвать DoS . Также было возможно, что некоторые приложения раскрывают содержимое проанализированных расширений OCSP , что приводило к тому, что злоумышленник мог прочитать содержимое памяти, которая шла после ClientHello. [66]

Уязвимость ASN.1 BIO

При использовании базовых функций ввода/вывода (BIO) [67] или функций на основе FILE для чтения ненадежных данных формата DER , OpenSSL уязвим. Эта уязвимость была обнаружена 19 апреля 2012 года и ей был присвоен идентификатор CVE CVE - 2012-2110. Хотя она не затрагивала напрямую код SSL/TLS OpenSSL, любое приложение, использующее функции ASN.1 (в частности, d2i_X509 и d2i_PKCS12), также не было затронуто. [68]

Атака восстановления открытого текста SSL, TLS и DTLS

При обработке наборов шифров CBC в SSL, TLS и DTLS OpenSSL был обнаружен уязвимым к атаке по времени во время обработки MAC. Надхем Альфардан и Кенни Патерсон обнаружили проблему и опубликовали свои выводы [69] 5 февраля 2013 года. Уязвимости был присвоен идентификатор CVE CVE - 2013-0169.

Предсказуемые закрытые ключи (специфичные для Debian)

Генератор псевдослучайных чисел OpenSSL приобретает энтропию, используя сложные методы программирования. Чтобы инструмент анализа Valgrind не выдавал связанных предупреждений, сопровождающий дистрибутива Debian применил патч к варианту пакета OpenSSL от Debian, который непреднамеренно сломал его генератор случайных чисел, ограничив общее количество секретных ключей, которые он мог сгенерировать, до 32 768. [70] [71] Сломанная версия была включена в выпуск Debian от 17 сентября 2006 года (версия 0.9.8c-1), также скомпрометировав другие дистрибутивы на основе Debian, например Ubuntu . Готовые к использованию эксплойты легко доступны. [72]

Ошибка была сообщена Debian 13 мая 2008 года. В дистрибутиве Debian 4.0 (etch) эти проблемы были исправлены в версии 0.9.8c-4etch3, тогда как исправления для дистрибутива Debian 5.0 (lenny) были предоставлены в версии 0.9.8g-9. [73]

Сердце кровью обливается

Логотип, представляющий жука Heartbleed

OpenSSL версий 1.0.1 по 1.0.1f имеют серьезную ошибку обработки памяти в их реализации расширения TLS Heartbeat, которая может быть использована для раскрытия до 64  КБ памяти приложения с каждым тактовым импульсом [74] [75] ( CVE - 2014-0160). Читая память веб-сервера, злоумышленники могут получить доступ к конфиденциальным данным, включая закрытый ключ сервера . [76] Это может позволить злоумышленникам расшифровать ранее подслушанные сообщения, если используемый протокол шифрования не обеспечивает идеальную прямую секретность . Знание закрытого ключа также может позволить злоумышленнику организовать атаку «человек посередине» против любых будущих сообщений. [ необходима цитата ] Уязвимость также может раскрыть незашифрованные части конфиденциальных запросов и ответов других пользователей, включая сеансовые куки и пароли, что может позволить злоумышленникам перехватить личность другого пользователя сервиса. [77]

На момент раскрытия информации 7 апреля 2014 года считалось, что около 17% или полмиллиона защищенных веб-серверов Интернета , сертифицированных доверенными органами, были уязвимы для атаки. [78] Однако Heartbleed может поражать как сервер, так и клиента.

Уязвимость инъекции CCS

Уязвимость внедрения CCS ( CVE - 2014-0224) - это уязвимость обхода безопасности, которая возникает из-за слабости методов OpenSSL, используемых для создания ключей. [79]

Эта уязвимость может быть использована посредством атаки типа «человек посередине» [80] , в ходе которой злоумышленник может расшифровать и изменить трафик в пути. Удаленный неаутентифицированный злоумышленник может использовать эту уязвимость, используя специально созданное рукопожатие, чтобы заставить использовать слабый ключевой материал. Успешная эксплуатация может привести к состоянию обхода безопасности, в котором злоумышленник может получить доступ к потенциально конфиденциальной информации. Атака может быть выполнена только между уязвимым клиентом и сервером.

Клиенты OpenSSL уязвимы во всех версиях OpenSSL до версий 0.9.8za, 1.0.0m и 1.0.1h. Известно, что серверы уязвимы только в OpenSSL 1.0.1 и 1.0.2-beta1. Пользователям серверов OpenSSL более ранних версий, чем 1.0.1, рекомендуется обновиться в качестве меры предосторожности. [81]

ClientHello sigals DoS

Эта уязвимость ( CVE - 2015-0291) позволяет любому человеку взять сертификат, прочитать его содержимое и точно изменить его, чтобы злоупотребить уязвимостью, заставляя сертификат вызывать сбой клиента или сервера. Если клиент подключается к серверу OpenSSL 1.0.2 и повторно согласовывает с недействительным расширением алгоритмов подписи, происходит разыменование нулевого указателя. Это может вызвать DoS-атаку на сервер.

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

OpenSSL классифицировал ошибку как проблему высокой степени серьезности, отметив, что версия 1.0.2 была признана уязвимой. [82]

Атака по восстановлению ключа на небольшие подгруппы Диффи-Хеллмана

Эта уязвимость ( CVE - 2016-0701) позволяет, при определенных обстоятельствах, восстановить закрытый ключ Диффи–Хеллмана сервера OpenSSL. Исследователь Adobe System Security Антонио Сансо в частном порядке сообщил об уязвимости.

OpenSSL классифицировал ошибку как проблему высокой степени серьезности, отметив, что уязвимой оказалась только версия 1.0.2. [83]

Вилки

Агломерированный SSL

В 2009 году, после разочарования в оригинальном API OpenSSL, Марко Пирбум, в то время разработчик OpenBSD, разветвил оригинальный API, создав Agglomerated SSL (assl), который повторно использует API OpenSSL под капотом, но предоставляет гораздо более простой внешний интерфейс. [84] С тех пор он был объявлен устаревшим в свете форка LibreSSL около 2016 года.

LibreSSL

В апреле 2014 года вслед за Heartbleed участники проекта OpenBSD разветвили OpenSSL, начав с ветки 1.0.1g, чтобы создать проект под названием LibreSSL . [85] За первую неделю сокращения кодовой базы OpenSSL из разветвления было удалено более 90 000 строк кода на языке C. [86]

BoringSSL

В июне 2014 года Google анонсировала собственный форк OpenSSL под названием BoringSSL. [87] Google планирует сотрудничать с разработчиками OpenSSL и LibreSSL. [88] [89] [90] С тех пор Google разработала новую библиотеку Tink, основанную на BoringSSL. [91]

Критика

Обратная совместимость

Среди сообществ разработчиков OpenSSL часто упоминается за то, что он нарушает совместимость API с каждой новой основной версией, [92] [93] [94] [95] , что требует адаптации программного обеспечения, что, как правило, задерживает принятие новых версий. [96] Это, в сочетании с тем фактом, что предыдущие выпуски, как правило, поддерживаются не более двух лет после выпуска новой основной версии [27], заставляет некоторых поставщиков предвидеть миграцию программного обеспечения очень рано, имея при этом мало времени [97] для обновления до новой версии, иногда с риском потери некоторой совместимости с существующим программным обеспечением [98] [99] или риском регрессии. [100] [101]

Задержка между выпусками

Хотя выпуски с долгосрочной поддержкой (LTS) поддерживаются в течение 5 лет [11], накопленные задержки в сроках выпуска, как правило, заставляют поставщиков операционных систем дольше оставаться на последнем поддерживаемом выпуске, оставляя меньше запаса, когда новая версия становится доступной. Например, OpenSSL 3.0 изначально ожидался в четвертом квартале 2019 года [44] и был окончательно выпущен 21 месяц спустя [27] без продления ожидаемого окончания поддержки ранее поддерживаемой версии 1.1.1, и это несмотря на значительные изменения, которые потребовали адаптации к существующему программному обеспечению.

Значительное снижение производительности

Упомянутая выше задержка поддержки версии 1.1.1 вызывает дополнительные опасения у пользователей, чьи рабочие нагрузки чувствительны к производительности. Через некоторое время после общедоступности 3.0 некоторые пользователи начали сообщать о серьезных регрессиях производительности, влияющих на эту версию в многопоточных средах, многие ссылались на неэффективное использование блокировок в частых низкоуровневых операциях, ссылаясь на замедления от 80 до 400 раз. [102] [103] [104] [105] [106] [107] [108] [109] Команда OpenSSL создала мета-проблему, чтобы попытаться централизовать отчеты о таких масштабных регрессиях производительности. [110] Около половины этих репортеров указывают на невозможность для них обновиться до 3.0 с более ранних версий, что усугубляет проблемы, вызванные ограниченным временем поддержки, оставшимся для предыдущей версии 1.1.1.

Учет требований пользователей

Пока транспортный уровень QUIC работал над поддержкой третьей версии протокола HTTP , было предложено использовать TLS для обеспечения безопасности [111] и было определено, что потребуются некоторые адаптации библиотек TLS. Такие изменения были внесены в BoringSSL [112], которая к тому времени в основном использовалась разработчиками QUIC, а затем перенесена в другие библиотеки. [113] Перенос этой работы был быстро предложен в OpenSSL. [114] Хотя некоторое обсуждение началось в тот же день, оно быстро заглохло и сначала было заблокировано по соображениям лицензии [114] , а затем приостановлено после того, как эти опасения были устранены. Наконец, 10 месяцев спустя Комитет по управлению OpenSSL объявил в сообщении в блоге [115] , что этот набор исправлений не будет принят для 3.0 из-за опасений, что API со временем изменится. Наконец, более чем через год после запланированного выпуска 3.0, который все еще не состоялся, команда добровольцев из Akamai и Microsoft решила разветвить проект как QuicTLS [116] и поддерживать эти патчи поверх кода OpenSSL, чтобы разблокировать разработку QUIC. Это действие в целом приветствовалось сообществом. Наконец, после того, как OpenSSL 3.0 был окончательно выпущен, набор патчей QUIC был пересмотрен и отклонен, [117] вызвав десятки или сотни реакций разочарования в сообществе. [114] Запрос на включение был закрыт, в то время как пользователи чувствовали необходимость публично выразить свое разочарование [118] или попросить поставщиков операционных систем поддержать альтернативный форк QuicTLS [119] [120] или искать альтернативные решения. [121] Наконец, Рич Сальц, соучредитель форка QuicTLS, объявил [121] о своей заинтересованности в том, чтобы проект Apache был ответвлен от QuicTLS. По состоянию на 25 февраля 2023 года в операционных системах по-прежнему не существует совместимой с QUIC библиотеки TLS с долгосрочной поддержкой, доступной по умолчанию без необходимости для конечных пользователей самостоятельно пересобирать ее из исходных кодов.

Смотрите также

Примечания

  1. ^ Основная версия 2.0.0 была пропущена из-за ее предыдущего использования в модуле OpenSSL FIPS. [29]

Ссылки

  1. ^ "OpenSSL 3.4.0". 22 октября 2024 г. Получено 22 октября 2024 г.
  2. ^ "/source/license.html". www.openssl.org . Получено 3 марта 2021 г. .
  3. ^ «Лицензия OpenSSL | Обмен данными о программных пакетах (SPDX)». spdx.org .
  4. ↑ Лори, Бен (6 января 1999 г.). "АНОНС: OpenSSL (Take 2). ssl-users (список рассылки) . Получено 29 октября 2018 г.
  5. ^ "Новые коммиттеры". OpenSSL Software Foundation. 20 мая 2019 г. Получено 11 октября 2024 г.
  6. ^ "Комитет по управлению OpenSSL". OpenSSL Software Foundation . Получено 3 ноября 2019 г.
  7. ^ "OpenSSL Committers". OpenSSL Software Foundation . Получено 3 ноября 2019 г.
  8. ^ Маркес, Стив (19 января 2017 г.). "Akamai спонсирует TLS 1.3". openssl-announce (список рассылки) . Получено 9 ноября 2018 г.
  9. ^ "OpenSSL – Changelog". OpenSSL Software Foundation . Получено 26 сентября 2016 г.
  10. ^ "OpenSSL Releases". GitHub . Получено 6 декабря 2022 г.
  11. ^ ab "OpenSSL Library – Release Strategy". OpenSSL Software Foundation . Получено 1 августа 2024 г.
  12. ^ abcdefgh "Заметки о серии OpenSSL 0.9.x". GitHub . Получено 6 декабря 2022 г. .
  13. ^ "Заметки о серии OpenSSL 1.0.0". GitHub . Получено 6 декабря 2022 г. .
  14. ^ "Заметки о серии OpenSSL 1.0.1". GitHub . Получено 6 декабря 2022 г. .
  15. ^ R. Seggelmann; M. Tuexen; M. Williams (февраль 2012 г.). Transport Layer Security (TLS) и Datagram Transport Layer Security (DTLS) Heartbeat Extension. Internet Engineering Task Force . doi : 10.17487/RFC6520 . ISSN  2070-1721. RFC 6520. Предложенный стандарт. Обновлен RFC 8447.
  16. ^ E. Rescorla (январь 2010 г.). Keying Material Exporters for Transport Layer Security (TLS). Internet Engineering Task Force . doi : 10.17487/RFC5705 . ISSN  2070-1721. RFC 5705. Предложенный стандарт. Обновлен RFC 8446 и 8447.
  17. ^ D. McGrew; E. Rescorla (май 2010 г.). Расширение Datagram Transport Layer Security (DTLS) для установления ключей для безопасного протокола передачи данных в реальном времени (SRTP). Internet Engineering Task Force . doi : 10.17487/RFC5764 . ISSN  2070-1721. RFC 5764. Предложенный стандарт. Обновлен RFC 7983 и 9443.
  18. ^ "Заметки о серии OpenSSL 1.0.2". GitHub . Получено 6 декабря 2022 г. .
  19. ^ "Заметки о серии OpenSSL 1.1.0". GitHub . Получено 6 декабря 2022 г. .
  20. ^ JP. Aumasson (октябрь 2015 г.). MJ. Saarinen (ред.). Криптографический хэш BLAKE2 и код аутентификации сообщений (MAC). Независимое представление IETF . doi : 10.17487/RFC7693 . ISSN  2070-1721. RFC 7693. Информационный.
  21. ^ Y. Nir; A. Langley (июнь 2018 г.). ChaCha20 и Poly1305 для протоколов IETF. Internet Research Task Force (IRTF). doi : 10.17487/RFC8439 . ISSN  2070-1721. RFC 8439. Информационный. Отменяет действие RFC 7539.
  22. ^ ab A. Langley; M. Hamburg; S. Turner (январь 2016 г.). Эллиптические кривые для безопасности. Internet Engineering Task Force . doi : 10.17487/RFC7748 . ISSN  2070-1721. RFC 7748. Информационный.
  23. ^ ab Caswell, Matt (11 сентября 2018 г.). «OpenSSL 1.1.1 выпущен». Блог OpenSSL . OpenSSL Foundation . Получено 11 октября 2024 г.
  24. ^ "Заметки о серии OpenSSL 1.1.1". GitHub . Получено 6 декабря 2022 г. .
  25. ^ Касвелл, Мэтт (8 февраля 2018 г.). «Использование TLS1.3 с OpenSSL». Блог OpenSSL . OpenSSL Foundation . Получено 11 октября 2024 г.
  26. ^ B. Kaliski; A. Rusch; J. Johnsson; A. Rusch (ноябрь 2016 г.). K. Moriarty (ред.). PKCS #1: Спецификации криптографии RSA версии 2.2. Internet Engineering Task Force (IETF). doi : 10.17487/RFC8017 . ISSN  2070-1721. RFC 8017. Информационный. Отменяет действие RFC 3447.
  27. ^ abc "OpenSSL 3.0 выпущен!". Блог OpenSSL . Получено 11 октября 2024 г.
  28. ^ "Заметки о серии OpenSSL 3.0". GitHub . Получено 6 декабря 2022 г. .
  29. ^ ab Мэтт Касвелл (28 ноября 2018 г.). «Священная ручная граната Антиохии». Блог OpenSSL . Получено 11 октября 2024 г.
  30. ^ "OpenSSL 3.1 Final Release". Блог OpenSSL . Получено 11 октября 2024 г.
  31. ^ "Заметки о серии OpenSSL 3.1". GitHub . Получено 15 марта 2023 г. .
  32. ^ "OpenSSL 3.2.0 Final Release". Блог OpenSSL . Получено 11 октября 2024 г.
  33. ^ "Заметки о серии OpenSSL 3.2". GitHub . Получено 24 ноября 2023 г. .
  34. ^ А. Гедини; В. Васильев (декабрь 2020 г.). Сжатие сертификата TLS. Internet Engineering Task Force (IETF). doi : 10.17487/RFC8879 . ISSN  2070-1721. RFC 8879. Предлагаемый стандарт.
  35. ^ T. Pornin (август 2013 г.). Детерминированное использование алгоритма цифровой подписи (DSA) и алгоритма цифровой подписи на основе эллиптических кривых (ECDSA). Независимая подача. doi : 10.17487/RFC6979 . ISSN  2070-1721. RFC 6979. Информационный.
  36. ^ J. Gilmore; S. Weiler; T. Kivinen (июнь 2014 г.). P. Wouters; H. Tschofenig (ред.). Использование необработанных открытых ключей в безопасности транспортного уровня (TLS) и безопасности датаграмм транспортного уровня (DTLS). Internet Engineering Task Force . doi : 10.17487/RFC7250 . ISSN  2070-1721. RFC 7250. Предлагаемый стандарт.
  37. ^ "OpenSSL 3.3 Final Release". Блог OpenSSL . Получено 11 октября 2024 г.
  38. ^ abc "GOST engine OpenSSL 1.0.0 README". cvs.openssl.org. Архивировано из оригинала 15 апреля 2013 г.
  39. ^ "Исходный код OpenSSL, каталог crypto/whrlpool". GitHub . Получено 29 августа 2017 г.
  40. ^ "Защита данных на долгий срок с помощью прямой секретности" . Получено 5 ноября 2012 г.
  41. ^ "NIST повторно сертифицирует модуль шифрования с открытым исходным кодом". gcn.com. Архивировано из оригинала 10 октября 2007 г.
  42. ^ "FIPS-140". openssl.org . Получено 12 ноября 2019 г. .
  43. ^ «Руководство пользователя OpenSSL для модуля объектов OpenSSL FIPS v2.0» (PDF) . openssl.org. 14 марта 2017 г. . Получено 12 ноября 2019 г. .
  44. ^ ab "Обновление о разработке 3.0, FIPS и 1.0.2 EOL". Блог OpenSSL . 7 ноября 2019 г. Получено 11 октября 2024 г.
  45. ^ "Сертификат программы проверки криптографического модуля № 1747". Центр ресурсов компьютерной безопасности . 11 октября 2016 г.
  46. ^ "Cryptographic Module Validation Program Certificate #2398". Computer Security Resource Center . 11 октября 2016 г.
  47. ^ "Сертификат программы проверки криптографического модуля № 2473". Центр ресурсов компьютерной безопасности . 11 октября 2016 г.
  48. ^ "Результаты поиска программы проверки криптографических модулей". Центр ресурсов компьютерной безопасности . 11 октября 2016 г.
  49. ^ "Результаты поиска программы проверки криптографических модулей". Центр ресурсов компьютерной безопасности . 11 октября 2016 г.
  50. ^ Шнайдер, Трой К. (20 июля 2016 г.). «Получение одобрения правительством более безопасного OpenSSL». GCN: Технологии, инструменты и тактики для ИТ-сектора государственного сектора .
  51. ↑ Уотерман, Шон (21 июля 2016 г.). «SafeLogic спасает положение, поскольку федералы используют OpenSSL». FedScoop .
  52. ^ Рашид, Фахмида Й. (26 июля 2016 г.). «Переработанный OpenSSL готовится к правительственной проверке». InfoWorld .
  53. ^ Уэллс, Джойс (3 августа 2017 г.). «Oracle, SafeLogic и OpenSSL объединяют усилия для обновления модуля FIPS». Тенденции и приложения баз данных .
  54. ^ Кернер, Шон Майкл (4 августа 2017 г.). «Oracle присоединяется к SafeLogic для разработки модуля FIPS для безопасности OpenSSL». eWeek .
  55. ^ "OpenSSL 3.0 Alpha7 Release". Блог OpenSSL . 20 октября 2020 г. Получено 11 октября 2024 г.
  56. ^ "Программа проверки криптографического модуля: OpenSSL". Центр ресурсов компьютерной безопасности . 11 октября 2016 г.
  57. ^ "OpenSSL: Исходный код, Лицензия". openssl.org.
  58. ^ «Лицензии – Фонд свободного программного обеспечения». fsf.org.
  59. ^ "WGET 1.10.2 для Windows (win32)". users.ugent.be. Архивировано из оригинала 2 января 2008 г.
  60. ^ "Выпуски исходного кода и двоичных файлов". climm.org. Архивировано из оригинала 12 февраля 2011 г. Получено 30 ноября 2010 г.
  61. ^ "Файл Deluge LICENSE". deluge-torrent.org . Получено 24 января 2013 г. .
  62. ^ Salz, Rich (1 августа 2015 г.). «Лицензионные соглашения и изменения грядут». openssl.org . Получено 11 октября 2024 г. .
  63. ^ "OpenSSL Re-licensing to Apache License v. 2.0 To Encourage Wider Use with Other FOSS Projects and Products". 23 марта 2017 г. Архивировано из оригинала 18 июля 2017 г. Получено 6 августа 2018 г.
  64. ^ Ли, Виктория; Рэдклифф, Марк; Стивенсон, Крис (5 февраля 2019 г.). «10 главных юридических разработок FOSS в 2018 году». Opensource.com, Red Hat . Архивировано из оригинала 5 февраля 2019 г. Получено 28 сентября 2019 г. Проект OpenSSL объявил о завершении перехода с лицензии OpenSSL/SSLeay на Apache Software License версии 2 (ASLv2).
  65. ^ "Изменение лицензии OpenSSL 3.0". 22 сентября 2021 г. Получено 24 сентября 2021 г.
  66. ^ "Обновления OpenSSL устраняют критические уязвимости безопасности". 9 августа 2014 г. Получено 25 августа 2014 г.
  67. ^ «Уязвимость переполнения кучи OpenSSL ASN.1 asn1_d2i_read_bio()». Cisco.
  68. ^ "Уязвимость ASN1 BIO". OpenSSL.
  69. ^ «О безопасности RC4 в TLS». Департамент информационной безопасности Royal Holloway.
  70. ^ "research!rsc: Уроки фиаско Debian/OpenSSL". research.swtch.com . Получено 12 августа 2015 г. .
  71. ^ "SSLkeys". Debian Wiki . Получено 19 июня 2015 г.
  72. ^ "Debian OpenSSL – Predictable PRNG Bruteforce SSH Exploit Python". База данных эксплойтов . 1 июня 2008 г. Получено 12 августа 2015 г.
  73. ^ "DSA-1571-1 openssl – генератор предсказуемых случайных чисел". Проект Debian . 13 мая 2008 г.
  74. ^ OpenSSL.org (7 апреля 2014 г.). "OpenSSL Security Advisory [07 апреля 2014 г.]" . Получено 9 апреля 2014 г.
  75. ^ OpenSSL (7 апреля 2014 г.). "TLS heartbeat read overrun (CVE-2014-0160)" . Получено 8 апреля 2014 г. .
  76. ↑ Codenomicon Ltd (8 апреля 2014 г.). "Heartbleed Bug" . Получено 8 апреля 2014 г.
  77. ^ "Почему Heartbleed опасен? Эксплуатация CVE-2014-0160". IPSec.pl. 2014. Архивировано из оригинала 8 апреля 2014 г. Получено 8 апреля 2014 г.
  78. ^ Mutton, Paul (8 апреля 2014 г.). «Полмиллиона пользующихся большим доверием веб-сайтов уязвимы для ошибки Heartbleed». Netcraft Ltd. Получено 8 апреля 2014 г.
  79. ^ «OpenSSL продолжает давать больше уязвимостей – обнаружено больше критических уязвимостей». Cyberoam Threat Research Labs. 2014. Архивировано из оригинала 19 июня 2014 г. Получено 13 июня 2014 г.
  80. ^ "CVE-2014-0224". CVE. 2014.
  81. ^ "OpenSSL Security Advisory". OpenSSL. 5 июня 2014 г.
  82. ^ "OpenSSL исправляет серьезную уязвимость типа "отказ в обслуживании"". Брэндон Стош. 20 марта 2015 г.
  83. ^ Гудлин, Дэн (28 января 2016 г.). «Ошибка высокой степени серьезности в OpenSSL позволяет злоумышленникам расшифровывать трафик HTTPS». Ars Technica .
  84. ^ "security/assl: assl-1.5.0p0v0 – скрыть ужасный SSL API в разумном интерфейсе". Порты OpenBSD . 22 мая 2014 г. Получено 10 февраля 2015 г.
  85. ^ "OpenBSD начала масштабную очистку и демонтаж OpenSSL". Журнал OpenBSD . 15 апреля 2014 г.
  86. ^ "OpenBSD разветвляется, сокращается, исправляется OpenSSL". ZDNet. 21 апреля 2014 г. Получено 21 апреля 2014 г.
  87. ^ "BoringSSL". Git в Google .
  88. ^ "Google представляет независимую "ветвь" OpenSSL под названием "BoringSSL"". Ars Technica . 21 июня 2014 г.
  89. ^ "BoringSSL". Веблог Адама Лэнгли . 20 июня 2014 г.
  90. ^ «BoringSSL хочет убить волнение, которое привело к Heartbleed». Sophos. 24 июня 2014 г.
  91. ^ Бьюкенен, Билл (30 августа 2018 г.). «Прощай, OpenSSL, и привет Google Tink». Medium . Получено 4 апреля 2019 г. .
  92. ^ "OpenSSL 3 ломает сборку webpack · Проблема № 22305 · brave/brave-browser". GitHub .
  93. ^ "openssl версии 3.0 в arch? / Уголок новичка / Форумы Arch Linux". bbs.archlinux.org .
  94. ^ "Планы перехода на OpenSSL 3.0". Ubuntu Community Hub . 6 апреля 2022 г.
  95. ^ "Совместимость OpenSSL 3.0 · Проблема № 597 · nginx/unit". GitHub .
  96. ^ "Наше будущее с OpenSSL". Обсуждения на Python.org . 28 ноября 2022 г.
  97. ^ «Опыт внедрения OpenSSL 3.0 в Red Hat Enterprise Linux и Fedora». www.redhat.com .
  98. ^ "Компиляция с OpenSSL 3.X". groups.google.com .
  99. ^ "ESET Management Agent (RHEL 9.x, OpenSSL 3.0.x)". Форум безопасности ESET . 6 июня 2022 г.
  100. ^ «Проблема 46313: SSLObject не вызывает SSLEOFError в OpenSSL 3 — трекер Python». bugs.python.org .
  101. ^ "RHEL 9: openssl (RHSA-2022:6224)". www.tenable.com .
  102. ^ "Значительное падение производительности OpenSsl 3.0 при использовании в тяжелом многопоточном серверном приложении · Проблема № 17064 · openssl/openssl". GitHub .
  103. ^ "Проблема производительности Openssl 3.0 в многопоточном приложении при использовании d2i_x509 · Проблема № 17950 · openssl/openssl". GitHub .
  104. ^ "Значительное снижение эффективности загрузки учетных данных по сравнению с 1.1.1 · Проблема № 18814 · openssl/openssl". GitHub .
  105. ^ "Производительность 3.0 снизилась из-за блокировки · Проблема № 20286 · openssl/openssl". GitHub .
  106. ^ "Высокая загрузка ЦП для исходящих запросов SSL после обновления с v16.15.0 до v18.1.0 · Проблема № 43128 · nodejs/node". GitHub .
  107. ^ "Значительное падение производительности в поставщике OpenSsl 3.0 FIPS · Проблема № 18472 · openssl/openssl". GitHub .
  108. ^ "Измерения производительности · Проблема № 16791 · openssl/openssl". GitHub .
  109. ^ "PEM/DER декодирование закрытых ключей PKCS8 RSA в 80 раз медленнее в 3.0 · Проблема № 15199 · openssl/openssl". GitHub .
  110. ^ "3.0 Проблемы с производительностью · Проблема № 17627 · openssl/openssl". GitHub .
  111. ^ Томсон, Мартин; Тернер, Шон (14 января 2017 г.). «Использование Transport Layer Security (TLS) для защиты QUIC» – через IETF.
  112. ^ "221 - drillingssl - Форк OpenSSL, разработанный для удовлетворения потребностей Google - Monorail". bugs.chromium.org .
  113. ^ "Поддержка QUIC TLS API (#826) · Проблемы · gnutls / GnuTLS · GitLab". GitLab . 4 сентября 2019 г.
  114. ^ abc "WIP: поддержка основного QUIC от tmshort · Запрос на извлечение № 8797 · openssl/openssl". GitHub .
  115. ^ "QUIC и OpenSSL". Блог OpenSSL . Получено 11 октября 2024 г.
  116. ^ "quictls анонсируют в твиттере".
  117. ^ «Требования к выпуску OMC». www.mail-archive.com .
  118. ^ «QUIC API OpenSSL не будет предоставлять | daniel.haxx.se». 25 октября 2021 г.
  119. ^ Тарро, Вилли (27 октября 2021 г.). «[Pkg-openssl-devel] Есть ли намерение поддерживать quictls?».
  120. ^ "Ошибка № 1011391: openssl: пожалуйста, поддержите quictls patchset". groups.google.com .
  121. ^ ab "Поддержка HTTP/3 · Проблема № 680 · haproxy/haproxy". GitHub .

Внешние ссылки

На Викискладе есть медиафайлы по теме OpenSSL .