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]

По состоянию на май 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 , Triple DES , ГОСТ 28147-89 , [28] SM4
Криптографические хэш-функции
МД5 , МД4 , МД2 , ША-1 , ША-2 , ША-3 , RIPEMD-160 , МДК-2 , ГОСТ Р 34.11-94 , [28] BLAKE2 , Whirlpool , [29] SM3
Криптография с открытым ключом
RSA , DSA , обмен ключами Диффи–Хеллмана , Эллиптическая кривая , X25519 , Ed25519 , X448 , Ed448 , ГОСТ Р 34.10-2001, [28] SM2

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

Проверка FIPS 140

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

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

Комитет управления OpenSSL объявил об изменении схемы управления версиями.

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

OpenSSL 3.0 восстановил режим FIPS и прошел тестирование FIPS 140-2, но со значительными задержками: впервые работа была начата в 2016 году с поддержкой со стороны SafeLogic [40] [41] [42] и дальнейшей поддержкой со стороны Oracle в 2017 году [43] [44] , но этот процесс был непростым. [45]

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

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

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

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

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

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

Отказ в обслуживании: анализ 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. [56]

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

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

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

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

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

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

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

Сердцекровие

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

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

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

Уязвимость внедрения CCS

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

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

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

DoS-отказ от сигальгов ClientHello

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

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

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

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

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

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

Вилки

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

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

LibreSSL

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

скучныйSSL

В июне 2014 года Google анонсировала собственную версию OpenSSL, получившую название BoringSSL. [77] Google планирует сотрудничать с разработчиками OpenSSL и LibreSSL. [78] [79] [80] С тех пор Google разработала новую библиотеку Tink, основанную на BoringSSL. [81]

Критика

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

В сообществах разработчиков OpenSSL часто упоминается из-за некоторых проблем с совместимостью API с каждой новой основной версией, [82] [83] [84] [85] , что требует адаптации программного обеспечения, что, как правило, задерживает внедрение новых версий. [86] Это, в сочетании с тем фактом, что предыдущие версии обычно поддерживаются не более двух лет после выпуска новой основной версии [87] , как правило, вынуждает некоторых поставщиков очень рано предвидеть миграцию программного обеспечения, хотя у нее еще остается мало времени [88] ] для обновления до новой версии, иногда с риском потери некоторой совместимости с существующим программным обеспечением [89] [90] или риска регресса. [91] [92]

Задержка между релизами

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

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

Упомянутая выше уменьшенная задержка поддержки версии 1.1.1 вызывает дополнительные опасения у пользователей, чьи рабочие нагрузки чувствительны к производительности. Через некоторое время после общедоступной версии 3.0 некоторые пользователи начали сообщать о серьезном падении производительности этой версии в многопоточных средах, многие ссылались на неэффективное использование блокировок в частых низкоуровневых операциях, ссылаясь на замедление от 80 до 400 раз. [95] [96] [97] [98] [99] [100] [101] [102] Команда OpenSSL создала мета-проблему, чтобы попытаться централизовать отчеты о таких масштабных падениях производительности. [103] Около половины этих репортеров указывают на невозможность обновления до 3.0 с более ранних версий, что усугубляет проблемы, вызванные ограниченным временем поддержки, оставшимся для предыдущей версии 1.1.1.

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

В то время как транспортный уровень QUIC работал над поддержкой третьей версии протокола HTTP , было предложено использовать TLS для обеспечения безопасности [104] и было установлено, что потребуются некоторые адаптации библиотек TLS. Такие модификации были внесены в BoringSSL [105] , которая к тому времени в основном использовалась разработчиками QUIC, а затем была портирована на другие библиотеки. [106] Порт этой работы был быстро предложен OpenSSL. [107] Хотя некоторые обсуждения начались в тот же день, они быстро застопорились и сначала были заблокированы по соображениям лицензии, [107] затем были приостановлены, как только эти опасения были сняты. Наконец, 10 месяцев спустя комитет управления OpenSSL объявил в своем блоге [108] , что этот набор исправлений не будет принят для версии 3.0 из-за опасений, что API со временем изменится. Наконец, более чем через год после запланированного выпуска 3.0, который все еще не состоялся, команда добровольцев из Akamai и Microsoft решила форкнуть проект как QuicTLS [109] и поддерживать эти исправления поверх кода OpenSSL, чтобы разблокировать разработку QUIC. . Сообщество в целом приветствовало это действие. Наконец, после того, как OpenSSL 3.0 был наконец выпущен, набор патчей QUIC был пересмотрен и отклонен [110] , что вызвало десятки и сотни реакций разочарования среди сообщества. [107] Запрос на включение был закрыт, а пользователи почувствовали необходимость публично выразить свое разочарование, [111] или попросить поставщиков операционных систем поддержать альтернативный форк QuicTLS, [112] [113] или поискать альтернативные решения. [114] Наконец, Рич Зальц, сооснователь форка QuicTLS, объявил [114] о своем интересе к проекту Apache, ответвленному от QuicTLS. По состоянию на 25 февраля 2023 года все еще не существует QUIC-совместимой библиотеки TLS с долгосрочной поддержкой, доступной по умолчанию в операционных системах, без необходимости от конечных пользователей самостоятельно пересобирать ее из исходных кодов.

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

Примечания

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

Рекомендации

  1. ^ «Выпуск OpenSSL 3.2.1» .
  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. 20 мая 2019 г. Проверено 3 ноября 2019 г.
  6. ^ «Управляющий комитет OpenSSL» . Фонд программного обеспечения OpenSSL . Проверено 3 ноября 2019 г.
  7. ^ "Коммиттеры OpenSSL" . Фонд программного обеспечения OpenSSL . Проверено 3 ноября 2019 г.
  8. ↑ Маркиз, Стив (19 января 2017 г.). «Akamai спонсирует TLS 1.3». openssl-announce (список рассылки) . Проверено 9 ноября 2018 г.
  9. ^ «OpenSSL – Журнал изменений» . Фонд программного обеспечения OpenSSL . Проверено 26 сентября 2016 г.
  10. ^ «OpenSSL – Стратегия выпуска» . Фонд программного обеспечения OpenSSL . Проверено 26 сентября 2016 г.
  11. ^ «Релизы OpenSSL» . Гитхаб . Проверено 6 декабря 2022 г.
  12. ^ abcdefgh «Примечания к серии OpenSSL 0.9.x». Гитхаб . Проверено 6 декабря 2022 г.
  13. ^ «Примечания к серии OpenSSL 1.0.0» . Гитхаб . Проверено 6 декабря 2022 г.
  14. ^ «Примечания к серии OpenSSL 1.0.1» . Гитхаб . Проверено 6 декабря 2022 г.
  15. ^ "Примечания к серии OpenSSL 1.0.2" . Гитхаб . Проверено 6 декабря 2022 г.
  16. ^ abcde «Стратегия выпуска». www.openssl.org . Фонд OpenSSL. 7 января 2020 г.
  17. ^ "Примечания к серии OpenSSL 1.1.0" . Гитхаб . Проверено 6 декабря 2022 г.
  18. ↑ Аб Касвелл, Мэтт (11 сентября 2018 г.). «Выпущен OpenSSL 1.1.1». www.openssl.org . Фонд OpenSSL.
  19. ^ "Примечания к серии OpenSSL 1.1.1" . Гитхаб . Проверено 6 декабря 2022 г.
  20. ↑ Касвелл, Мэтт (8 февраля 2018 г.). «Использование TLS1.3 с OpenSSL — блог OpenSSL». www.openssl.org . Фонд OpenSSL.
  21. ^ «Выпущен OpenSSL 3.0! - Блог OpenSSL» . www.openssl.org . Проверено 8 сентября 2021 г.
  22. ^ "Примечания к серии OpenSSL 3.0" . Гитхаб . Проверено 6 декабря 2022 г.
  23. ↑ ab Мэтт Касвелл (28 ноября 2018 г.). «Святая ручная граната Антиохии». Блог OpenSSL . Проверено 7 октября 2019 г.
  24. ^ «Окончательный выпуск OpenSSL 3.1 — Блог OpenSSL» . www.openssl.org . Проверено 15 марта 2023 г.
  25. ^ «Примечания к серии OpenSSL 3.1» . Гитхаб . Проверено 15 марта 2023 г.
  26. ^ «Финальный выпуск OpenSSL 3.2.0 — Блог OpenSSL» . www.openssl.org . Проверено 24 ноября 2023 г.
  27. ^ "Примечания к серии OpenSSL 3.2" . Гитхаб . Проверено 24 ноября 2023 г.
  28. ^ abc «README для ядра OpenSSL 1.0.0 ГОСТ». cvs.openssl.org. Архивировано из оригинала 15 апреля 2013 года.
  29. ^ «Исходный код OpenSSL, каталог crypto/whrlpool». Гитхаб . Проверено 29 августа 2017 г.
  30. ^ «Защита данных в долгосрочной перспективе с помощью прямой секретности» . Проверено 5 ноября 2012 г.
  31. ^ «NIST повторно сертифицирует модуль шифрования с открытым исходным кодом» . gcn.com. Архивировано из оригинала 10 октября 2007 года.
  32. ^ "ФИПС-140". openssl.org . Проверено 12 ноября 2019 г.
  33. ^ «Руководство пользователя OpenSSL для объектного модуля OpenSSL FIPS v2.0» (PDF) . openssl.org. 14 марта 2017 г. Проверено 12 ноября 2019 г.
  34. ^ «Обновление разработки 3.0, FIPS и EOL 1.0.2» . Блог OpenSSL . 7 ноября 2019 г.
  35. ^ «Сертификат программы проверки криптографического модуля № 1747» . Ресурсный центр компьютерной безопасности . 11 октября 2016 г.
  36. ^ «Сертификат программы проверки криптографического модуля № 2398» . Ресурсный центр компьютерной безопасности . 11 октября 2016 г.
  37. ^ «Сертификат программы проверки криптографического модуля № 2473» . Ресурсный центр компьютерной безопасности . 11 октября 2016 г.
  38. ^ «Результаты поиска программы проверки криптографических модулей» . Ресурсный центр компьютерной безопасности . 11 октября 2016 г.
  39. ^ «Результаты поиска программы проверки криптографических модулей» . Ресурсный центр компьютерной безопасности . 11 октября 2016 г.
  40. ↑ Шнайдер, Трой К. (20 июля 2016 г.). «Получение правительственного одобрения более безопасного OpenSSL». GCN: Технологии, инструменты и тактика для ИТ государственного сектора .
  41. ↑ Уотерман, Шон (21 июля 2016 г.). «SafeLogic спасает ситуацию от использования OpenSSL федеральными властями». ФедСкуп .
  42. ↑ Рашид, Фахмида Ю. (26 июля 2016 г.). «Переработанный OpenSSL готов к государственной проверке». Инфомир .
  43. ↑ Уэллс, Джойс (3 августа 2017 г.). «Oracle, SafeLogic и OpenSSL объединяют усилия для обновления модуля FIPS». Тенденции и приложения баз данных .
  44. ↑ Кернер, Шон Майкл (4 августа 2017 г.). «Oracle присоединяется к SafeLogic для разработки модуля FIPS для безопасности OpenSSL». электронная неделя .
  45. ^ «Выпуск OpenSSL 3.0 Alpha7» . Блог OpenSSL . 20 октября 2020 г.
  46. ^ «Программа проверки криптографического модуля: OpenSSL» . Ресурсный центр компьютерной безопасности . 11 октября 2016 г.
  47. ^ «OpenSSL: Источник, Лицензия» . openssl.org.
  48. ^ «Лицензии - Фонд свободного программного обеспечения» . fsf.org.
  49. ^ «WGET 1.10.2 для Windows (win32)» . пользователи.ugent.be. Архивировано из оригинала 2 января 2008 года.
  50. ^ «Выпуски исходных кодов и двоичных файлов» . climm.org. Архивировано из оригинала 12 февраля 2011 года . Проверено 30 ноября 2010 г.
  51. ^ "Файл ЛИЦЕНЗИИ Deluge" . deluge-torrent.org . Проверено 24 января 2013 г.
  52. ↑ Зальц, Рич (1 августа 2015 г.). «Лицензионные соглашения и изменения грядут». openssl.org . Проверено 23 августа 2015 г.
  53. ^ «Перелицензирование OpenSSL на лицензию Apache v. 2.0 для поощрения более широкого использования с другими проектами и продуктами FOSS» . 23 марта 2017. Архивировано из оригинала 18 июля 2017 года . Проверено 6 августа 2018 г.
  54. ^ Ли, Виктория; Рэдклифф, Марк; Стивенсон, Крис (5 февраля 2019 г.). «10 лучших правовых событий FOSS 2018 года». Opensource.com, Red Hat . Архивировано из оригинала 5 февраля 2019 года . Проверено 28 сентября 2019 г. Проект OpenSSL объявил о завершении перехода от лицензии OpenSSL/SSLeay к лицензии на программное обеспечение Apache версии 2 (ASLv2).
  55. ^ «Изменение лицензии OpenSSL 3.0» . 22 сентября 2021 г. Проверено 24 сентября 2021 г.
  56. ^ «Обновления OpenSSL исправляют критические уязвимости безопасности» . 9 августа 2014 года . Проверено 25 августа 2014 г.
  57. ^ «OpenSSL ASN.1 asn1_d2i_read_bio() Уязвимость переполнения кучи» . Циско.
  58. ^ «Уязвимость ASN1 BIO» . OpenSSL.
  59. ^ «О безопасности RC4 в TLS». Департамент информационной безопасности Ройал Холлоуэй.
  60. ^ "research!rsc: Уроки фиаско Debian/OpenSSL" . www.research.swtch.com . Проверено 12 августа 2015 г.
  61. ^ "SSL-ключи". Дебиан Вики . Проверено 19 июня 2015 г.
  62. ^ «Debian OpenSSL — предсказуемый PRNG-перебор SSH с использованием Python» . База данных эксплойтов . 1 июня 2008 года . Проверено 12 августа 2015 г.
  63. ^ «DSA-1571-1 openssl – генератор предсказуемых случайных чисел» . Проект Дебиан . 13 мая 2008 г.
  64. ^ OpenSSL.org (7 апреля 2014 г.). «Рекомендации по безопасности OpenSSL [7 апреля 2014 г.]» . Проверено 9 апреля 2014 г.
  65. ^ OpenSSL (7 апреля 2014 г.). «Переполнение контрольного сигнала TLS при чтении (CVE-2014-0160)» . Проверено 8 апреля 2014 г.
  66. ^ Codenomicon Ltd (8 апреля 2014 г.). «Жук с кровоточащим сердцем» . Проверено 8 апреля 2014 г.
  67. ^ «Почему Heartbleed опасен? Использование CVE-2014-0160» . IPSec.pl. 2014. Архивировано из оригинала 8 апреля 2014 года . Проверено 8 апреля 2014 г.
  68. ↑ Маттон, Пол (8 апреля 2014 г.). «Полмиллиона широко надежных веб-сайтов уязвимы для ошибки Heartbleed» . ООО "Неткрафт" . Проверено 8 апреля 2014 г.
  69. ^ «OpenSSL продолжает устранять все больше недостатков - обнаружено больше критических уязвимостей» . Лаборатории исследования угроз Cyberoam. 2014. Архивировано из оригинала 19 июня 2014 года . Проверено 13 июня 2014 г.
  70. ^ «CVE-2014-0224». CVE. 2014.
  71. ^ «Рекомендации по безопасности OpenSSL» . OpenSSL. 5 июня 2014 г.
  72. ^ «OpenSSL исправляет серьезную уязвимость, связанную с отказом в обслуживании» . Брэндон Стош. 20 марта 2015 г.
  73. ↑ Гудлин, Дэн (28 января 2016 г.). «Ошибка высокой степени серьезности в OpenSSL позволяет злоумышленникам расшифровывать HTTPS-трафик». Арс Техника .
  74. ^ «security/assl: assl-1.5.0p0v0 – скрыть ужасный SSL API в нормальном интерфейсе» . Порты OpenBSD . 22 мая 2014 года . Проверено 10 февраля 2015 г.
  75. ^ «OpenBSD начала масштабную очистку OpenSSL». Журнал OpenBSD . 15 апреля 2014 г.
  76. ^ «OpenBSD расширяет, сокращает и исправляет OpenSSL» . ЗДНет. 21 апреля 2014 года . Проверено 21 апреля 2014 г.
  77. ^ "СкучныйSSL". Git в Google .
  78. ^ «Google представляет независимую «вилку» OpenSSL под названием «BoringSSL»» . Арс Техника . 21 июня 2014 г.
  79. ^ "СкучныйSSL". Блог Адама Лэнгли . 20 июня 2014 г.
  80. ^ «BoringSSL хочет убить волнение, которое привело к Heartbleed» . Софос. 24 июня 2014 г.
  81. ↑ Бьюкенен, Билл (30 августа 2018 г.). «Прощай, OpenSSL и здравствуй, Google Tink». Середина . Проверено 4 апреля 2019 г.
  82. ^ «OpenSSL 3 нарушает сборку веб-пакета · Проблема № 22305 · храбрый / храбрый браузер» . Гитхаб .
  83. ^ «openssl версии 3.0 в Arch? / Уголок новичков / Форумы Arch Linux» . bbs.archlinux.org .
  84. ^ «Планы перехода на OpenSSL 3.0» . Центр сообщества Ubuntu . 6 апреля 2022 г.
  85. ^ «Совместимость OpenSSL 3.0 · Проблема № 597 · nginx/unit» . Гитхаб .
  86. ^ «Наше будущее с OpenSSL». Обсуждения на Python.org . 28 ноября 2022 г.
  87. ^ ab «Выпущен OpenSSL 3.0! - Блог OpenSSL» . www.openssl.org .
  88. ^ «Опыт внедрения OpenSSL 3.0 в Red Hat Enterprise Linux и Fedora». www.redhat.com .
  89. ^ «Компиляция с OpenSSL 3.X» . groups.google.com .
  90. ^ «Агент ESET Management (RHEL 9.x, OpenSSL 3.0.x)» . Форум безопасности ESET .
  91. ^ «Проблема 46313: SSLObject не вызывает SSLEOFError в OpenSSL 3 — трекер Python» . bugs.python.org .
  92. ^ «RHEL 9: openssl (RHSA-2022:6224)» . www.tenable.com .
  93. ^ "/policies/releasestrat.html". www.openssl.org .
  94. ^ «Обновление разработки 3.0, FIPS и EOL 1.0.2 — блог OpenSSL» . www.openssl.org .
  95. ^ «Значительное снижение производительности OpenSsl 3.0 при использовании в тяжелом многопоточном серверном приложении · Проблема № 17064 · openssl/openssl» . Гитхаб .
  96. ^ «Проблема с производительностью Openssl 3.0 в многопоточном приложении при использовании d2i_x509 · Проблема № 17950 · openssl/openssl» . Гитхаб .
  97. ^ «Серьёзное снижение эффективности загрузки учетных данных по сравнению с версией 1.1.1 · Проблема № 18814 · openssl/openssl» . Гитхаб .
  98. ^ «Производительность версии 3.0 снизилась из-за блокировки · Проблема № 20286 · openssl/openssl» . Гитхаб .
  99. ^ «Высокая загрузка процессора для исходящих SSL-запросов после обновления с версии 16.15.0 до версии 18.1.0 · Проблема № 43128 · nodejs/node». Гитхаб .
  100. ^ «Значительное снижение производительности поставщика OpenSsl 3.0 FIPS · Проблема № 18472 · openssl/openssl» . Гитхаб .
  101. ^ «Измерения производительности · Проблема № 16791 · openssl/openssl» . Гитхаб .
  102. ^ «Декодирование PEM/DER закрытых ключей PKCS8 RSA в версии 3.0 в 80 раз медленнее · Проблема № 15199 · openssl/openssl» . Гитхаб .
  103. ^ «3.0 Проблемы с производительностью · Проблема № 17627 · openssl/openssl» . Гитхаб .
  104. ^ «Использование Transport Layer Security (TLS) для защиты QUIC» . 14 января 2017 г. – через IETF.
  105. ^ «221 — Boringssl — Ответвление OpenSSL, разработанное для удовлетворения потребностей Google — Монорельс» . bugs.chromium.org .
  106. ^ «Поддержка API QUIC TLS (# 826) · Проблемы · gnutls / GnuTLS · GitLab» . ГитЛаб .
  107. ^ abc «WIP: основная поддержка QUIC от tmshort · Запрос на извлечение № 8797 · openssl/openssl» . Гитхаб .
  108. ^ «QUIC и OpenSSL - Блог OpenSSL» . www.openssl.org .
  109. ^ "Объявление Quictls в Твиттере" .
  110. ^ «Требования к выпуску OMC» . www.mail-archive.com .
  111. ^ «QUIC API OpenSSL не предоставляет | daniel.haxx.se» . 25 октября 2021 г.
  112. ↑ Тарро, Вилли (27 октября 2021 г.). «[Pkg-openssl-devel] Есть ли намерение поддерживать quictls?».
  113. ^ «Ошибка № 1011391: openssl: пожалуйста, поддержите набор обновлений quictls». groups.google.com .
  114. ^ ab «Поддержка HTTP/3 · Проблема № 680 · haproxy/haproxy». Гитхаб .

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

Викискладе есть медиафайлы, связанные с OpenSSL .