URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID3
Нить номер: 103574
[ Назад ]

Исходное сообщение
"Критическая уязвимость в OpenSSL"

Отправлено opennews , 09-Июл-15 19:38 
Доступны корректирующие релизы OpenSSL 1.0.2d (http://marc.info/?l=openssl-announce&m=143644788123757&w=2) и 1.0.1p (http://marc.info/?l=openssl-announce&m=143644724423541&w=2), в которых устранена критическая уязвимость (http://openssl.org/news/secadv_20150709.txt) (CVE-2015-1793), позволяющая обойти процедуру проверки сертификата и организовать подтверждённое соединение с использованием подставного сертификата.


Причиной уязвимости являются внесённые в выпусках  1.0.1n и
1.0.2b изменения, в результате которых OpenSSL пытается  найти альтернативную цепочку верификации сертификата, если первая попытка построения цепочки подтверждения доверия не увенчалась успехом. Из-за ошибки в реализации данной особенности, атакующий получил возможность пройти некоторые проверки указав не заслуживающий доверия сертификат. В частности, можно пройти проверку на флаг принадлежности удостоверяющему центру, что даёт атакующему возможность задействовать второстепенный заверенный сертификат в качестве сертификата удостоверяющего центра и "выписать" при его помощи подставной сертификат, проходящий проверку в OpenSSL.


Проблема затрагивает любые приложения, инициирующие проверку сертификата, в том числе клиенты SSL/TLS/DTLS и серверы SSL/TLS/DTLS, использующие клиентскую аутентификацию. Опасность уязвимости частично смягчает то, что она  проявляется только версиях  OpenSSL 1.0.2c, 1.0.2b, 1.0.1n и 1.0.1o, выпущенных в июне. Более ранние выпуски, а также ветки 1.0.0 и 0.9.8 уязвимость не затрагивает.
Проблема выявлена Адамом Лэнгли (Adam Langley) из Google  и Дэйвидом Бенджамином (David Benjamin) из проекта BoringSSL (http://www.opennet.me/opennews/art.shtml?num=40049).


URL: http://marc.info/?l=openssl-announce&m=143644868424087&w=2
Новость: http://www.opennet.me/opennews/art.shtml?num=42590


Содержание

Сообщения в этом обсуждении
"Критическая уязвимость в OpenSSL"
Отправлено asavah , 09-Июл-15 19:38 
Шо опять? (c)

"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 10-Июл-15 01:04 
Ну, не совсем. На этот раз новость нужно читать не "В OpenSSL нашли очередную багу", а "OpenSSL теперь настолько активно проверяют серьезные конторы, что багу нашли сразу, как она появилась".

"Критическая уязвимость в OpenSSL"
Отправлено Анончег , 10-Июл-15 02:16 
И не спрашивай даже!

Зато смотри какую полезную фичу ребята заимплементировали в недра этого... даже не знаю как это поточнее обозначить:

"Т.е. атакующий получает возможность выступить в качестве удостоверяющего центра, генерирующего сертификаты для любых доменов."


"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 09-Июл-15 19:43 
Интресно, чего редхет понабекпортил в 0.9.8, что она обновляется, хотя в тексте новости написано, что не должна.

"Критическая уязвимость в OpenSSL"
Отправлено Я , 09-Июл-15 20:05 
Тут два вопроса, шо опять и второй, а вдруг АНБ внедрила новый шел и под предлогом уязвимости хочет что бы все обновились )))

"Критическая уязвимость в OpenSSL"
Отправлено robux , 09-Июл-15 21:08 
Дак не "вдруг", а точно - под видом устранения одной уязвимости, вставляют новые.

"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 10-Июл-15 12:24 
> Дак не "вдруг", а точно - под видом устранения одной уязвимости, вставляют новые.

Да там даже вставлять ничего не надо. При таком объеме кода там уязвимостей хватит лет на 20 вперед.


"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 09-Июл-15 20:57 
Это, конечно, боян, но я все-таки был прав насчет OpenSSL. И наверняка это не последняя уязвимость, и не только в этой библиотеке.

Потому что такой шмат кода и такие протокольные навороты просто не могут быть реализованы без багов.


"Критическая уязвимость в OpenSSL"
Отправлено robux , 09-Июл-15 21:10 
> Потому что такой шмат кода и такие протокольные навороты просто не могут
> быть реализованы без багов.

Всё верно, рыбка ловится в мутной воде:
чем больше кода, и чем он замороченней, тем легче спрятать бэкдоры.

К примеру, законодательство тоже специально усложнено (и каждый день усложняется), переполняется всякими законами, актами и постановлениями, чтобы при необходимости любое дело можно было повернуть в нужную корпорастам сторону.


"Критическая уязвимость в OpenSSL"
Отправлено Crazy Alex , 10-Июл-15 00:50 
В "специально" верят только те, кто не пытался долго поддерживать любую сложную систему - будь то софтина, организация или собственная квартира. Всё имеет привычку обрастать какими-то непредвиденными функциями, незаметными взаимосвязями и особыми случаями. наоборот, приходится прилагать усилия, чтобы этого не происходило.

"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 10-Июл-15 12:21 
> В "специально" верят только те, кто не пытался долго поддерживать любую сложную систему

Ты не понял, чувак. Специально оно именно сложное. А когда хотят сделать криптографию простой и, главное, аудитируемой - делают как DJB. Когда вся либа умещается в 1 файлик который на твиттер можно накромсать. Вот там сюрпризов и факапов будет минимум.

А тут под эгидой решения всех вселенских проблем наворотили черти-что. С кучей опций, кучей легаси, кучей бестолковостей и прочая. "И вам потребуется пара толковых ребят, чтобы во всех этих опциях разобраться". Бонусом в openssl дурные умолчания и дурное апи. В результате секурно пользоваться всем этим не умеет чуть менее чем никто.

Ну то-есть есть полторы программы на всю планету где это кой-как работает, и то - вот такие плюхи постоянно лезут. А все остальные просто без шансов еще на старте. Кто экспортные алгоритмы не запретил, кто SSLv3. А MITM-ам только того и надо :)


"Критическая уязвимость в OpenSSL"
Отправлено vi , 10-Июл-15 14:59 
>[оверквотинг удален]
> там сюрпризов и факапов будет минимум.
> А тут под эгидой решения всех вселенских проблем наворотили черти-что. С кучей
> опций, кучей легаси, кучей бестолковостей и прочая. "И вам потребуется пара
> толковых ребят, чтобы во всех этих опциях разобраться". Бонусом в openssl
> дурные умолчания и дурное апи. В результате секурно пользоваться всем этим
> не умеет чуть менее чем никто.
> Ну то-есть есть полторы программы на всю планету где это кой-как работает,
> и то - вот такие плюхи постоянно лезут. А все остальные
> просто без шансов еще на старте. Кто экспортные алгоритмы не запретил,
> кто SSLv3. А MITM-ам только того и надо :)

Вы оба правы! (Даже без ИМХО ;)
Но иногда сложновато бывает отказаться от своего любимого старенького велосипеда (и вынести старый хлам из дому ;)


"Критическая уязвимость в OpenSSL"
Отправлено Crazy Alex , 10-Июл-15 22:09 
Понимаешь, эта сложность нужна для решения реальных сложных задач. Дурные умолчания и дурное апи - разговор другой, конечно. Но вот сама сложность SSL/TLS - она не с пустого места родилась. И не будет там никогда файлика для твиттера. Потому что нужны цепочки, нужны отзывы, нужен менеджмент сертификатов, нужны компромиссы затрат ресурсов/безрасность, нужна совместимость с уже существующими реализациями, в том числе - торчащими в каком-нибудь легаси софте или, паче, железе... и ещё 100500 вещей, о которых я не вспомнил или вообще не знаю. Другое дело, что, возможно, для каких-то ситуаций нужен параллельный ДРУГОЙ протокол с другим набором фич.

"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 15-Июл-15 13:26 
> Понимаешь, эта сложность нужна для решения реальных сложных задач.

Какие реальные задачи решает доисторический SSLv3? Доступ левых MITMов в чужие данные? :) А может быть, ты придумаешь юзкейс для heartbeat с заказом произвольного объема данных? А то я так смотрю, его отпилили - никто и не заметил.

> Дурные умолчания и дурное апи - разговор другой, конечно.

Это всего лишь логичное дополнение к общей картине. Х-во сделанному протоколу с кучей дряни - и апи под стать! И дефолты. Такой протокол невозможно проаудитить на предмет возможных вариантов развития событий во всех комбо с разумными затратами сил. Это обрекает реализаторов на туеву хучу багов, если они попробуют реализовать всю эту туеву хучу фич. Получаются вот такие плюхи и прочие heartbleed. Которых быть вообще не должно. Потому как нефиг уметь слать произвольный объем данных по запросу ремоты. И нефиг уметь шифровать по DES с ключом 40 битов - это имитация бурной деятельности, а не защита: его кто угодно вскроет за обозримое время.

> Но вот сама сложность SSL/TLS - она не с пустого места родилась.

Ну конечно, судя по Сноудэну - NSA очень старались, чтобы вышло именно так. Впарив максимально дурные решения как стандарты. Где 25519 например? Быстрый как ракета и с стойкостью уровня 2048 битного RSA, только быстрее в 100500 раз на всех операциях? Ах, нету? Зато есть NISTовские кривые. Тормознее в разы и, возможно, с бэкдорами. Великолепно, гули. Хорошее дополнение к DualEC DRBG от NIST. Кто хочет быть попаданцем - идет и пользуется стандартизированным!!!111 DualEC и нистовскими кривыми. Как раз NSA будет удобно. Зато стандарт!!!1111

> И не будет там никогда файлика для твиттера.

Ну так махровая энтерпрайзятина обречена быть гомнософтом с кучей багов, а в крипто любая аномалия оказывается достаточно фатальна. Крипто не бывает второй свежести.

> Потому что нужны цепочки, нужны отзывы, нужен менеджмент сертификатов,

Ну вот и получите тогда Comodohacker'а, который выписал себе сертификаты на все и вся. Он уже показал как надо менежмент сертификатов делать, сломав дигинотара в хлам. А заодно и их активную директорию (ибо большому кораблю - БОЛЬШАЯ торпеда). Ты хотел энтерпрайзятины - ну на, получай!

Ну а openssl по дефолту доверяет туевой хуче CA. Вот так и получается что NSA или какой comodohacker может их немного ломануть/надавить. И все твои цепочки быстренько трансформируются в большой факап, когда какие-то левые хрены могут мимикрировать под твой сервер с полоборота. И заметить отличия может.. нууууууу... я видел целый пиджин, который парился о том что сертификат изменился. Сцуко единственная программа на планете из всех которые я видел. А остальные втихушку поумничают, скушав вражеский сертификат. Круто, правда? :)

> нужны компромиссы затрат ресурсов/безрасность,

Не заметно. Если бы это было правдой, за 25519 зубами бы цеплялись, как за очень удачную вариацию на эту тему: скорость ракеты и безопасность RSA-2048. При скорости на несколько порядков (!!!) выше.

> нужна совместимость с уже существующими реализациями,

Спасибо, но совместимость с DES и прочими RC2 с ключом 40 битов - означает что атакующий в два счета устроит активную атаку, задаунгрейдив конекцию до этого варианта. Потому как активны атакующий может, внезапно, менять все поля протокола по своему усмотрению. И протокол или делается так, что с этого ничего поиметь нельзя, или возникают факапы как в SSL.

> легаси софте или, паче, железе...

Криптография бывает только первой свежести. Вторая - это уже тухлятина. Ну ты в своем праве ходить телнетом на вон ту железку, через открытый вайфай. Но если тебе разнесут в результате энтерпрайз в жанре комодохакеры - ну ты сам в этом виноват, потому что думать надо было головой, а не другими частями тела. Атакующие не собираются слушать все это энтрпрайзное блеяние. Они просто приходят и ломают, если это технически возможно сломать. Им пофиг на твои блеяния про компромиссы и совместимость.

> я не вспомнил или вообще не знаю.

...и которые не забудут #$%нуть тебе по лбу ручкой грабель при удобном случае, подыграв MITM-у на проводе, а вовсе не.

> Другое дело, что, возможно, для каких-то ситуаций нужен параллельный ДРУГОЙ
> протокол с другим набором фич.

Для начала нехило бы перестать считать SSL/TLS защитой от чего либо. Оно втирание очков нежели защита, для начала.


"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 17-Июл-15 13:10 
> делают как DJB

Т.е. NaCl?
Кстати, как насчет использования Sodium-a?


"Критическая уязвимость в OpenSSL"
Отправлено Andrey Mitrofanov , 22-Июл-15 18:50 
>> В "специально" верят только те, кто не пытался долго поддерживать любую сложную систему
> Ты не понял, чувак. Специально оно именно сложное. А когда хотят сделать
> криптографию простой и, главное, аудитируемой - делают как DJB. Когда вся
> либа умещается в 1 файлик который на твиттер можно накромсать. Вот
> там сюрпризов и факапов будет минимум.

Сю-урпри-из! Все делаем, как DJB! Вдоль.

http://oldmann.livejournal.com/275306.html
https://datatracker.ietf.org/meeting/93/agenda/cfrg/

CFRG - Crypto Forum Research Group
  ECC Signatures (presentations and discussions)
    13:45 - 15:15 (90 mins)
      3) Dan Bernstein/Simon Josefsson/Tanja Lange/Peter Schwabe/Bo-Yin Yang


> кто SSLv3. А MITM-ам только того и надо :)


"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 11-Июл-15 09:49 
Не согласен!

Склонен считать что специально...

Девиз Юникс 70-тых годов прошлого века - "Простота и совершенство!".
Где он сегодня? Кто ему следует?


"Критическая уязвимость в OpenSSL"
Отправлено Andrey Mitrofanov , 09-Июл-15 23:17 
> это не последняя

http://dayswithoutansslexploit.com/ в новость наверху ещё не добавляют сразу?


"Критическая уязвимость в OpenSSL"
Отправлено bav , 09-Июл-15 22:38 
> пытается найти альтернативную цепочку верификации сертификата, если первая попытка построения цепочки подтверждения доверия не увенчалась успехом.

Зачем? Зачем они это делают? Зачем этот протокол такой сложный? Мы обречены!


"Критическая уязвимость в OpenSSL"
Отправлено Crazy Alex , 10-Июл-15 00:57 
А реальные случаи вообще часто оказываются сложнее, чем думали. И альтернатива - либо говорить "идите на фиг, нам простота, надёжность и безопасность важнее" либо делать костыли. Как ни странно, второй путь часто правильнее, если понимаешь, что костыли таки есть и что они могут рухнуть. Вот с SSL проблема как раз в том, что обычно забывают, что это адский комбайн, непригодный для случаев, когда нужна серьёзная надёжность. А для интернет-магазина или даже интернет-банкинга (с 2FA, например) он отлично годится, даже со всеми дырами.

"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 10-Июл-15 12:49 
> понимаешь, что костыли таки есть и что они могут рухнуть. Вот
> с SSL проблема как раз в том, что обычно забывают,

Проблема в том что сделали overengineered нечто, с кучей легаси, хлама и опций позволяющих прострелить себе пятку, типа всяких heartbeat зачем-то позволяющих заказывать объем ответа (нафига бы), даунгрейдиться до SSLv3 с кучей проблем, а то и просто экспортной криптографии, с ключами чуть ли не 40 битов, которые даже на CPU за полдня вынесут, а на GPU и за полчаса. Ну или вот сабж.

А чтобы все это секурно использовать - надо быть настоящим криптографом. Уровня Брюса Шнайера. Ну может самую капельку поменьше. Вот ты, разбуженный среди ночи - скажешь мне чем ECB от CBC отличается, о великий гуру? И, главное - ты знаешь как тебе предпочтительнее вот в этой задаче? А какое шифрование либа у тебя использует по дефолту? А что ремотный сервер (читай MITM) может тебе всучить? И какой процент кодерасов типа тебя вообще в курсе всего этого? А без знания всего этого пользоваться openssl - форменный выстрел себе в пятку, т.к. абы какие дефолты да еще ремота может влиять.

Не говоря о том что там 100% факап с публичной криптографией. RSA тормозливый что пиндец и с длинными ключами его использовать - сущее мучение. 4096-битные ключи используют только самые отчаянные. Да и 2048 многих напрягает. А меньше, извините, не безопасно уже считается. И вот "благодетели" из DNSSCE вкручивают 1024 битный RSA. Хилый, но "иначе все сколлапсирует по производитльности". Ну да, а кому не нравится может использовать эллиптические кривые. Они быстрее при одинаковой надежности. Вот только в openssl и стандарте - почему-то только NIST'овская эллиптика, в которой подозревается бэкдор. А какая-нибудь кривая 25519, которую ковыряла куча независимых криптографов - "совершенно случайно" оставлена за бортом. Ну еще бы, АНБ будет икаться, если быстрая публичная криптография уровня RSA-2048 станет стандартом.

> для интернет-магазина или даже интернет-банкинга (с 2FA, например) он отлично годится,
> даже со всеми дырами.

Угу, только потом ComodoHacker-ы выносят не то что банк или магазин, а целый УЦ. Выписав себе сертификаты на ВСЕ. И на банкинг, и на магазин, и на скайп, и на микрософтапдейт, и на мозиллу. Безопасность перла из всех щелей. Не, чувак, извини. Безопасность бывает двух уровней - "high" и "нехай".


"Критическая уязвимость в OpenSSL"
Отправлено Crazy Alex , 10-Июл-15 22:23 
Ты тут всё в кучу смешал. Давай всё же делить:
- кривые дефолты OpenSSL;
- то, что кримтографию кто-то с перепою считает простой и лезет, не читая матчасти. Для простых случаев оно, кстати, некритично, а для серьёзных - нужны компетентные специалисты, как и везде;
- DNSSEC - он здесь совсем с краю. И я даже не уверен, что вообще ключи в DNS - хорошая альтернатива УЦ. Хотя бы потому, что выбора, кому доверяешь, нет.
- то, что в SSL не стали добавлять ещё пачку алгоритмов (и усложнять ещё больше).

А что до комодохакера... Ну и что? Выяснили, выкинули CA и успокоились. Где серьёзные защиты нужны, вроде банкинга - никто на чистый SSL в жизни не полагался. Магазины - ну сделают магазины рефанд, страховка это дело покроет, все успокоятся. Скайпы никого не волнуют и не волновали в жизни. Микрософтапдейт - так там своя система подписей всю жизнь была.

И нет, безопасность бывает разной. От машины, отключённой от интернета за тремя постами охраны до смартфона, валяющегося на столе и прикрытого "паттерном" от случайного бродяги по офису. Потому что первый случай, как ты понимаешь, несколько более затратен и несколько менее удобен.


"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 15-Июл-15 13:50 
> Ты тут всё в кучу смешал. Давай всё же делить:

А смысл? Это клубок проблем, где одно следует из другого. Стройное апи к мегапротоколу с кучей опций и легаси сделать не получится по чисто техническим причинам. И в дефолтах продолбаться - как нефиг делать. Особенно, если всем этим по донкихотски займутся левые хрены "мы не криптографы" (но за каким-то лядом полезли писать криптолибу).

> не уверен, что вообще ключи в DNS - хорошая альтернатива УЦ.

Тут проблема в том что когда ты спрашиваешь у DNS "а кто такой example.com?" - вернуться в ответ может все что угодно. Активному атакующему не проблема впихнуть в DNS-ответ что example.com -> 1.2.3.4, который сервак атакующего. Под его полным контролем. Далее тебе никакой SSL не поможет. Его может там не быть совсем. Или там может быть чужой серт. Сколько софта и юзерей заметит подвох со сменой серта? Ну ты понял!

> Хотя бы потому, что выбора, кому доверяешь, нет.

А в TLS/SSL ты по дефолту "типа, доверяешь" вон той куче хренов. И они все (включая NSA и прочих Comodohacker-ов) могут выписать серт от чьего-то лица что "мамой клянус, я сервер Crazy Alex-а!". И какой либо подвох заметят только очень некоторые программы в очень некоторых обстоятельствах и - не по дефолту.

> А что до комодохакера... Ну и что? Выяснили, выкинули CA и успокоились.

...а комодохацкер в ответ пробурчал "но у меня есть сертификаты другого УЦ на много чего, включая виндусапдейт". А хрен бы его знает кого еще он там подломил. Его ник - в честь слома Comodo, как я понимаю. Но те как-то отвилялись ж...й. А комод в своих пасквилях с хвастовством утверждал что у него есть доступ в еще несколько CA и что он много чего еще подписывать могет :)

Не говоря уж про NSA которое может поднажать на то или иное CA. Называя вещи своими именами, доверие по дефолту 100500 мутных комерсов - уже подстава.

> Где серьёзные защиты нужны, вроде банкинга - никто на чистый SSL в жизни не полагался.

Оно и видно. Как раз половина онлайн банкинга на нем работает.

> Магазины - ну сделают магазины рефанд, страховка это дело покроет, все успокоятся.

Ну да, по тем же причинам живут карты с магнитной полосой, защита которых равна нулю (любой желающий может снять все данные нехитрым оборудованием, получив точную копию карты, а потом платить оной вместо владельца). В результате кардинг - просто рядовое явление. Зато если ты поехал за границу - банк в два счета оставит тебя без твоих же денег, посчитав это "подозрительными транзакциями". Сразу видно что и как банки по факту клали на секурити :). "Страховка покроет" - вот и вся их секурность :)

> Скайпы никого не волнуют и не волновали в жизни.

Оно и видно - микрософт аж суперноды из юзерей заменил на свои, чтобы с них данные лопатой грести можно было.

> Микрософтапдейт - так там своя система подписей всю жизнь была.

ЧСХ, основанная более-менее на том же механизме сертификатов, IIRC.

> И нет, безопасность бывает разной.

Как кто-то из безопасников сказал, безопасность бывает двух уровней - "high" и "нехай". Величина бинарная: оно или ломается за обозримое время с обозримыми усилиями, или нет. И чем больше наворочено в протоколе и прочая - тем вероятнее что таки ломаемо.

> несколько более затратен и несколько менее удобен.

А парни из Equation Group показали что неудобства и затраты - понятие растяжимое. Лихо распетрушивая такое "заранее подготовленными флешками и сидюками". Впрочем, даже местный DiHalt устроил эпичный промышленный шпионаж, поклав на посты охраны и меры безопасности, задействовав немного подготовленную мышь. При том что DiHalt - не хакер и не шпион вообще, так, просто сообразительный типок, который за мыслью в карман не лезет.


"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 09-Июл-15 22:54 
> OpenSSL пытается найти альтернативную цепочку верификации сертификата

нахрена? какой долбодятел это придумал? не доходит цепочка до нужного ЦА - всё, пнх, без разговоров.


"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 09-Июл-15 23:33 
Так весь TLS вообще и OpenSSL в частности - большие мегакомбайны на все случаи жизни. Ну вто они и умничают когда их не просили. А в криптографии это может быть достаточно фатально.

"Критическая уязвимость в OpenSSL"
Отправлено robux , 10-Июл-15 09:23 
За весь OpenSSL не говори - низкоуровневая (базовая) криптография там хорошо реализована (про бэкдоры не слышал).

А вот высокоуровневые вещи, типа ущербного TLS/SSL/HTTPS - естественно, замороченные и дырявые. Это не вина OpenSSL, а вина составителей спецификаций этих дебильных протоколов. Нельзя пересказать Новый Завет в 3х словах, даже если ты гениальный поэт. Всё равно наплетёшь охинеи, чтобы передать все сюжеты. Вот и с дурацкими протоколами так.


"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 10-Июл-15 13:02 
> За весь OpenSSL не говори - низкоуровневая (базовая) криптография там хорошо реализована

Лучше не бывает. Например, если попросить либу использовать аппаратное ускорение - эти укypки напрямую выведут тебе в апликуху вывод аппаратного RNG, без каких либо изменений. Кексы из Tor долго фигели с такой реализации криптографии и со своей стороны конечно вбили костыли, куда они денутся с подводной лодки. Ну а о том что энтропию аппаратного RNG можно подмешивать к остальной - упыри из openssl походу вообще не слышали. КрЮтая базовая криптография, нечего сказать. Только почему-то даже линуксный Теодор Тсо, который как таковой даже и не криптограф - и тот догадывается, что такое поведение - полный факап. И на корню зарубает такие инициативы в "подшефном" ядре Linux. Которое даже и не позиционируется как мегакриптолиба, а крипто умеет вообще до кучи. Вот так мы сразу видим кто есть кто. Где профессионалы, а где галимое нубье.

Домашнее задание - прикинуть сколько программ в результате оказалось накормлено АНБшными генераторами "типа, случайных" чисел :). Ну и сколько ключей АНБ угадает "с трех нот".

> А вот высокоуровневые вещи, типа ущербного TLS/SSL/HTTPS - естественно, замороченные и
> дырявые.

Все добавочно усугубляется тем, что авторы openssl честно признаются что они - не криптографы. И это весьма заметно. По дурному апи с кучей факапов, по ряду дурных подлян и просто нубастых бестолковостей. В OpenSSL собраны все хучшие качества которые можно ожидать от криптолибы.


"Критическая уязвимость в OpenSSL"
Отправлено robux , 11-Июл-15 10:40 
> Домашнее задание - прикинуть сколько программ в результате оказалось накормлено АНБшными
> генераторами "типа, случайных" чисел :). Ну и сколько ключей АНБ угадает
> "с трех нот".

Вот об этом не знал.
Поэтому к случайным генераторам прикладнику нужно добавлять свою случайность.

> Все добавочно усугубляется тем, что авторы openssl честно признаются что они -
> не криптографы. И это весьма заметно. По дурному апи с кучей
> факапов, по ряду дурных подлян и просто нубастых бестолковостей. В OpenSSL
> собраны все хучшие качества которые можно ожидать от криптолибы.

С этим категорически не согласен!
Так может сказать только человек, который горя не знал с другими либами.

Мне приходилось иметь дело с проприетарной криптолибой (с VipNet) - по удобству API и по глюкавости оно даже рядом не валялось с OpenSSL. Если к закрытости и глюкавости добавить, что оно ещё моноплатформенное (только под Windows), то кросплатформенный открытый OpenSSL вобще за пояс затыкает. А если вспомнить, что обвязки к OpenSSL есть почти под ВСЕ языки прог-ния, а у ВипНета, к примеру, были только C-шные обвязки (паскалевскую мне пришлось самому писать), то проприетари нехрен ловить в сравнении с открытыми решениями.

И потом, среди открытых криптолиб выбор не так уж и велик: OpenSSL да GnuPG.
Сильно не завыпендриваешься.


"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 15-Июл-15 14:07 
> Вот об этом не знал.

Источник - changelog Tor. Им пришлось отдельно это прокостылить. Но они уже стреляные воробьи (и своих факапов у них - более чем). А кто попроще - просто влопаются в эти медвежьи услуги.

> Поэтому к случайным генераторам прикладнику нужно добавлять свою случайность.

Вот только крипто-либа по идее была нужна как раз для того чтобы прикладник этим не занимался, т.к. он в этом не копенгаген. А тут на тебе, EPIC FAIL.

> С этим категорически не согласен!
> Так может сказать только человек, который горя не знал с другими либами.

Я посмотрел как это делает DJB и понял как это надо делать, чтобы горя не знать :). Мизерная либа, с полутора требованиями понятными даже полному овощу. Вот так себе пятку прострелить довольно сложно.

> Мне приходилось иметь дело с проприетарной криптолибой (с VipNet) - по удобству
> API и по глюкавости оно даже рядом не валялось с OpenSSL.

Проприетарь в криптографии - заведомо фарс и лохотрон. Поэтому ты расписался в том что занимался имитацией бурной деятельности и на...ловом своих клиентов. Поздравляю. А что, сможешь после этого честно смотреть в глаза клиентуре? Стыд глаза не ест, да? :) Ну а я буду знать что ты - кидала и лохотронщик, подписывающийся имитировать бурную деятельность в заведомо провальных вещах.

> Если к закрытости и глюкавости добавить

Не понимаю зачем пинать труп. Закрытость автоматом означает что о какой либо надежности криптографии разговора просто не идет. Конец истории. Поэтому единственное чем ты смог "похвастаться" - тем что ты впаривал своим клиенам фуфло и по сути занимался кидаловом. Вот только ИМХО такая активность биографию специалиста совсем не украшает.

> И потом, среди открытых криптолиб выбор не так уж и велик: OpenSSL да GnuPG.
> Сильно не завыпендриваешься.

Мнение кидалы и лохотронщика - очень ценно, спасибо. А я как-нибудь попользуюсь DJB'шным творчеством, пожалуй. DJB на кидалу и лохотронщика не очень похож, в отличие от. А ты, дружок, просто занимаешься не своим делом, ничерта в этом не понимая да еще подкладывая клиентом заведомые подляны. И это называется словом "свинство" и профессионала совсем не украшает, если что.


"Критическая уязвимость в OpenSSL"
Отправлено usf , 10-Июл-15 18:43 
только libressl, только хардкор!

"Критическая уязвимость в OpenSSL"
Отправлено Аноним , 19-Июл-15 21:41 
Шо опять?! (c)№2
Бесплатный сыр ...