В OpenSSL выявлена (http://heartbleed.com/) одна из самых серьёзных уязвимостей (CVE-2014-0160 (https://www.openssl.org/news/secadv_20140407.txt)) в истории проекта, затрагивающих огромное число сайтов, серверных систем и клиентских приложений, использующих OpenSSL 1.0.1 для организации обмена данными через защищённое соединение. Суть проблемы проявляется в возможности доступа к 64Кб памяти клиентского или серверного процесса с которым установлено шифрованное соединение.
Практическая опасность уязвимости связана с тем, что в подверженной утечке области памяти могут размещаться закрытые ключи или пароли доступа, которые потенциально может быть извлечены удалённым злоумышленником. При удачном проведении атаки злоумышленник может получить содержимое ключа, используемого для организации шифрованного доступа к серверу, и организовать перехват на транзитном узле защищённого трафика. Также не исключена утечка паролей и других закрытых данных клиентских приложений при попытке их соединения с подконтрольными злоумышленникам серверными системами.
Причиной проблемы является (http://blog.existentialize.com/diagnosis-of-the-openssl-hear...) отсутствие проверки выхода допустимых границ в коде реализации TLS-расширения heartbeat, что позволяет инициировать отправку удалённой стороне до 64Кб данных за границей текущего буфера. По некоторым оценкам проблема охватывает до половины всех серверных систем в сети, включая собранные с OpenSSL 1.0.1 web-серверы (Apache httpd, nginx), почтовые серверы, VPN-системы, шлюзы и скрытые сервисы анонимной сети Tor (https://blog.torproject.org/blog/openssl-bug-cve-2014-0160) и XMPP-серверы.Проблема проявляется только в актуальной стабильной ветке OpenSSL 1.0.1 и тестовых выпусках 1.0.2, прошлые стабильные ветки 0.9.x и 1.0.0x уязвимости не подвержены. Системы, использующие выпуски OpenSSL 1.0.1[abcdef], требуют срочного обновления. Обновления пакетов уже выпущены для RHEL 6 (https://access.redhat.com/security/cve/CVE-2014-0160), CentOS 6 (http://lists.centos.org/pipermail/centos-announce/2014-April...), Fedora 19/21 (https://lists.fedoraproject.org/pipermail/announce/2014-Apri...), FreeBSD (http://www.vuxml.org/freebsd/5631ae98-be9e-11e3-b5e3-c80aa90...), Ubuntu 12.04-13.10 (http://www.ubuntu.com/usn/usn-2165-1/), Debian wheezy/squeeze (https://www.debian.org/security/2014/dsa-2896). В качестве запасного варианта отмечается возможность пересборки OpenSSL с опцией "-DOPENSSL_NO_HEARTBEATS", отключающей TLS-расширение heartbeat. Уязвимость устранена в выпуске OpenSSL 1.0.1g (http://www.openssl.org/). Для проверки серверных систем на предмет наличия уязвимости подготовлен специальный online-сервис (http://possible.lv/tools/hb/). Уязвимость выявлена сотрудниками компании Google.
URL: http://seclists.org/fulldisclosure/2014/Apr/90
Новость: http://www.opennet.me/opennews/art.shtml?num=39518
ай да АНБ, ай да молодцы. это просто 5+
Бритва херлона: Никогда не приписывайте злому умыслу то, что вполне можно объяснить глупостью.
> Бритва херлона: Никогда не приписывайте злому умыслу то, что вполне можно объяснить
> глупостью.Ну SSL и TLS врядли по глупости были напроектирвоаны столь навороченными что ими безопасно пользоваться невозможно. А то что ламеры в шифровании написали свою мегалибу и популяризовали этот крап - ну ок, Шнобелевскую премию им за это.
а утверждения Херлона, типа, истина в последней инстанции, как суждения Папы Римского для католиков?
всегда говорил, что https не нужно, не нужно, не нужно :)
Если в твоей системе с рождения присутствует уязвимость, то вся паранойя вокруг анб ненужна. Подумай в сторону доверенного конпилятора.
извините, но в вашей ахинее я не вижу причинно-следственных связей
> Подумай в сторону доверенного конпилятора.А что не так с компилятором? Он собран майнтайнерами системы, на пакете цифровая подпись данных граждан повешена. Достаточно доверяемо выходит вроде.
А компилятор чем собирать будет маинтейнер, он же из воздуха не возьмётся. Нужен другой компилятор и так отматывай до самого начала.
> А компилятор чем собирать будет маинтейнер, он же из воздуха не возьмётся.
> Нужен другой компилятор и так отматывай до самого начала.Внезапно, до того как появились компиляторы, был мир где компиляторов не было. Это было логично и предсказуемо. Это довольно хитрая инженерная проблема, решение которой называется bootstrap, прозрачно намекая что процесс похож на вытаскивание себя из болота за шнурки своих же ботинок.
Если я отмотаю историю gcc назад, к самому началу - я увижу дядьку Столлмана. Я знаю что Столлман не будет мне делать гадости. Его нельзя купить звонкой монетой. И у него есть определенные принципы. У Столлмана есть странности. Но делать западло - не его методы. Этот играет честно и открыто. Что не помешало ему взять и у...ть разным проприерасам-корпорасам по полной программе :)
Твоё воображение ничего общего с реальностью не имеет.
> Твоё воображение ничего общего с реальностью не имеет.только твоё имеет, ага?
Д'артаньян != Столлман
> Твоё воображение ничего общего с реальностью не имеет.Д'Артаньян, залогинься!
>> Твоё воображение ничего общего с реальностью не имеет.
> Д'Артаньян, залогинься!Легко, есть проблемы ?
> Легко, есть проблемы ?А где апостроф? Говорят, Д'Артаньян не настоящий!
Возможно здесь от слова Dark, поклонение тёмным силами, всё такое.
Ничего ты не понял! Это Дарт Аньян! Как Дарт Вейдер или Дарт Сидиус, например.
> всегда говорил, что https не нужно, не нужно, не нужно :)Да, особенно на всяких сбербанк-онлайнах, там пароли нужно вообще открытым текстом передавать.
Интересно как уважаемый оппонент предлагает защищать передаваемые данные от подглядывания со стороны например провайдера ?
Шифровать ДО передачи по инету.
А ты думаешь, как ssl работает?
еще раз зашифровать)
> Шифровать ДО передачи по инету.MS-виндоботы поражают воображение.
> Интересно как уважаемый оппонент предлагает защищать передаваемые данные от подглядывания
> со стороны например провайдера ?Раньше на всяких "Клиент-банках" и без ССЛ-я всё как-то работало, прикинь!
>> Интересно как уважаемый оппонент предлагает защищать передаваемые данные от подглядывания
>> со стороны например провайдера ?
> Раньше на всяких "Клиент-банках" и без ССЛ-я всё как-то работало, прикинь!До червя морриса вообще о многих вещах не парились, прикинь :)
ага, потому что было отдельное диалап подключение для каждого банка)
а, то есть твой говнобанк вот так и валит нешифрованый поток в соединение, надеясь на https? тогда у меня для тебя очень плохие новости…
> а, то есть твой говнобанк вот так и валит нешифрованый поток в
> соединение, надеясь на https? тогда у меня для тебя очень плохие
> новости…А что, кто-то делает по другому :) ? А именно - вообще не использует https, принципиально.
И какими же средствами обеспечивается защита соединения ? Для домохозяек все так же прозрачно как и в случае https ? - то есть не нужно ставить никакого стороннего софта ?
> А что, кто-то делает по другому :) ?да, все нормальные люди шифруют сами, секретными ключами. впрочем, ты с домохозяйками можешь не заморачиваться, вам без разницы. не понимаю, правда, зачем тогда спич о какой-то «безопасности». это, видимо, ты просто слово крутое услышал — и пихаешь куда ни попадя.
>> А что, кто-то делает по другому :) ?
> да, все нормальные люди шифруют сами, секретными ключами.И какими же средствами обеспечивается защита соединения ?
В ручную что-ли ? каждый GET и POST пропускать через шифровальную машину, которая не-openssl ? )))
Примерно так. Только нет наружу соединения с таким https. Шифровка/дешифровка идет на отдельных серверах, не имеющих прямого выхода в инет.
А вот видимо и сотрудники банков появились, видимо. При том ник сам за себя говорит. Что еще веселее - ник не врет. Понимание процесса - на уровне питекантропа, ффтыкающего на микроволновку.
> А вот видимо и сотрудники банков появились, видимо. При том ник сам
> за себя говорит. Что еще веселее - ник не врет. Понимание
> процесса - на уровне питекантропа, ффтыкающего на микроволновку.Мне одно не понятно - банк как сможет расшифровать ваши данные ? Нет, если конечно пойти в банк, написать заявление на изготовление ключа, недели за две вам его сделают, вы придете домой, установите КриптоПро (купив естественно, банки по другому не умеют), по***авшись с установкой ключа, купив dial-up модем для связи с банком - тогда да, без https будет вам шифрованное счастье - это хорошо для организаций но для домашних пользователй с динамическим ip - НА*ЕР не нужно.
Вы бы хоть пример банка привели, который работает по вашей схеме - подключиться и посмотреть как оно работает :)))
> Мне одно не понятно - банк как сможет расшифровать ваши данные ?
> Нет, если конечно пойти в банк, написать заявление на изготовление ключа,
> недели за две вам его сделают, вы придете домой, установите КриптоПро
> (купив естественно, банки по другому не умеют), по***авшись с установкой ключа,
> купив dial-up модем для связи с банком - тогда да, без
> https будет вам шифрованное счастье - это хорошо для организаций но
> для домашних пользователй с динамическим ip - НА*ЕР не нужно.
> Вы бы хоть пример банка привели, который работает по вашей схеме -
> подключиться и посмотреть как оно работает :)))Генеришь ключи, относишь на бумажечке. Покупать ничего не нужно. Есть онлайн-версия на жабе, правда, с некоторых требует только сановскую.
> Генеришь ключи, относишь на бумажечке. Покупать ничего не нужно. Есть онлайн-версия на жабе, правда, с некоторых требует только сановскую.Ааа, это тот банк (та система), где ключи ещё должны лежать на диске A: или B:?
И линуксовым/маковским юзерам приходится извращаться и создавать каталоги с таким именем в корне?
Сейчас в этих банках смарткарты и токены под собственным брендом, а линукс и мак пользователи все также идут лесом как и раньше.
Причем, выбор банка в организации никак не связан с прямотой его работы. Начальник сказал - все. У него там какие-то скидки или просто по знакомству попросили.
Для себя же есть банки с двойной аунтификацией пароль/мобила. Только на моем сабжевую дыру еще не залатали, лохопеды.
> Ааа, это тот банк (та система), где ключи ещё должны лежать на
> диске A: или B:?
> И линуксовым/маковским юзерам приходится извращаться и создавать каталоги с таким именем
> в корне?Нет, лежит где положишь. Система кажись эта, тут и демка какая-то есть:
http://www.csltd.com.ua/ru/products/for-banking/ifobs.html
Ох, еще один питекантроп. Блин, народ, куда у нас модно посылать питекантропов, если они не совсем безнадежные? В плане криптографических FAQ, доступных для начального понимания даже питекантропам.И да, моя схема - это какая? Я вроде не настолько крутой человек чтобы свои схемы шифрования придумывать, на такие навороты у меня квалификации не хватит, имхо. Я могу более-менее осмысленно выбирать существующие схему и/или комбинировать их для достижения нужных свойств. А мне почему-то приписывают создание каких-то схем...
> Ох, еще один питекантроп. Блин, народ, куда у нас модно посылать питекантропов,
> если они не совсем безнадежные? В плане криптографических FAQ, доступных для
> начального понимания даже питекантропам.Ко криптокантропам, очевидно.
> И какими же средствами обеспечивается защита соединения ?для тебя, кретина, ещё раз повторяю: *соединение* защищать не надо. дальше повторяй это себе сам.
> для тебя, кретина, ещё раз повторяю: *соединение* защищать не надо. дальше повторяй
> это себе сам.К сожалению, эти люди иной раз лезут в области где подразумевается передача ценных данных.
> К сожалению, эти люди иной раз лезут в области где подразумевается передача
> ценных данных.это да. причём они даже не понимают, насколько они ничего не понимают. эффект Даннинга-Крюгера.
> да, все нормальные люди шифруют сами, секретными ключами. впрочем, ты с домохозяйками
> можешь не заморачиваться, вам без разницы. не понимаю, правда, зачем тогда
> спич о какой-то «безопасности». это, видимо, ты просто слово крутое услышал
> — и пихаешь куда ни попадя.про крутые слова смешно читать от человека, постоянно использующего "спич"
> про крутые слова смешно читать от человека, постоянно использующего "спич"а дуракам всегда смешно. потому что дураки.
p.s. кретин, защищать надо не «соединение», а данные. иди, осмысливай.
Если соединение скомпрометировано, то данным можно тоже помахать ручкой, т.к. по этому соединению вам может прилететь все что угодно, внешне "похожее" на сайт банка.
оно не «если», оно однозначно. https — иллюзия безопасности, и поэтому оно вредно. равно как и пользование «сайтами банков». увы.
> оно не «если», оно однозначно. https — иллюзия безопасности,Если пользоваться самоподписаными сертификатами, или же давай пруф на статью которая доказывает что https с валидными сертификатами - пустое место и не дает никакой защиты вообще.
Нет вы на него посмотрите - все пользуются (ну почти все) https, а этот крутой чувак такой эксперД, что одному "и так все понятно" что https - полная ерунда :)))))
> что https с валидными сертификатами - пустое местоГуглить про comodohacker, DigiNotar и какими сайтами умел представляться этот хакерь, собственно. Хинт: он себе сертификаты выписал на Windows Update, Skype, Mozilla, Google и кого я там еще забыл. Понятно что после такого демарша Diginotar'у как CA пришел пиндец, но это не отменяет того факта что некоторое время у чувака были валидные сертификаты, удостоверяющие что вот этот хрен - гугл, мозилла и скайп вместе взятые. И т.к. они подписаны "доверяемым CA" - у браузера никаких вопросов по этому поводу не возникало.
Да-да, в TLS/SSL любой CA из длиииинного дефолтного списка "доверяемых" CA может удостоверить кому угодно что угодно, по желанию своей левой пятки. Некоторые обнаглели настолько что уже почти в открытую выписывают поддельные серты производителям IDSок для "инспектирования" (==взлома) SSL-соединений.
> никакой защиты вообще.
А какая защита, если любой из кучи CA может выписать Васе-комодохакеру или Пете-агенту-АНБ сертификат того что это не Вася и не Петя, а Гугл и Мозилла, вместе со скайпом, гмылом и фэйсбучиком?
> Нет вы на него посмотрите - все пользуются (ну почти все) https,
Миллионы мух не могут ошибаться, да?
> Хинт: он себе сертификаты выписал на Windows Update, Skype, Mozilla, GoogleНо сейчас то никто его трюк повторить не сможет, так ?
> Но сейчас то никто его трюк повторить не сможет, так ?Нет, не так. А что принципиально изменилось с того момента? Не вижу что помешает повторению этой ситуации. Особенно учитывая что некоторые CA чуть ли не в открытую выписывают серты для взлома SSL IDSками анализирующими трафф.
>> Хинт: он себе сертификаты выписал на Windows Update, Skype, Mozilla, Google
> Но сейчас то никто его трюк повторить не сможет, так ?откуда у тебя такие выводы?
> А какая защита, если любой из кучи CA может выписать Васе-комодохакеру или
> Пете-агенту-АНБ сертификат того что это не Вася и не Петя, а
> Гугл и Мозилла, вместе со скайпом, гмылом и фэйсбучиком?Это не проблема HTTPS. Проблема в некоторых CA.
Кто-нибудь например может выдавать свой сертификат. Самоподписанный. В конторе лично. (при чём всем желающим).
Мозилловские браузеры могут иметь предустановленные сертификаты для доступа к google. И т д.
В остальных случаях могут использоваться разные многочисленные CA. Иногда способствующие выявлению...
> Это не проблема HTTPS. Проблема в некоторых CA.Как бы это сказать? Толпа прихлебателей, которым либа/браузер/... по дефолту "доверяют", хотя на самом деле я этих удодов в первый раз в жизни вижу и уж тем более не имею никаких оснований им "доверять" - оптимизма совершенно не внушает. Поскольку могут "мамой клянус!" удостоверить что вон тот хрeн с горы - гугл и мозилла, скайп, фэйсбук или мой собственный сайт, etc. Просто потому что им ничто не мешает это сделать, бабло побеждает зло, ничего личного это бизнес, ну и все такое прочее.
> Кто-нибудь например может выдавать свой сертификат. Самоподписанный. В конторе лично.
> (при чём всем желающим).Может. А если в браузере прописано 100500 CA, самозванец может выписать сертификат похожий на вид на самоподписанный, заверить его в одном из 100500 CA, завернуть народ на левый сервер и ХРЕН КТО ЗАМЕТИТ что что-то идет не так.
> В остальных случаях могут использоваться разные многочисленные CA.
> Иногда способствующие выявлению...Уточним: разные многочисленные CA могут выписывать что угодно. Любой из них. Поэтому если некто выпишет завтра Васе сертификат на то что это мозилла и фэйсбук - вычислить негодяев без изучения сертификата специалистом под микроскопом не получится. Обычные юзери вообще без шансов. Гуру конечно может фингерпринт проверить, но врядли вы их наизусть заучиваете, да и есть легитимные поводы по которым сертификат может измениться, например истечение его срока годности.
> Миллионы мух не могут ошибаться, да?Кем доказано, что речь идет про го*но?
Так проблема-то не в HTTPS а инфраструктуре CA.
> Так проблема-то не в HTTPS а инфраструктуре CA.Проблем несколько.
1) PKI - лохоразвод. Сколь-нибудь надежно это может быть только если CA вообще один. Лично ваш. И сколько реально существующих применений PKI именно так работают? Понятно почему это лохоразвод? Потому что в безопасном и доверяемом виде не используется почти никогда. Вместо этого предлагается доверять толпе каких-то левых контор. А вы точно доверяете всем этим левым шарагам? У них там "ничего личного, это бизнес".
2) Протокол наворочен до ж...ы! Это кроме всего прочего означает кучу багов и в разных фичах оного и в либе.
3) Валидация сертификатов, особенно запоминание и контроль смены фингерпринта не делается в нормальном виде чуть менее чем никем. Большинство софта вообще класть хотело какой там сертификат у сервера, что он изменился, и что это вообще левый сервер, который радостно качает шлангом расшифрованные данные и гоняет их между вами и тем сервером куда вы хотели на самом деле пойти.
4) И в либах и в протоколе уйма легаси. И не то чтобы кто-то сильно парился по поводу дефолтов. А еще поддерживается 100500 алгоритмов. Включая древний и несекурный шит, "для совместимости". Да еще с ремотой согласовывается, при том какие там дефолты - полная лотерея. При этом шифрование как бы есть, но то что используются сколь-нибудь секурные алгоритмы - далеко не факт. А много ли авторов софта заморочилось тем чтобы заказать наиболее стойкие алгоритмы как наиболее приоритетные? Ах, чуть более чем никто?Ну вот как-то так оно и работает. В смысле, если вы Берштейн, или Шнайер - вы может и сможете этим безопасно пользоваться. Только оно вам нафиг не упало, потому что вы сделаете свой алгоритм, в разы лучше. А если вы простой смертный - ну, удачи использовать SSL/TLS секурно, в том числе и в виде OpenSSL. Нет, криптография конечно ляпов не прощает, но в SSL/TLS и OpenSSL есть вообще все для того чтобы реализатор пролошился хренадцать раз подряд, если он не профессиональный криптограф.
> Если соединение скомпрометировано, то данным можно тоже помахать ручкой,Вообще-то, криптография ставит своей задачей в том числе и передачу данных по ненадежным каналам. Но да, такой примитивизм питекантропского мышления просто умиляет.
сложно сказать, кто тут более кретин. множество сетевых атак как раз строится на неверифицированных соединениях.
любая идея защищать *соединиение*, а не *данные* — придумана идиотами для успокоения идиотов.
> любая идея защищать *соединиение*, а не *данные* — придумана идиотами для успокоения идиотов.Какое хорошее описание OpenSSL и тех кто им пользуется.
>> любая идея защищать *соединиение*, а не *данные* — придумана идиотами для успокоения идиотов.
> Какое хорошее описание OpenSSL и тех кто им пользуется.хинт: OpenSSL — это ещё и библиотека алгоритмов шифрования. которые можно использовать для шифрования данных *внутри* *своего* *софта*, до передачи их куда-либо.
то, что API у него наглухо неадекватный, и чтобы ним правильно пользоваться, надо нехило понимать что делаешь — это да. ну так в криптографии вообще очень полезно понимать, что делаешь.
> хинт: OpenSSL — это ещё и библиотека алгоритмов шифрования. которые можно использовать
> для шифрования данных *внутри* *своего* *софта*, до передачи их куда-либо.Это да, но понимаешь ли, там SSL/TLS есть, и вон то стадо долбодятлов начинает верить что оно их от всего защитит. При этом долбодятлы ни в зуб ногой какие там есть алгоритмы, для чего и чем отличаются, как выглядит TLS handshake, etc (честно говоря протокол настолько наворочен что ). ИЧСХ большинство софта как-то так пишется теми кто в криптографии ни разу не эксперт. Насколько этому софту наличие либы OpenSSL помогает - ну ты понял.
> криптографии вообще очень полезно понимать, что делаешь.
Ну вот дяденька Берштейн в курсе и поэтому вывесил такоe API в котором даже долбодятлу будет сложно прострелить себе пятку. Отличный подход - дать простую функцию для дерга. А те кто понимает - может подергать составные части, если считает себя достаточно квалифицированным. Ну вот как-то так это и надо делать.
Ну я понимаю Кэпа. Иногда очень хочется честно сказать кретину что он - кретин. Это выглядит как наезд, но на самом деле это лишь констатация печального факта, не более.В частности, если некто смеет высказывать какие-то мнения по криптографии, подразумевается что гражданин владеет тематикой как минимум на базовом уровне. То-есть прочел FAQ'и и осознал основные определения, алгоритмы и прочая, типовые варианты применений, etc. Чем отличается криптография с публичным ключом от симметричного шифрования, etc. Какие алгоритмы бывают, чем отличаются. Что секурно, а что нет.
А когда дублан думает что "о, эта мегасуперлиба меня защитит от всего", а авторы либы фигарят на своей волне и вообще откровенно ламерят местами - результат получается достаточно печален.
> любая идея защищать *соединиение*, а не *данные* — придумана идиотами для успокоения
> идиотов.Соединение и есть данные. Просвещайся, неуч.
> Соединение и есть данные.Совершенно не обязательно. Могут быть и служебные сущности, например. Но грамотеи же не читали описание хоть того же TLS, правда?
> тогда у меня для тебя очень плохие новости…Еще более плохая новость: обезьяны которые пишут этот банковский крап обычно не смогут написать даже нечто с уровнем защищенности TLS. Если кто не понял: Houston, we have a problem, http://www.theguardian.com/commentisfree/2013/sep/05/governm...
Да, сейчас с безопасностью в интернете *плохо*. SSL/TLS - большой фэйк, но те индусы кто пишут клиент-банки - еще хуже и не напишут даже такое.
это совершенно не повод считать https какой-то там «защитой».
> это совершенно не повод считать https какой-то там «защитой».Спасибо, я в курсе свойств SSL/TLS и мне они не нравятся. За все это я и не жалую openssl. Ее авторы тоже те еще бакланы, которые могут подложить весьма неожиданных сюрпризов, ибо те еще ламеры в криптографии, судя по наблюдаемым продолбам. По крайней мере, юзануть RDRAND совсем без подмешивания сторонней энтропии - это факин шит, товарищи!!!
>> это совершенно не повод считать https какой-то там «защитой».
> Спасибо, я в курсе свойств SSL/TLS и мне они не нравятся. За
> все это я и не жалую openssl. Ее авторы тоже те
> еще бакланы, которые могут подложить весьма неожиданных сюрпризов, ибо те еще
> ламеры в криптографии, судя по наблюдаемым продолбам. По крайней мере, юзануть
> RDRAND совсем без подмешивания сторонней энтропии - это факин шит, товарищи!!!Пожалуйста, предложи криптографический casino-grade (как на колесах рулетки пишут) аппаратный ген энтропии стоимостью 2 бакса - и к тебе тут же выстроится двухмиллионная очередь. Озолотишься.
> Пожалуйста, предложи криптографический casino-grade (как на колесах рулетки пишут)С казино известно много приколов. Как минимум одному гражданину запретили вход во многие казино лишь за то что он набирал статистику по выпадению номеров и потом (вы только подумайте, какой негодяй) ставил на наиболее вероятные номера, умудряясь разувать казино. Из-за некоторой неидеальности реальных рулеток, распределение "casino-grade (как на колесах рулетки пишут)" может несколько отличаться от идеала. В лучшем случае - достаточно для того чтобы казино начало пролетать, если кто статистику накопил и асимметрию вычислил :)
> аппаратный ген энтропии стоимостью 2 бакса -
Даже дешевле можно. Тепловой шум, etc.
> и к тебе тут же выстроится двухмиллионная очередь. Озолотишься.
Понятно, единственное что вы умеете - ламерить в темах в которых не разбираетесь.
> это совершенно не повод считать https какой-то там «защитой».Хватит уже изголяться. Ты альтернативу предложи.
> Да, особенно на всяких сбербанк-онлайнах, там пароли нужно вообще открытым
> текстом передавать.Ну передашь ты его шифрованным, только окажется что это был не тот сервер. Но никто и не пикнет.
> Интересно как уважаемый оппонент предлагает защищать передаваемые данные от
> подглядывания со стороны например провайдера ?Ну ок, выпишет некто их 100500CA сертификат прову и будет он бампать SSL. При этом браузер или кто там еще и не пикнет - а что, валидный сертификат от доверяемой CA, ничего не знаю!
>> Да, особенно на всяких сбербанк-онлайнах, там пароли нужно вообще открытым
>> текстом передавать.
> Ну передашь ты его шифрованным, только окажется что это был не тот
> сервер. Но никто и не пикнет.Так, допустим некто организовал атаку M-I-M и стал через себя траффик пропускать, допустим без шифрование соединения. Перехватчики перехватили мой хеш пароля и передают его банку, и банк его принимает, так ?
И что до сих пор не придумано никаких механизмов защиты от таких "кулхацкеров" ?
Насколько я знаю, даже самая простая авторизация с применением шифрованного пароля имеет небольшую защиту:
хеш пароля это не только md5 (для примера) от "пароля", а md5 от {uniqid}:{password}:{что-то еще}
где uniqid - уникальный id для каждой сессии, ну станет удаленная сторона для меня проксей, но сама то рулить сессией tcp не сможет. А хеш пароля им ничего не даст, вообще.
> Ну ок, выпишет некто их 100500CA сертификат провуКто выпишет ?, давайте по конкретней !
> Так, допустим некто организовал атаку M-I-M и стал через себя траффик пропускать,
> допустим без шифрование соединения.Зачем? Он ставит свой сервак, который "я, типа, банковский сервер". SSL делается до него. Если сертификат этого сервера хавается за чистую монету - нет проблем. Клиент начинает гонять данные. Данные расшифровываются. Изучаются и меняются. Поднимается SSL конекция к настоящему банку, ему отправляются данные. Для клиента все выглядит как будто он просто поработал с банковским сервером. А то что его немного запроксировали и изучили и/или пропатчили данные - нуу... вот такая вот хорошая защита в SSL, что в ряде случаев такое западло обнаружено и зарублено не будет. Потому что из 100500 доверяемых CA кто угодно может выписывать сертификаты на что угодно. В том числе и сертификат вон тому левому серверу на то что это, типа, сервер банка, а вовсе и не левый сервер нифига.
> Перехватчики перехватили мой хеш пароля и передают
> его банку, и банк его принимает, так ?Для начала, совсем не факт что там хэш а не просто пароль в чистом виде. Если кто уповал на SSL - могли и в чистом виде отправить. А даже если и не уповали - совсем не факт что они крутые криптографы и нигде не налажали. Если ты просто посылаешь хэш пароля - это ничем не лучше чем посылка пароля. А какая атакующему разница, слать пароль или его хэш? :)
> И что до сих пор не придумано никаких механизмов защиты от таких
> "кулхацкеров" ?Придумано то много чего. Например чтобы не слать пароль можно делать challenge-response. При этом сначала сервер кидает рандом, а клиент считает response=hash(random, password) и шлет что получилось на сервер. Сервер считает hash(random, password) и если это совпало с тем что прислал клиент - ок, клиент знал пароль. Это если упомянутый неандертальский пример немного окультурить.
> Кто выпишет ?, давайте по конкретней !
А любой из кучи CA может. По желанию левой пятки. Кому вся эта ватага и что выписывает - "после узнаете".
> что это, типа, сервер банка, а вовсе и не левый сервер
> нифига.Щас попробую вникнуть:
1. Мне отравили DNS, и для меня валидным ip банка теперь считается ip злыдня
2. Злыдни загодя заказали сертификат для моего домена (допустим CA не потребовали чтобы почта была на том же домене что и сайт) и получили его.
3. Они разместили этот сертификат на своем https-сервере, и мой браузер обращаясь к фейковому https не чует подмены, потому что полученный сертификат проходит все проверки.Сомнение вызвает пункт 2 - я что могу получить сертификат для mail.ru ?
> Щас попробую вникнуть:За кадром слышен натужный скрип мозга питекантропа: "электричество... магнетрон.... волны... черт, как все сложно! А я то думал - нажимаешь кнопку, готовится еда!"
> 1. Мне отравили DNS, и для меня валидным ip банка теперь считается ip злыдня
Как один из вариантов. А еще могли просто поставить transparent proxy, вклиниться в провод (или подставную точку wi-fi поставить), etc. Как будто мало методов, блин.
> 2. Злыдни загодя заказали сертификат для моего домена (допустим CA не потребовали
> чтобы почта была на том же домене что и сайт)Ну да. Т.к. любой CA может выписать серт на что угодно, какой-то из этой кучи может по долбоклюйству (как DigiNotar) или просьбе властьимущих (NSA одобряет), или просто потому что бабло побеждает зло - производители IDS вполне готовы доплатить за такую магию, разумеется, чтобы предоставить клиенту новую кульную фичу - анализ "защищеных" соединений путем снятия защиты, собственно.
> и получили его.
Ну comodohacker ведь получил. И производители IDSок получают, чуть ли не в открытую. Ищи новости о том как мозилла собиралась какой-то CA за это выпнуть.
> 3. Они разместили этот сертификат на своем https-сервере, и мой браузер обращаясь
> к фейковому https не чует подмены, потому что полученный сертификат проходит все проверки.Именно так. Это валидный сертификат, выписанный на "якобы твой сайт". Он другой, но заметить это может только внимательный параноик, который знает что у сертификата есть fingerprint и он при этом разумеется будет разным, т.к. это иной сертификат.
> Сомнение вызвает пункт 2 - я что могу получить сертификат для mail.ru?
Ну вот конкретно ты может и не можешь. А производители IDSок и comodohacker вот смогли, при том от последнего стоял жуткий грохот кирпичей. И никаких изменений предотвращающих это в будущем сделано не было.
>[оверквотинг удален]
>> 3. Они разместили этот сертификат на своем https-сервере, и мой браузер обращаясь
>> к фейковому https не чует подмены, потому что полученный сертификат проходит все проверки.
> Именно так. Это валидный сертификат, выписанный на "якобы твой сайт". Он другой,
> но заметить это может только внимательный параноик, который знает что у
> сертификата есть fingerprint и он при этом разумеется будет разным, т.к.
> это иной сертификат.
>> Сомнение вызвает пункт 2 - я что могу получить сертификат для mail.ru?
> Ну вот конкретно ты может и не можешь. А производители IDSок и
> comodohacker вот смогли, при том от последнего стоял жуткий грохот кирпичей.
> И никаких изменений предотвращающих это в будущем сделано не было.Плз, не надо столько громких слов.
Объясни этому баклану, что PKI (Который x509) это не только шифрование, но и, прежде всего, аутентификация и защита от подмены. Пусть пендует на интуит ввкуривать ликбезы до просветления.
> Плз, не надо столько громких слов.
> Объясни этому баклану, что PKI (Который x509) это не только шифрование, но
> и, прежде всего, аутентификация и защита от подмены.Это прежде всего лохотрон, который претендует на то что он типа, аутентификация, и типа защита от подмены. На практике это, ясен пень, в большинстве реализаций не работает.
> Пусть пендует на интуит ввкуривать ликбезы до просветления.
Хз кто такое интуит, но пендовать надо куда-нибудь в FAQ по криптографии. И PKI и x509 далеко не лучшие примеры того как это бывает.
Отключи heartbeat.
И всё.
http://www.linuxtag.org/2012/en/program/speaker-features/fea... - автор злополучного бага (http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=...)
А сколько еще неизвестных общественности критических уязвимостей. Бояться надо не то, что знаешь, а то, что не знаешь)
все параноики так и делают
И правильно, ведь всё знать невозможно и повод для страха есть всегда. :)
А чё бояться то? Ну есть язвы, ну может у тебя давно бэкдор, мир не без "добрых" людей, и что с того? Нужно не бояться, а думать о способах обезопасить компьютер. Или читать литературу по теме. Когда-нибудь, да научишься в безопасности разбираться.
> Когда-нибудь, да научишься в безопасности разбираться.А бояться надо того что чего-то не учел и не заметил, разумеется. То-есть, собственных продолбов.
Вот за что-то такое мы и любим nacl от дяденьки берштейна. Хорошее средство от обиронов с криптографией.
> Вот за что-то такое мы и любим nacl от дяденьки берштейна.рад за вас. где можно скачать ваши патчи к софту, который использует OpenSSL, дабы заменить его на nacl?
Нельзя. Пакет станет популярным, это вредит неуязвимости продукта.
> Нельзя. Пакет станет популярным, это вредит неуязвимости продукта.В SSL/TLS и OpenSSL как реализации вредят совсем иные вещи, как то пи...цкая навороченность с кучей опций и легаси. Секурно пользоваться этим - сложнее чем стать капитаном воздушного судна. А вот то что те кто программы пишут имеют квалификацию криптографа экстра-класса - вот это совсем не факт. Так что подстава, да.
Синдром неуловимого Джо?
> Синдром неуловимого Джо?Более того, хорошая криптография проверки толпой народа не боится.
Нигде. OpenSSL (и SSL/TLS вообще) сделаны так, что секурно ими пользоваться может полтора академика, являющихся экспертами в криптографии. Тогда они смогут вызвать правильные алгоритмы и нигде не продолбаться. Сколько таких среди авторов софта - ну ты понял. А все остальные обречены продалбываться. Не говоря о том что сам протокол SSL/TLS и либа соответственно - жутко наворочены и имеют массу опций. Это гарантирует туеву хучу багов.ИМХО самое умное что можно сделать - просто считать что этот крап не существует. Как средство защиты данных. Не полагайся на то что это гомно сможет защитить твои данные, чтобы потом не было мучительно больно.
мягко намекаю, что *уже* есть куча софта, которая использует OpenSSL. поскольку я вижу тут любителя nacl, то я так понимаю, что оный любитель успешно патчит софт для использования nacl (иначе он просто балабол). вот и спрашиваю: где патчи-то взять?
> мягко намекаю, что *уже* есть куча софта, которая использует OpenSSL.При том большинство оного по факту использует сие в виде декоративной бесполезной ширмы - мол, а мы типа тоже умеем шифрование \m/ \m/. Правда, никто не проверяет, тот ли сертификат приехал от сервера, и уж конечно никто не париться указать либе секурные алгоритмы. Тем более что в TLS/SSL еще и ремотный сервер мнение имеет. А там его либа и его дефолты. Подпихнет он тебе DES какой-нибудь, и никто и не пикнет. Каким ауторити эта ... по дефолту доверяет в конкретной системе/инкарнации - без поллитра не разберешься.
А если этого мало и ты хочешь поиметь мнение о квалификации разработчиков конкретно OpenSSL, посмотри на ченжлог свежих версий Tor, чувакам пришлось воркэраундить эталонный кретинизм авторов SSLной либы: если попросить аппаратное ускорение шифрования....аппаратный генератор случайных чисел просто напрямую выдается как есть, остальные источники энтропии за каким-то лешим отправляются в пешее(!!!). Подмешивать вывод аппаратного генератора к чему-то еще? Ну что вы, как можно! А как АНБ будет ключи подбирать?! А потом вот так через несколько годиков окажется что генератор случайных чисел у интела не совсем случайный, и чего? Дебиан номер два, опять рекеить все машины, теперь те которые с RDRAND? Как видишь, мое мнение что авторы openSSL долбодятлы возникло не на пустом месте.
> поскольку я вижу тут любителя nacl, то я так понимаю, что оный любитель
> успешно патчит софт для использования nacl.Нет, ты неправильно понимаешь. Любитель нашел хорошую вещицу и осознал что теперь для новых дизайнов будет пользоваться чем-то таким.
> (иначе он просто балабол)
- Парни, этот самолет старый, он выработал свой ресурс! Сдайте на металлолом!
- Что? Где твои инструменты?! А ну чини эту рухлядь давай!
- Парни, его списать надо. Это единственный вариант. Е#$%тся!
- Балабол!!! А ну давай заплатки накладывай!
- (сматывая удочки) Ну ок, удачного полета.Я не знаю, как понятнее объяснить что общая гнилость фюзеляжа никак не лечится одной-двумя заплатками?
> вот и спрашиваю: где патчи-то взять?
Я думаю пример с самолетом хорошо объясняет ситуацию. Если весь фюзеляж от многочисленных взлетов и посадок в микротрещинах, единственное что с ним можно сделать - сдать в металлолом. Нет никакого способа починить глобально разваливающуюся конструкцию. Нет, одна-две заплатки ситуацию не исправят. API OpenSSL - это одна из больших проблем, вносящих свой вклад в галимую секурность софта который этим пользуется. Единственный фикс - сделать заново. Но ты в своем праве лететь гнилым самолелом. Я честно предупредил что он может развалиться в воздухе, а дальше у каждого своя голова на плечах.
ок. где взять замены всему софту, который использует OpenSSL, от любителей nacl? меня не интересует «отличная библиотека в вакууме», меня интересует рабочий софт. как это понятней пояснить?
> меня не интересует «отличная библиотека в вакууме», меня интересует рабочий
> софт. как это понятней пояснить?"У меня полный аэродром самолетов выработавших свой ресурс! Что же мне с ними делать?"
Ну я понимаю что ситуация досадная, вроде самолеты совсем как настоящие, даже летают в принципе, только пользоваться очень стремно. Ну вот и тут как-то так же. Софт есть. Только рабочий он по какому угодно критерию. Кроме защиты данных через SSLное шифрование. Уповать на эту защиту - себе дороже. Развалится в воздухе.
>> меня не интересует «отличная библиотека в вакууме», меня интересует рабочий
>> софт. как это понятней пояснить?
> "У меня полный аэродром самолетов выработавших свой ресурс! Что же мне с
> ними делать?"Есть распространённые и мощные БД, есть веб-серверы, есть куча другого софта, использующего SSL/TLS для соединений. При этом основной их функционал - не шифрование, так что заменять софт целиком не нужно, нужно заменить только модули защиты данных.
Об этом разговор же.
Свои проекты - это совсем другой вопрос.
> Есть распространённые и мощные БД, есть веб-серверы, есть куча другого софта,Ну я и говорю - полон аэродром стремных самолетов с гнилыми внутренностями, которые вроде нормальные на вид, но летать на них дико стремно.
> использующего SSL/TLS для соединений. При этом основной их функционал - не шифрование,
И за декларацию/реализацию "типа, шифрования" которое ничего не защищает - яйцы надо обрывать, т.к. создает ложную иллюзию защищенности, при том что мнение о уровне защиты у юзеров и тех кто это кодил может здорово не совпасть с тем что есть по факту.
> так что заменять софт целиком не нужно, нужно заменить только модули
> защиты данных.Нужно? Заменяйте. Я не против. Но как я уже сказал, OpenSSLное апи - часть проблемы, ибо секурно им пользоваться - рокетсайнс. Это отнюдь не косметическая переделка. Это сдать в утиль то что было и сделать заново.
> Свои проекты - это совсем другой вопрос.
Вопрос - о защите данных как таковых. И если это делалось по остаточному прнципу, "мы тут для галочки OpenSSL привинтили" - результат будет чертовски предсказуем.
>> меня не интересует «отличная библиотека в вакууме», меня интересует рабочий
>> софт. как это понятней пояснить?
> "У меня полный аэродром самолетов выработавших свой ресурс! Что же мне с
> ними делать?"
> Ну я понимаю что ситуация досадная, вроде самолеты совсем как настоящие, даже
> летают в принципе, только пользоваться очень стремно. Ну вот и тут
> как-то так же. Софт есть. Только рабочий он по какому угодно
> критерию. Кроме защиты данных через SSLное шифрование. Уповать на эту защиту
> - себе дороже. Развалится в воздухе.Угу. Давайте запретим авиацию как класс, пока не создадут новые самолеты.
Есть вещи, которые сделать просто не реально.
> Угу. Давайте запретим авиацию как класс, пока не создадут новые самолеты.Декоративное "типа, шифрование" вредно хотя-бы тем что дает ложную уверенность что оно от чего-то может защитить. Вон одни чудики тоже думали что фанерка защитит их от пуль из снайперской винтовки. А оказалось что фанерка - не такая уж и крутая защита от пуль. Вот и с SSL как-то так же получается.
> Есть вещи, которые сделать просто не реально.
А что именно по вашему не реально? Прекратить врать самому себе и начать разбираться в тематике в которую суешься? Ну тогда выращивайте рассаду, там попроще.
лететь-то на чём, а? лететь *уже* надо. есть замена? нет? только вопли, что «вот этот-то точно упадёт, а наш когда-нибудь будет построен»? ок. я рад. лететь как?
> лететь-то на чём, а? лететь *уже* надо. есть замена? нет? только вопли,
> что «вот этот-то точно упадёт, а наш когда-нибудь будет построен»? ок.
> я рад. лететь как?В зависимости от - я считаю что самолета нет, или конструирую новый. Лететь на этой хреновине у которой фюзеляж в воздухе рассыпется мне не хочется, несмотря на увещевания перевозчика что это "безопасно".
ещё раз повторяю: лететь надо *уже*. «поехали, потом заведёшь», ага?
> ещё раз повторяю: лететь надо *уже*. «поехали, потом заведёшь», ага?Ну раз надо - лети. Правда у тебя интересно получается. Если в дебиане лажа - они лошпеды и все такое, а авторы OpenSSL которые помогли пролошиться - все в белом. А если пролошились авторы OpenSSL (при том они это делают часто и увесисто, и на то есть причины) - начинается нытье "аа, ну что же делать, уже куча софта есть". Тебе не кажется что тут просматриваются двойные стандарты? Криптография - она как осетрина, только первой свежести бывает. Или уж работает, или уж фуфло. То что у тебя куча софта с фуфлом, которое годится только для отвода глаз и пудрения мозгов - никак не улучшает защищенность данных и никак не устраняет тот факт что это навороченный монстр с кучей опций, рулить которым сложнее чем боингом и в котором дохрена багов, поэтому в большинстве программ он живет своей жизнью и выступает декорацией "а я вроде что-то защищаю", толку от такой "защиты" сам понимаешь сколько.
Эталонный пример: xchat и hexchat даже fingerprint сертификата не показывают. То-есть, ты даже не заметиш что это не тот сертификат. Но формально SSL как бы поддерживается, да. Правда, толку то с него при такой реализации? Ведь даже компетентный человек с такой реализацией не заметит подмену сертификата. Какая при этом защита? А никакой.
я что-то говорил про то, что в чём? не надо бредить, ты перечитай мои комментарии. ещё раз: я спрашивал у любителей соли, где их патчи к софтам, использующим OpenSSL. нет патчей? ну ок, я рад, что любители обмазываются в углу солью и мастурбируют, но никакого практического значения это не имеет.
> перечитай мои комментарии. ещё раз: я спрашивал у любителей соли, где
> их патчи к софтам, использующим OpenSSL. нет патчей?Естественно. Я не могу запатчить парой заплаток фюзеляж, который по всей поверхности в микротрещинах. Его можно только сдать в металлолом и сделать новый. API openSSL категорически не способствует сколь-нибудь безопасному использованию этой либы. Как ты это патчить то предлагаешь, чудило? Если у либы дурное апи, а наивные додики им пользуются для "защиты соединений", при том "защита" нифига не защищает - как должен патч выглядеть? Я должен им переписать всю логику шифрования соединения? И на серверах тоже? Эм... вообще-то с этим нынче большие проблемы, ибо SSL гэ, а ничего другого распостраненного в общем то и нет. Internet is broken (c) Schneier. И да, время починить его только наступает. И да, если я не могу дать тебе хорошее решение по вылезанию из ж...ы, это не значит что я не должен констатировать тот факт что ж...а есть.
> практического значения это не имеет.
Ну если ты хочешь летать на самолете, у которого вот-вот развалится фюзеляж - ок, это твое право практиковать такие вещи. Но потом не жалуйся на результат. У меня нет цели спасти твой зад, но будучи достаточно квалифицированным в области я могу попытаться предупредить тебя что на вон том самолете лучше не летать. Дальнейший выбор, разумеется, за тобой.
если всё ещё не дошло: от воплей «а соль лучше» *существующий* софт с OpenSSL не изменится. весь его выкинуть и ждать, пока любители соли сделают свой? не вариант.если опять не дошло: я не сравнивал соль и OpenSSL. я упорно повторяю, что от слова «соль» во рту солёней не станет.
> если всё ещё не дошло: от воплей «а соль лучше» *существующий* софт
> с OpenSSL не изменится.Да, от того факта что я сказал что на самолетах с фюзеляжем выработавшим свой реусрс летать опасно - их фюзеляж не починится, микротрещины не пропадут. И я даже не могу починить его, вкатив пару заплаток. Не тот масштаб. Это чинится путем выпуска нового самолета с новым фюзеляжем.
> весь его выкинуть и ждать, пока любители соли сделают свой? не вариант.
Как минимум, ты не должен уповать что SSL/TLS тебя от чего-то защитит. А, собственно, openssl редко юзают в упомянутом софте для чего либо еще. Ну то-есть иногда кто-то дергает некие алгоритмы оттуда, но основным использованиям является подъем TLS/SSL соединений. За это я и считаю его большим куском фэйка.
> если опять не дошло: я не сравнивал соль и OpenSSL. я упорно
> повторяю, что от слова «соль» во рту солёней не станет.А я еще раз повторяю: даже тот факт что у тебя весь аэродром до отказа забит отлетавшими свое самолетами, безопаснее они не станут и поэтому летать на них - нафиг-нафиг.
>[оверквотинг удален]
> Как минимум, ты не должен уповать что SSL/TLS тебя от чего-то защитит.
> А, собственно, openssl редко юзают в упомянутом софте для чего либо
> еще. Ну то-есть иногда кто-то дергает некие алгоритмы оттуда, но основным
> использованиям является подъем TLS/SSL соединений. За это я и считаю его
> большим куском фэйка.
>> если опять не дошло: я не сравнивал соль и OpenSSL. я упорно
>> повторяю, что от слова «соль» во рту солёней не станет.
> А я еще раз повторяю: даже тот факт что у тебя весь
> аэродром до отказа забит отлетавшими свое самолетами, безопаснее они не станут
> и поэтому летать на них - нафиг-нафиг.Откажись от: уютненькой мордокниги/фконтактика, связи - в т.ч мобильной - там вообще защиты нет, от банковских карт ну и заодно от банков вообще. Храни бабло в трехлитровых. Можешь сразу к Лыковым в тайгу податься. Угу?
Напомнить, сколько ДЕСЯТИЛЕТИЙ заняло повсеместное обHHPSивание?
> Откажись от: уютненькой мордокниги/фконтактика,Сложно. Ведь я ими и не начинал пользоваться. Поэтому отказаться от них будет проблематично, это да. Ведь я и не собираюсь даже и начинать ими пользоваться, если что.
> связи - в т.ч мобильной - там вообще защиты нет,
Я достаточно хорошо в курсе этого факта. В отличие от пальцатого ламерья я как-то раз подрасперся почитать документы с etsi.org, а также осознать какие вообще протоколы и уровни оных есть в природе, как и где идут данные, etc. Хотите меня этому поучить? Ну попробуйте.
> от банковских карт ну и заодно от банков вообще.
Я умею пользоваться ими так что все это мне не вредит. Ну вот например я могу быть Mr. Cardholder-ом, с картой Visa Virtual. Вполне достаточно чтобы сделать платеж. Карта - понятие растяжимое.
> Храни бабло в трехлитровых. Можешь сразу к Лыковым в тайгу податься.
Я без вас разберусь в чем мне бабло хранить. А с банками уже был прецедент в 1998 году, когда банк отказался выдать деньги. Ну а там курс доллара - ёк и настал дефолт. В трехлитровой было бы намного менее печально, это да.
> Напомнить, сколько ДЕСЯТИЛЕТИЙ заняло повсеместное обHHPSивание?Что таое HHPS? HTTPS напечатанный с ошибкой? А смысл в оном? Декоративное секурити - хуже чем никакого, ибо создает ложное чувство защищенности и усыпляет бдительность.
Это "декоративное" секурити защищает в 99% случаев. От теоретического знания общего плана взлома, до его практической реализации очень далеко. Пароли словарным перебором ломают куда чаще. А абсолютной защиты вообще в принципе не существует. Так что с учетом цены https очень даже хорошая защита.
> Это "декоративное" секурити защищает в 99% случаев.Это декоративное секурити "защищает" лишь до тех пор, пока никто не озадачивается проведением атаки :). С таким же успехом, фанерный щит "защищает от пуль". При условии что пули в вашу сторону не летят. Сложность в том, что такая "защита" придает уверенности там где это напрасно и чревато.
> до его практической реализации очень далеко.
Так проблема с SSL/TLS в том, что на них можно вполне практично проводить атаки от которых оно по идее должно было защищать. Комодохакер - он не теоретический, он на практике обеспечил пиндец одного из CA. IDSки хакающие трафф с целю анализа - тоже вполне практическая штука. А уж если кто не проверяет что за сертификат подсунули (как большинство программ, отличных от браузера, например) - тут вообще атаку может сделать шкoльник Вася из пятой квартиры, просто впихав прозрачный прокчи и выписав себе сертификат. Раз уж его никак не проверяют.
> Пароли словарным перебором ломают куда чаще.
Весьма зависит от ситуации, знаете ли. Если затребовать сложность пароля "не менее чем", а сам пароль хранится в виде хеша какой-нибудь memory-hard функции типа scrypt, catena и прочих - вот это совсем не факт. Юзера не напряжет секунду подождать при логине. А вот скорость подбора пароля "1 пароль в секунду" атакующим совсем не понравится, имхо.
> что с учетом цены https очень даже хорошая защита.
Фанерный щит - хорошая защита от пуль, с учетом цены. При условии что пули в вашу сторону не летят.
Танковая броня не защищает от прямого попадания ядерного заряда. Ох печалька, уж лучше совсем голышом ходить, чем прикрываться "декаративной" защитой танка.
> Танковая броня не защищает от прямого попадания ядерного заряда.В данном случае броня является фанерной. И не защищает даже от пистолетной пули. Кстати, хороший танк рассчитывают на работу в условиях близких ядерных взрывов, если что.
>> Танковая броня не защищает от прямого попадания ядерного заряда.
> В данном случае броня является фанерной. И не защищает даже от пистолетной
> пули. Кстати, хороший танк рассчитывают на работу в условиях близких ядерных
> взрывов, если что.От пистолетной пули не защищает? Тебе дать дамп SSL траффика, а ты его расшифруешь, скажем, за неделю? Или ты только лужи газифицировать можешь?
Когда в твоём любимом nalc найдут не меньшей эпичности баг, что будешь делать? Или к тому времени уже будешь сидеть на очередном велосипеде, в котором дыр - как вшей у бомжа, но никто их не ищет, потому что нужны они кому-то, как те же вши?
> А потом вот так через несколько годиков окажется что генератор случайных чисел у интела не совсем случайный, и чего?"A deterministic random-bit generator is seeded by the output from the conditioner, providing cryptographically secure random numbers to applications requesting them via the RdRand instruction"
Уже.
>:-)
openssh тоже в группе риска?
Конечно) Смотрите вывод команды и всё будет понятно:ssh -version
http://security.stackexchange.com/questions/3424/how-is-open...
Ага. Рестартнуть придется.
> openssh тоже в группе риска?Нет. openssh использует openssl, но не tls с heartbeat. Так что, sshd не затронут.
> Для проверки серверных систем на предмет наличия уязвимости подготовлен специальный online-сервис.Что-то на этом сервисе все чеки проходят как ОК в отличие от http://filippo.io/Heartbleed/
> http://filippo.io/Heartbleed/Эм... особо предприимчивые господа уже коллекционируют пароли и ключи на своих онлайн ресурсах? Малацца, правильно, хомяк сам же и укажет свой сервак, меньше затрат ресурсов на скан интернета :)
Эксплойт то где? А то развели шум из-за ничего )) Где гарантия что в этих 64 килобайтах будет вдруг ключ и пароль?
> Эксплойт то где? А то развели шум из-за ничего )) Где гарантия
> что в этих 64 килобайтах будет вдруг ключ и пароль?А вы оставьте здесь адреса своих серверов... :)
> А вы оставьте здесь адреса своих серверов... :)Да, вон там как раз пара сервисов уже. Для проверки, так сказать, сколько ключей и паролей удастся извлечь.
> Где гарантия что в этих 64 килобайтах будет вдруг ключ и пароль?ничё себе чувак губу раскатал, гарантии ему нужны. Хочешь гарантию - покупай микроволновку
Ещё увидел в рекомендациях заново по-возможности сгенерировать сертификаты.
> Ещё увидел в рекомендациях заново по-возможности сгенерировать сертификаты.Логично. Потому что если у тебя тихой сапой уперли пароли и ключи - однажды на сервер может кто-то неожиданно припереться...
А что случится после того как злоумышленник вытянет из сервера закрытый ключ?
> А что случится после того как злоумышленник вытянет из сервера закрытый ключ?А вот тогда и увидишь, как сервак плавно-нах становится не твоим.
это было бы круто, но я этого не увижу поскольку оргмеры рулят, потому и спрашиваю
$ ssh -V
OpenSSH_5.5p1 Debian-6+squeeze4, OpenSSL 0.9.8o 01 Jun 2010Цифродрочepы - цифродpoчат! :-P
> Цифродрочepы - цифродpoчат! :-PТы айпишник сказать забыл, чтобы мы могли посмотреть сколько ключей и паролей удастся утянуть.
> Ты айпишник сказать забыл, чтобы мы могли посмотреть сколько ключей и паролей
> удастся утянуть."Тебя посодют, а ты не воруй".
> "Тебя посодют, а ты не воруй".Чего-то не похоже на айпишник.
> Ты айпишник сказать забыл, чтобы мы могли посмотреть сколько ключей и паролей
> удастся утянуть.Придётся подсказать специалисту, который внимательно прочитал CVE -- 127.14.98.241. Да, md5sum правильного ответа при вводных из #60 -- cfcd208495d565ef66e7dff9f98764da.
> 127.14.98.241.Надеетесь что все вокруг глупые и не умеют считать битовые маски? :)
>> 127.14.98.241
> Надеетесь что всеОтнюдь. :)
В nginx под centos используется статическая линковка с openssl.
Брали из репозитария nginx.org
Ой не верю что программист этого дела типа случайно забыл там проверку поставить...
Гонорарчик :)
Ну или угрозы. :)
Вообще-то из FreeBSD только 10.0+ уязвимо..root@as2:~ # uname -r
9.2-RELEASE-p3
root@as2:~ # openssl version
OpenSSL 0.9.8y 5 Feb 2013
https://github.com/openssl/openssl/commit/4817504d069b4c5082...
https://www.youtube.com/watch?v=3jQoAYRKqhg
http://phk.freebsd.dk/_downloads/FOSDEM_2014.pdf
http://video.fosdem.org/2014/
если я правильно понял, этот баг будет проявляться только через ssl-соединения, созданные штатными средствами openssl.
если так, то openssh не подвержен уязвимости, openvpn поверх udp - тоже
Вот что происходит, когда для разработки криптографических библиотек используется С вместо безопасного языка программирования вроде rust.
Он ведь тоже на си
> Вот что происходит, когда для разработки криптографических библиотек используется С
> вместо безопасного языка программирования вроде rust.Боюсь, SSL/TLS на чем не реализуй, а получишь не секурити а буй.
> Боюсь, SSL/TLS на чем не реализуй, а получишь не секурити а буй.Кстати, GnuTLS как нельзя лучше подходит под это определение.
> Кстати, GnuTLS как нельзя лучше подходит под это определение.Ты не напишешь ничего безопасного ни на каком ЯП. Ни с какой библиотекой. Потому что ламер и просто глупый субъект, не понимающий как работают компьютеры. Выращивай рассаду, может хоть там лажать не будешь.
> Выращивай рассаду, может хоть там лажать не будешь.Ты рискнешь что-нибудь съесть с той грядки??? Смело!
> безопасного языка программирования вроде rust.А безопасный ЯП типа rust с его garbage collector и прочим вообще позволит сказочно продолбаться в криптографии, утратив возможность сколь-нибудь предсказуео чистить память с важными данными вовремя. Но об этом скрипткидизы от мозиллы подумают чуть попозже, когда продолбаются.
> с его garbage collectorRust использует линейные типы с отслеживанием скопа вместо сборки мусора.
Погуглил бы сначала, перед тем, как отвечать: http://pcwalton.github.io/blog/2013/03/18/an-overview-of-mem.../
> Rust использует линейные типы с отслеживанием скопа вместо сборки мусора.А один хрен. Автоматика в таких вещах только мешается и гробит предсказуемость. Ключ должен быть изничтожен ровно в тот момент когда он перестал быть нужен. Всякие умничания суперумных аллокаторов и прочей байды будут только мешать и почем зря создадут уйму неочевидных проблем. Которые, однако, постепенно будут обнаружены исследователями и все испортят.
> Ключ должен быть изничтожен ровно в тот момент когда он перестал
> быть нужен.у тебя руки отпали, ты надеешься на языковую магию? ок, возьми D, сделай scoped struct с деструктором, по выходу из scope деструктор всё почистит. предсказуемей некуда, и при этом сборка мусора никуда не девалась.
> Ключ должен быть изничтожен ровно в тот момент когда он перестал быть нужен.Ну так в чём проблема? По выходу из скопа, данные, если уникальный указатель не передан за скоп, автоматически уничтожаются деструктором. Причём всё это дело разрешается ещё на этапе компиляции, без всяких жирных рантаимов.
Контролируемо, но в то же время без возможности выстрелить себе в ногу за пределами unsafe.
ухнифигасебе !! щас еще тестят StrongSWAN и либресван, есть шансы что там - тоже воспроизводимо :(
Во FreeBSD закрыли этот ваш баг в SSL:
http://www.freebsd.org/security/advisories/FreeBSD-SA-14:06....
Расстраиваться не стоит.
> Расстраиваться не стоит.Вот только стоит помнить что клиент мог получить кусок памяти сервера, а сервер - кусок памяти клиента. Так что ключи и пароли надо менять... Ять-ять-ять - привычно откликнулось эхо.
> Так что ключи и пароли надо менять.Так это стандартная процедура, выполняемая часто и регулярно. Залог безопасности от случайной утечки. Или у вас пароли и ключи сгенерированы "на века" и менять их может только суперадмин-архитектор, когда его хорошенько попросят об этом? :)
ну да, у бсдоидов смена ключей — процедура чуть ли не ежедневная. а то они в своей основной системе от m$ троянов нахватаются — и прощайте, ключики.
Вброшу-ка сюда пару ссылок:
Theo de Raadt: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable" (http://article.gmane.org/gmane.os.openbsd.misc/211963)
И http://mirror.as35701.net/video.fosdem.org//2014/Janson/Sund... — о безопасности ПО, FOSS и OpenSSL в частности.
Отлично, эти умники перехватили malloc() но сделать его в виде как ожидается от криптографической либы и не почесались. Я таки был прав в моем мнении про openssl.
Если я правильно понял, то почесались. Но потом за-ifdef-или защиту и забыли про это.
Странное дело - сервис проверки (соединения на его уязвимость) указанный в статье (http://filippo.io/Heartbleed)
очевидно не справляется с проверкой некоторых программных продуктов - проверил
свой сервер с апачем - выдаёт, что всё окей (ну да он ещё на squeezе стоит).
А пытаюсь ему подсунуть порт 443 от pound, что стоит у одной из пачки серверов
как loadbalancer - говорит "heartbleed: timeout".У кого-нибудь есть похожие симптомы || опыт?
Спасибо новости, и генту-майнтейнерам, уже запилили ебилд.
Following up on the CVE-2014-0160 vulnerability, heartbleed. We've created some iptables rules to block all heartbeat queries using the very powerful u32 module.The rules allow you to mitigate systems that can't yet be patched by blocking ALL the heartbeat handshakes. We also like the capability to log external scanners :)
The rules have been specifically created for HTTPS traffic and may be adapted for other protocols; SMTPS/IMAPS/...
# Log rules
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ "52=0x18030000:0x1803FFFF" -j LOG --log-prefix "BLOCKED: HEARTBEAT"# Block rules
iptables -t filter -A INPUT -p tcp --dport 443 -m u32 --u32 \ "52=0x18030000:0x1803FFFF" -j DROP# Wireshark rules
$ tshark -i interface port 443 -R 'frame[68:1] == 18'
$ tshark -i interface port 443 -R 'ssl.record.content_type == 24'
We believe that this should only be used as a temporary fix to decrease the exposure window. The log rule should allow you to test the firewall rules before being used in production. It goes without saying that if you have any suggested improvements to these rules we would be grateful if you could share them with the security community.Clearly, use of these rules is at your own risk ;)
ECSC SOC Team Researchers:
Adam Shore
Alex Innes
Fabien Bourdaire
Я правильно понимаю, что если на моем сервере openssl 0.9.8e-27.el5_10.1, то данная уязвимость не могла затронуть меня?
тебя -- точно нет ))
> тебя -- точно нет ))Ну и ладушки. Centos 5 рулит. А ведь совсем недавно обновлялся.