31.12 // Коллизии в MD5 использованы для практической атаки на SSL-сертификаты
Под занавес года группа исследователей, в числе которых Alex Sotirov, Marc Stevens, Jake Appelbaum, Arjen Lenstra, Benne de Weger, David Molnar, сделала громкую новость. На 25-й конференции Chaos Computing Congress ею была представлена практическая криптоаналитическая атака на SSL-сертификаты X.509, используемые веб-сайтами для защиты соединений по протоколу HTTPS.
На основе всех предыдущих наработок в области поиска коллизий в хэш-алгоритме MD5 исследователи создали способ конструирования пар сертификатов X.509 с идентичными хэш-значениями MD5. Используя эту методику и вычислительный кластер из 200 видео-приставок Playstation3 они сформировали два сертификата X.509, один из которых выглядел совершенно легитимно и был передан на заверение в удостоверяющий центр Equifax Secure Global eBusiness (этот УЦ, как и множество других, для формирования подтверждающей цифровой подписи на сертификате использует именно алгоритм MD5). Другой сертификат не содержал бит ограничения доверия (превращая его в сертификат промежуточного УЦ, способного заверять другие сертификаты) и не прошёл бы процедуру заверения в УЦ, но соответствие хэш-значений позволило исследователям просто перенести ЭЦП с заверенного легитимного сертификата на поддельный. В результате ни один браузер, содержащий корневой сертификат Equifax Secure Global eBusiness, не смог бы выявить подобную подделку, поскольку, формально, она заверена доверенным УЦ. А благодаря иерархическому распространению доверия от легитимного УЦ каждый пользователь расценит доверенными и любые сертификаты, заверенные этой сконструированной подделкой.
Атаке подвержены все браузеры, содержащие хотя бы один доверенный корневой сертификат, использующий MD5 для выработки цифровых подписей. В качестве временного противодействия пользователь может вручную изменить доверие к тем или иным корневым сертификатам в хранилище браузера, что, однако, не слишком практично в виду количества корневых сертификатов в современных браузерах. Единственное полноценное решение (в рамках действующей модели PKI) — замена сертификатов самими удостоверяющими центрами и их обновление в браузерах, но они, несмотря на то, что были предупреждены заранее и давно в курсе положения дел с MD5, не спешили выполнять переход. Вероятно, теперь, когда детали атаки преданы гласности, они станут действовать более активно.
Источник: http://www.win.tue.nl/hashclash/rogue-ca/
комментариев: 155 документов: 20 редакций: 5
Злоумышленникам следует заверить сертификат после даты публикации уязвимости. Тогда пользователям следует проверять дату заверения сертификата соответственного уровня из цепочки, того который прошел проверку, и если она позже нулевого дня, заботиться об защите от mitm.
Такое заверение чревато уголовным преследованием, так как данные лица, заверяющего оригинальный сертификат, известны.
Точно также можно сказать, что любая фишинг атака с заверенным сертификатом опасна, но практически я о таких атаках до сих пор не слышал.
Резюмируя, можно сказать, что атака не опаснее использования незаверенных сертификатов (как на этом сайте), и для тех сайтов, которые для вас очень важны (а их вряд-ли большое число) следует проверять выше названные критерии, и лишь затем инсталлировать сертификат в браузер. Опасность данная атака представляет для репутации владельцев сайтов и людей, безапеляционно доверяющих желтой полоске браузера. Еще следует заметить, что в общей модели угрозы данную уязвимость я бы назвал менее опасной, нежели наличие вредоносного ПО, дыр в браузере, человеческого фактора или бизнес-фактора.
Данные рассуждения я основывал на технической информации из первого абзаца своего поста.
комментариев: 11558 документов: 1036 редакций: 4118
Боюсь, с доказательной базой у следствия возникнут сложности. Что с того, что какой-то абстрактный математический показатель моего сертификата и сертификата неких злодеев (о которых я вообще не знаю ничего!) по неудачной случайности совпал?
Зачем обманываете? /FAQ/Проект#h47-13
Любой сертификат автоматически принимается браузером (без вопросов пользователю; впрочем, вопросы пользователю тоже не привели бы ни к чему путному — привет кликательному рефлексу!), если заверен доверенным УЦ. Как в случае данной атаки.
комментариев: 155 документов: 20 редакций: 5
Как минимум в некоторых браузерах (konqueror) есть возможность отклонять/спрашивать для определенных сертификатов или не принимать их наследников.
Вы меня неимоверно обрадовали! Я про пару сайтов а вы мне про туеву кучу форумов :)))
Ни кого я не обманываю. Я все расписал и добавил вначале ИМХО. И для меня Ваш сайт не подписан. Хотя, да. Для домохозяйки опасней.
комментариев: 11558 документов: 1036 редакций: 4118
Долю Konqueror в массе браузеров Вам ведь называть не надо? Если Вы говорите о фишинге (суть массированых атаках), а не о целенаправленных атаках на нескольких параноиков, то должны мериться с тем, что "целевая аудитория" — это виндузятники с IE. Те самые домохозяйки.
О чём речь?
Некорректная формулировка. Возможно, его сертификат заверен не тем УЦ, который умолчально вшит в Ваш браузер. Ну установите корневой сертификат этого бесплатного УЦ (CACert), он ничем не хуже, а возможно и лучше, коммерческих УЦ, продающих сертификаты от чужих сайтов или для подписания кода первому встречному (исторических примеров хватает).
комментариев: 155 документов: 20 редакций: 5
Понял. Спасибо.
CaCert, которым подписан сертификат этого сайта, в их числе?
комментариев: 155 документов: 20 редакций: 5
комментариев: 9796 документов: 488 редакций: 5664
Это не решает проблемы: как доверять сертификату первый раз? Например, можно свериться с кем-то из других источников. Или, например SATtva на нашем сайте может все новые отпечатки заверять своей pgp-подписью.
Актуально скорее для пользователей сети Tor, поскольку там некоторые исходящие узлы иногда пытаются подменить сертификат.
комментариев: 11558 документов: 1036 редакций: 4118