LINUX.ORG.RU

DROWN — новая уязвимость в OpenSSL

 drown, ,


0

2

1 марта в рассылке OpenSSL сообщили о новой уязвимости: «Cross-protocol attack on TLS using SSLv2» (также известна как DROWN, CVE-2016-0800) позволяет расшифровать TLS-сессию, если сервер допускает работу по SSLv2 с использованием шифров класса EXPORT. Уязвимости подвержены приложения, использующие SSLv2 с любой версией OpenSSL; версии OpenSSL 1.0.1l (и более ранние) и OpenSSL 1.0.2 содержат ошибки, которые облегчают эксплуатацию уязвимости по сравнению с OpenSSL более поздних версий. Выпущены обновления, которые отключают поддержку SSLv2 по умолчанию и удаляют шифры EXPORT, исключая таким образом возможность конфигурации сервера, уязвимой к DROWN. Проблему также можно обойти, отключив поддержку SSLv2 в приложениях.

Популярное разъяснение природы и последствий уязвимости

Приложение, позволяющее проверить наличие уязвимости

Довольно подробный пост на Habrahabr

>>> Официальное сообщение от разработчиков OpenSSL

★★★★★

Проверено: tailgunner ()
Последнее исправление: tailgunner (всего исправлений: 4)

шифров класса EXPORT

Да сколько ж можно?

удаляют шифры EXPORT

Джва года, как надо было это сделать.

no-such-file ★★★★★
()

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

anonymous
()
Ответ на: комментарий от AVL2

SSL 3 был отключен уже в умершей Опере на Presto хз сколько лет назад, а SSL 2 был вообще удален из кода еще раньше.

anonymous
()
Ответ на: комментарий от baka-kun

Я повторю, ладно? Если банк работает с международными платежными системами, он должен проходить сертификацию на соответствие PCI DSS, где черным по-английски написано: не ниже TLS 1.0, переход на TLS не ниже 1.1 по первому же требованию.

Как раз банк может спокойно работать без всяких там PCI DSS (и зачастую ими там даже и не пахнет), но вот от своих шлюзов-контрагентов-мерчантов, работающих с карточными данными, соответствие этому стандарту будет требовать. Но сам банк… Максимум процессинг, и то если он есть.

PCI DSS это совершенно необязательный стандарт в общем случае, и многие никаких аудитов по нему и не пытаются проходить, если есть возможность договориться без него. Ибо дорого и геморрой. Его проходят вынужденно, т.к. обычно банк к своему процессингу иначе не подключит.

ynn
()
Ответ на: комментарий от ynn

Как раз банк может спокойно работать без всяких там PCI DSS

И эмитенты, и эквайеры (merchant bank), и сервис провайдеры с прочими третьими лицами (TPA — third party agents в терминологии PCI), и мерчанты — все обязаны-таки соответствовать PCI DSS. Точнее существуют ещё более специфические стандарты, всякие там ISO-ATM, ISO-C, ISO-M, ISO-PP, но это немного другая опера.

Например, «Альфа-Банк» имеет действующий до 31 декабря PCI DSS, аудитором по которому является QSA «ДиалогНаука». У «Внешэкономбанка» также, но аудитор другой. А, знаю, «Гознак» не имеет PCI DSS, но зато у них специфический и куда более строгий AVP, позволяющий персонифицировать чипы и магнитные полосы. Хотя постой, он ведь не банк…

Даже монстр «Сбербанк» имеет PCI DSS. «Информзащита» вешалась, но таки проводила аудит.

Максимум процессинг, и то если он есть.

Все обрабатывающие, хранящие, передающие и вообще прикасающиеся к информации о транзакциях, владельцах и прочих карточных данных обязаны соответствовать PCI DSS. Даже если это мерчант четвертой категории, для которого не обязан аудит, а хватает только честного слова в форме. Хотя конечно, если у тебя меньше миллиона транзакций в год, Visa и не подумает устраивать внезапную проверку.

многие никаких аудитов по нему и не пытаются проходить

Он как бы обязателен начиная с некоторого уровня. Ежегодно. Через месяц просрочки Visa вешает на тебя желтую карточку, и с тобой перестают работать многие крупные игроки. Еще через месяц вешают красную, и ты варишься в собственном соку. А дальше тебя, считай, просто ни для кого больше не существует.

baka-kun ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.