Разработчики проекта OpenBSD представили (http://marc.info/?l=openbsd-tech&m=141313546902405&w=2) выпуск переносимой редакции пакета LibreSSL 2.1.0 (http://www.libressl.org/), в рамках которого развивается форк OpenSSL, нацеленный на обеспечение более высокого уровня безопасности. Из особенностей LibreSSL можно отметить ориентацию на качественную поддержку протоколов SSL/TLS с удалением излишней функциональности, добавлением дополнительных средств защиты и проведением значительной чистки и переработки кодовой базы. Выпуск включает (http://ftp.openbsd.org/pub/OpenBSD/LibreSSL/) в себя изменения, подготовленные после заморозки кодовой базы нативной редакции LibreSSL для OpenBSD, которая будет представлена 1 ноября в составе OpenBSD 5.6. Наработки LibreSSL 2.1 войдут в состав ветки OpenBSD 5.7.
Из улучшений (http://opensslrampage.org/) можно отметить:
- добавление функции SSL_CTX_use_certificate_chain() для загрузки данных сертификата из памяти, а не из файла;
- устранение утечек памяти;
- замена использования strdup() на strndup();
- рефакторинг работы с расширениями ECC;
- добавлен шифр CHACHA20 для симметричного шифрования;
- переработан код для разбора опций;
- добавлена опция для упорядоченной обработки флагов;
- добавлена опция для обработки входных и выходных форматов;
- обеспечена поддержка в Linux системного вызова getrandom(), появившегося в ядре 3.17;Выпуск LibreSSL 2.1.0 не включает в себя реализацию нового API ressl, который пока разрабатывается отдельно (https://github.com/libressl-portable/openbsd/tree/master/src...). В рамках API ressl развивается (http://www.opennet.me/opennews/art.shtml?num=40710) упрощённая замена API OpenSSL, которая предоставляет высокоуровневый интерфейс для организации защищённых соединений, абстрагированный от внутренностей и скрывающий низкоуровневые манипуляции с сертификатами X.509 или ASN.1. Новый API предоставляет встроенные механизмы для верификация имени хоста, который позволяет убедиться, что имя хоста, к которому осуществляется соединение, соответствует имени, указанному в сертификате. При применении API OpenSSL данное сопоставление должно быть выполнено разработчиками приложения, которые часто игнорируют данную проверку или забывают её добавить.
URL: http://undeadly.org/cgi?action=article&sid=20141012180624
Новость: http://www.opennet.me/opennews/art.shtml?num=40807
/me уже готов к тонне минусов, ибо не знаком со внутренностями всяких libssl, однако может стоит разбить этот пакет на несколько. Я так понял, сейчас проблема в том, что пакет стал слишком большим, и сопровождать его на нужном уровне качества становится маловозможным. Дак может пойти по принципу UNIX-way, а вместо делания комбайнов? Сделать отдельные libecdsa, librsa, libgost и т.п. Потом как-нибудь всё это связать с помощью libssl, который в свою очередь будет использовать эти libкрипты.
> И стало интересно, почему не делают как я описал выше.Я, конечно, не изучал вопрос досканально, но могу предположить, что многие части так завязаны друг на друга, что разделить их не проще, чем создать новую реализацию с нуля.
А давно Unix way стал означат раздробить всё на сущности?
unix way -- это значит -- привязать к systemd![шутка-юмор:).. с намёком на то, что этот термин понимает кто как хочет]
> А давно Unix way стал означат раздробить всё на сущности?«Пишите программы, которые делают что-то одно и делают это хорошо.»
«Пишите программы, которые бы работали вместе.»Тут вы можете найти многократное упоминание:
https://ru.wikipedia.org/wiki/%D0%A4%D0%...А вообще, там есть ссылки на первоисточники.
Верно, но выделение блочных шифров в отдельную сущность явно не следует этой идеологии.
Почему?
> Почему?Потому что там _ни _при _каком делении или дроблении *интерфейсы* не станут проще или прозрачнее. //Наполовину пуст, да.
>> Почему?
> Потому что там _ни _при _каком делении или дроблении *интерфейсы* не станут
> проще или прозрачнее. //Наполовину пуст, да.Не соглашусь, хоть и это сейчас не важно.
А важно, что я говорю не про то, чтобы интерфейсы стали проще и прозрачнее. А про то, чтобы разбить программу на несколько, чтобы сообщество эффективнее взаимодействовало. Сейчас же будут форки openssl, в которых будут делать полезный код, но он будет сложно переносим между проектами (включая merge в оригинал). В результате вместо того, чтобы совместно пилить качественный продукт состоящий из хорошо работающих компонентов, каждый пилит свой bundle.
Очень грубо говоря:
Если разбить пакет на несколько, то LibreSSL-вцы бы просто пилили ядро (libssl) и минимальный набор базовых lib (libостальное). А OpenSSL-вцы смогли бы использовать это качественное и вылизанное ядро с базовыми lib-ами уже при добавлении поддержки дополнительных алгоритмов в виде отдельных lib.
>[оверквотинг удален]
> и прозрачнее. А про то, чтобы разбить программу на несколько, чтобы
> сообщество эффективнее взаимодействовало. Сейчас же будут форки openssl, в которых будут
> делать полезный код, но он будет сложно переносим между проектами (включая
> merge в оригинал). В результате вместо того, чтобы совместно пилить качественный
> продукт состоящий из хорошо работающих компонентов, каждый пилит свой bundle.
> Очень грубо говоря:
> Если разбить пакет на несколько, то LibreSSL-вцы бы просто пилили ядро (libssl)
> и минимальный набор базовых lib (libостальное). А OpenSSL-вцы смогли бы использовать
> это качественное и вылизанное ядро с базовыми lib-ами уже при добавлении
> поддержки дополнительных алгоритмов в виде отдельных lib.Проблема в том, что у OpenSSL и LibreSSL (равно как и BoringSSL) разные подходны к разработке. Но зато кодом и идеями последние два проекта потихоньку обмениваются, так что не всё так плохо.
Что же до разделения на отдельные сущности - в общем-то и так есть libssl и libcrypto, готовится ещё libressl. Это в OpenSSL как раз первые две либы умудрились завязать друг на друга взаимно. :-\ Правда, может, в последних версиях это всё же исправили - хз, свежего линя под руками нет... В общем, разделение определённое уже есть, а полностью его провести - увы, мешает понятие "обратная совместимость". API (заметно) ломать негоже, иначе такой форк никогда не станет дефолтным ни в одной ОС.
> стал означатизначально
Ну почему не делят? Делят. Например, в Debian функционал для pkcs12 вынесен в отдельные библиотеки. Потом просто в конфиге OpenSSL прописываешь, что нужно использовать, и всё. Не нужные какие-то протоколы - правь /etc/ssl/openssl.conf.
> /me уже готов к тонне минусов, ибо не знаком со внутренностями всяких libsslТебе повезло. Ибо знакомиться с этой фeкальной массой удовольствие ниже среднего.
> однако может стоит разбить этот пакет на несколько.
Лучше на SSL/TLS просто забить. For teh greater good, ну и вообще, если безопасность хоть на йот интересует.
если бы сейчас кто нибуть еще написал и мануал как прикруить его в существующие enterprise на базе spring, jboss, tomcat etc. то скорость разпространения этого пакета как минимум удвойтся.
> если бы сейчас кто нибуть еще написал и мануал как прикруить его
> в существующие enterprise на базе spring, jboss, tomcat etc.
> то скорость разпространения этого пакета как минимум удвойтся.Сказано же, что будет отдельная либа, которая будет выдавать себя за OpenSSL, т.е. никакое ПО перенастраивать не надо будет, оно и не заметит подмены (если не будет использовать недокументированные возможности и грязные хаки).
Упс, это я пропустил, спасибо за подсказку. Подмена не очень хорошая идея на мой взгляд, вот то что хочется это не подмена а настоящая замена учитывая того что она уже написана или хотя бы врапер, допустим вы разрабатываете что то вроде Spring Boot + Spring Security + Tomcat + hibernate + postgresql или аналог из Jboss для энерпраиз, все это один такой "маленький " executable пакетик, так вот если вы берете и ставите пакетик на чужую машину он блин пользуется ssl'ем с чужой машины а так пакетик был бы полностью независим.
У меня от вашего текста глаза вытекли.
Вам мешочек запятых с точками отсыпать ?
не поможет, поверьте,я побывал :)
> не поможет, поверьте,я побывал :)А надо чтобы вас побывали за такой текст. Может тогда дойдет.
столько агрессий, и все "по" теме , к тому же и это от аноним.
Никак, джава использует libnss
> с удалением излишней функциональности"Не удалось установить защищённое соединение, т.к. удалённый хост не поддерживает..."
> "Не удалось установить защищённое соединение, т.к. удалённый хост не поддерживает..."А зачем тебе "защищенное" соединение с 40-битным DES, который Вася на GPU за полчаса распатронит? От чего оно тебя "защитит"? :)