Фонд OSTIF (Open Source Technology Improvement Fund), созданный с целью усиления защищённости открытых проектов, объявил (https://ostif.org/the-ostif-and-quarkslab-audit-of-openssl-i... о завершении независимого аудита ветки OpenSSL 1.1.1 (https://www.opennet.me/opennews/art.shtml?num=49255), сосредоточенного на анализе безопасности алгоритмов и кода, связанных с реализацией TLS 1.3, новых протоколов и переработанного генератора псевдослучайных чисел. Работа выполнена французской компанией QuarksLab, которая находится вне юрисдикции крупнейших спецслужб, заинтересованных в организации слежки, и уже привлекалась для аудита проектов OpenVPN (https://www.opennet.me/opennews/art.shtml?num=46301) и VeraCrypt (https://www.opennet.me/opennews/art.shtml?num=45333). Проведение аудита было профинансировано компанией Private Internet Access (https://en.wikipedia.org/wiki/Private_Internet_Access) и проектом DuckDuckGo.
Аудит не выявил (https://ostif.org/wp-content/uploads/2019/01/18-04-720-REP_v... серьёзных проблем с безопасностью в OpenSSL 1.1.1 и реализации TLS 1.3. Код отмечен в целом как безопасный, быстрый и функциональный, но выявлены отдельные области, в которых качество кода и комментариев могут быть улучшены. Всего разработчикам OpenSSL было предоставлено 16 рекомендаций и исправлений. Для дальнейшего контроля качества проект OpenSSL включён в программу Internet Bug Bounty (https://internetbugbounty.org/), в рамках которой производятся выплаты вознаграждений за выявление уязвимостей и недоработок в области безопасности.
При проведении аудита выявлено 6 проблем, которые были устранены ещё до официального релиза OpenSSL 1.1.1 в ходе приватной переписки разработчики OpenSSL и исследователей, проводивших аудит:
- В некоторых ситуациях соединения могли (https://github.com/openssl/openssl/pull/6852) сбрасываться без обработки ошибки. Проблема могла применяться для осуществления DoS-атаки на клиента (крах приложения) при его обращении к подконтрольному злоумышленнику серверу (например, через организацию MITM-атаки);
- Проблемы (https://github.com/openssl/openssl/pull/6887) с генерацией уведомлений об ошибках, связанных с TLS v1.3. Проблемы можно было использовать для инициирования отказа в обслуживании;
- Высказано несколько замечаний по качеству кода нового генератора псевдослучайных чисел и недостаточно ясному описанию назначения функций в комментариях (функциональные недоработки в PRNG были выявлены ранее, после другого аудита (https://www.opennet.me/opennews/art.shtml?num=49349));- Реализация протокола аутентификации SRP признана корректной, но выявлено отсутствие (https://github.com/openssl/openssl/pull/8019) проверок некоторых возвращаемых значений. Также высказаны замечания по качеству кода и недостаточным пояснениям в комментариях;
- По реализации CAPI замечания коснулись отсутствия комментариев в коде, что значительно затрудняет понимание реализованной логики. Качество кода не вызвало нареканий;
- Во многих внутренних функциях OpenSSL обнаружены случаи отсутствия явных проверок на значения NULL, что потенциально может приводить к непредсказуемому поведению, которое может вылиться в проблемы со стабильностью или безопасностью.
URL: https://ostif.org/the-ostif-and-quarkslab-audit-of-openssl-i.../
Новость: https://www.opennet.me/opennews/art.shtml?num=50004
все 5 лет назад перекатились на libressl
Кто "все"? Можно поимённый список?
оба Васяна и один Колян. Правда, Колян два года назад выкинул эту хрень, в винде она ему ни к чему.
В Debian как не было так и до сих пор нет.
> и уже привлекалась для аудита проектов OpenVPN и VeraCrypt.Да... только после их аудита,в OpenVPN нашли еще несколько уязвимостей:
https://habr.com/ru/post/370573/
>> и уже привлекалась для аудита проектов OpenVPN и VeraCrypt.
> Да... только после их аудита,в OpenVPN нашли еще несколько уязвимостей:
>abr.com/ru/post/370573/Вас заинтересует п.13 http://book.itep.ru/10/merphy.html .
Почему опеннет не поддерживает 1.3? Или это косяк с моей стороны? Захожу с последнего TorBrowser.
> Почему опеннет не поддерживает 1.3?Вы еще utf-8 вместо старого доброго koi8-r потребуйте!
Ох уж эта молодежь!А вообще, гугля c яндексом и микрософтом пока тоже не спешат включить поддержку -- наверное стесняются обойти опеннет.
Осмелюсь предположить, потому что OpenSSL 1.1.1 ещё даже не в Gentoo, не говоря уже о более консервативных дистрибутивах, типа Debian.
> Осмелюсь предположить, потому что OpenSSL 1.1.1 ещё даже не в GentooВызывающе неверная информация:
# ls /usr/portage/dev-libs/openssl
files Manifest metadata.xml openssl-0.9.8z_p8-r1.ebuild openssl-1.0.2q.ebuild openssl-1.0.2q-r200.ebuild openssl-1.1.0j.ebuild openssl-1.1.1a.ebuild openssl-1.1.1a-r1.ebuild
Только он даже не в анстейбле, а замаскирован к чертовой матери. Можешь конечно на свой трах и риск маску убрать.
Ага. Я просто в новый год каким-то образом размаскировал 1.1.1. Задолбался зависимости править. Потом нашёл что натворил и откатился на стабильную версию и всё нормально стало. 1.1.1, конечно, можно поставить, но нафиг это делать на боевом сервере.
Вот уж спасибо. Ставьте на свой страх и риск. Для тех, кому важнее стабильность и кто не хочет экспериментировать:
$ openssl version
OpenSSL 1.0.2q 20 Nov 2018
Чертовски зря. В 1.1.0 убрали необходимость создавать lock-callback-и. Реально стало намного проще жить. Я перешел с 1.1.0i на 1.1.1 с середины сентября. С декабря на 1.1.1a. Полёт нормальный.
за всех не подписывайся, глупое это дело. персонально у меня OpenSSL 1.1.1a уже давно и в Debian 8 (Jessie) и в 9 (Stretch), да и всякие основные сервисы где это требуется (Nginx, Postfix и т.п.) сам давно бэкпортировал с поддержкой TLSv1.3root@vm15:~# aptly repo search jessie openssl
openssl_1.1.1a-1_amd64
openssl_1.1.1a-1_source
openssl_1.1.0j-1~deb9u1_amd64
openssl_1.1.0j-1~deb9u1_sourceroot@vm15:~# aptly repo search stretch openssl
openssl_1.1.1a-1_amd64
openssl_1.1.1a-1_sourceroot@vm15:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.11 (jessie)
Release: 8.11
Codename: jessieroot@vm15:~# nginx -V
nginx version: nginx/1.14.2
built with OpenSSL 1.1.1a 20 Nov 2018 (running with OpenSSL 1.1.1 11 Sep 2018)
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -fPIC -D_FORTIFY_SOURCE=2' --with-ld-opt='-fPIE -pie -Wl,-z,relro -Wl,-z,now -fPIC' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --modules-path=/usr/lib/nginx/modules --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_v2_module --with-http_dav_module --with-http_slice_module --with-threads --with-http_gzip_static_module --without-http_browser_module --without-http_geo_module --without-http_limit_req_module --without-http_limit_conn_module --without-http_memcached_module --without-http_referer_module --without-http_split_clients_module --without-http_userid_module --add-dynamic-module=/root/nginx/nginx-1.14.2/debian/modules/http-echo
Debian свежий, без всяких сторонних репов и тестинга:
openssl version
OpenSSL 1.1.0j 20 Nov 2018
ну сиди и жди тогда Debian 10 :D
ты пока ответ печатал похоже успел забыть, что новость о TLSv1.3 который поддерживается начиная с OpenSSL 1.1.1, так-что твой OpenSSL 1.1.0j тем-более в Debian 9 (Stretch) совсем не по теме новости и текущего обсуждения. на своём примере выше я лишь объяснил что далеко не у всех руки растут из ягодиц, чтоб не суметь портировать любой практически пакет из Sid/Unstable куда угодно
> ты пока ответ печатал похоже успел забыть, что новость о TLSv1.3 который поддерживается начиная с OpenSSL 1.1.1Я ничего не забывал. Я показал, что в текущем Debian версия OpenSSL ниже, чем та, что требуется для TLS 1.3. Соответственно, в случае применения на сервере Debian без костылей включить поддержку TLS 1.3 нельзя.
поддерживать локальный репозиторий и портировать в него необходимые пакеты - костыли? то-есть весь инструментарий для этого тоже костыли? руководствуясь элементарной логикой и твоими высказываниями, получаем: костыли - всё что ты не осилил сделать или даже прочесть
> OpenSSL 1.1.1 ещё даже не в GentooПочему "даже"?
% openssl version
OpenSSL 1.1.1a-freebsd 20 Nov 2018
Любил когда-то её. Но потом всё равно к Linux вернулся.
Вообще-то он уже почти везде, и в Gentoo и в Debian, и даже во Фряхе и слаквари:https://repology.org/metapackage/openssl/badges
думается мне, распоследний твой Tor Browser (8.0.4) не умеет последний TLSv1.3 (тот что final, RFC-8446) - умеет только-лишь какой-то черновик такового, да и-то поддержка его отключена (about:config). потому открывает всё по-старинке в TLSv1.2
Не мешки ворочать ага. Распаковал TORmozilla 8.0.4, зашел на клаудфлер и похороникс - tls 1.3 соединения.
Но да, вопрос глупый, почему, почему, покачану. Не у всех есть желание ручками собирать ради смены точка 2 на точка 3.
Кстати, navalny.com работает на 1.3
как и всё остальное что хостится на Cloudflare
да и потом https://dev.ssllabs.com/ssltest/analyze.html?d=www.opennet.r...
Не умеют они врать. Вот так надо: "В ходе аудита, было выявлено несколько не критичных ошибок, на которых указали разработчикам, и они их исправили. Теперь всё отлично". А они "Не, ошибок нет, бэкдоров нет, троянов нет, стопудово, вообще. Организация, выполнявшая проверку, не связана с государственными органами!"Просто уязвимости в OpenSSL иногда находят (тыкните по тегу, чтобы посмотреть новости на Опеннете), хоть и не конкретно в TLS, а во всём OpenSSL. А потому странно, что аудит не обнаружил вообще ничего. Тем более, в новом крупном релизе, который состоялся недавно
> Аудит не выявилотчеты о покрытии юнит-тестами с результатами - наилучший признак адекватного аудита
> отчеты о покрытии юнит-тестами с результатами - наилучший признак адекватного аудитаНет. Потому что это аудит безопасности, а не работоспособности.
Да и нужно быть лишь чуть-чуть выше джуна чтобы знать что тесты ничего не гарантируют даже при 100% покрытии.
> QuarksLab, которая находится вне юрисдикции крупнейших спецслужб, заинтересованных в организации слежкиНичего не понял.
Автору новости достоверно известно, что только крупнейшие спецслужбы заинтересованны с организации слежки, либо, не крупнейшими спецслужбами можно пренебречь при оценке рисков?
И ещё интересней про что он имел ввиду под юрисдикцие. Когда спецслужбы США воруют людей по всему миру, а армия США без мандата ООН бомбит страны во имя демократии.. это они в рамках юрисдикции делали, стало быть?
>Работа выполнена французской компанией QuarksLab, которая находится вне юрисдикции крупнейших спецслужбНичего не слышал про северокорейские спецслужбы, значит они не относятся к крупнейшим, да?
Любой бизнес и любой сотрудник любого бизнеса, особенно такого бизнеса, который на границе с криминалом (по желанию судьи, а желание судьи от многого зависит), каким является кибербезопасность, продаётся и покупается за возможность не сесть вот прямо сейчас на бутылку.
> Ничего не слышал про северокорейские спецслужбы, значит они не относятся к крупнейшим, да?нет, не относятся.
пару недель назад команда опенссл получила некую премию за
dramatic improvements to the code quality of OpenSSL
https://www.openssl.org/blog/blog/2018/01/10/levchin/
как можно писать код так что отсутствие проверки на NULL не ломает работу логики? не ужели код и был задуман без проверки NULL?!