В протоколах SSL/TLS найдена критическая уязвимость

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

Yeah! Как хорошо, что я не банковский админ!

Ждем диагноза Silvy :) Она обычно уязвимости одной из первых комментирует.

Вот те раз!!! Попадалово. Особенно для М$ - они медленно реагируют. Теперь протокол перелопачивать???

Для OpenSSL уже выпущен патч который отключает операции согласования

Хотелось бы узнать, какой сайд-эффект от этого патча помимо «отключает операции согласования», какие негативные последствия для конечного юзера?

ща у всех появятся свои протоколы.

http://www.linux.org.ru/view-message.jsp?msgid=4206224&lastmod=1257511886597

http://www.linux.org.ru/view-message.jsp?msgid=4206224
еще с ночи висит.. хотя у меня скорее больше вопросов, чем комментариев

если есть специалисты по протоколу SSL/TLS
---
после отключения re-negotiation пострадает ли и как пострадает работа apache mod_ssl, imap, postgres (может еще что можно добавить в список?) ?

>Следует заметить, что без изменения протокола решить данную проблему невозможно.

Унд наглише обирайтен!

а все потому что bloatware!!!

минимализм рулит.

З.Ы. и кто уверен после этого, что в монстре ssh/sshd не осталось таких же дыр?

> минимализм рулит.

Альтернативы?

что именно bloatware? уязвимость не в пакете openssl (хотя и в нем тоже), а в самом протоколе, кроме openssl еще есть и gnuTLS и nss , там тоже эта проблема присутствует

SSH вроде как не использует re-negotiation со сменой ключей посреди сессии, использует https (как apache mod_ssl (всех версий) так и обсуждается и MS IIS, PostgreSQL, IMAP (tls)) Вполне возможные кандидаты и другие программы использующие SSL/TLS, например Jabber ) банковские клиенты, и т д, и т п. Патч то конечно простой, взяли и запретили смену ключей сессии.. вопрос насколько это нарушит работу программ, получается что будут обрывы и звонки клиентов "Да с ноября месяца НЕ ЕДИНОГО!!! а ТУТ!!!" )

Проблема не совсем в SSL/TLS. Проблема в связке TLS и HTTP. Попробую описать суть метода на пальцах. К примеру у нас есть сервер s.com на котором есть как документы требующие авторизации (https://s.com/public, так и не требующие (https://s.com/private). Большинство серверов настроено таким образом, что при обращении пользователя к документу https://s.com/public, у него не будет запрошен сертификат. В таком случае, злоумышленник может запросить https://s.com/private, сервер запросит его предъявить свой сертификат, который он запросит у пользователя и перешлет серверу.

В таком случае сервер выполнит запрос и вернет ответ, который злоумышленник не сможет прочитать. Однако злоумышленник может послать POST запрос и выполнить некоторые действия с аккаунтом пользователя.

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

Проблема в том, что HTTP не позволяет потребовать послать тот же запрос повторно, а значит ответ приходит в рамках того же соединения.

После отключения renegotiation абсолютно не пострадают пользователи, у которых нет сертификатов. А те у кого есть должны будут устанавливать соединение с сертификатом, как и было задумано, вместо повышения привилегий во время работы. В случае с HTTP надо зайти сразу на приватный ресурс. IMAP по X.509 сертификатам скорее всего сразу спросит сертификат. Для postrges/... проблема так же не должна возникнуть.

теперь мне ссыкотно с карточки платить.. хотя кому я нужен?

>>Попробую описать суть метода на пальцах.

Респект! Запутанность объяснения всегда обратна глубине понимания.

Банковские клиенты используют свои реализации TLS и, скорее всего, сразу запрашивают сертификат. В нашем (http://alpha.ru/) ПО сертификаты запрашиваются сразу. Если сертификата нет, то пользователь никогда не сможет повысить своих полномочий. Не думаю что у других реализовано иначе, наоборот, я удивлен что при написании mod_ssl не сделали сразу запроса сертификата.

Вот ссылка на диаграмму: http://extendedsubset.com/Renegotiating_TLS_pd.pdf

Я фшоке - оно что, во время сессии меняет ключи??? Какая глупость если так... Мне всегда казалось, что man-in-the-middle - это самое страшное для пдобного рода штук и на это надо было обращать внимание в первую очередь...

> что именно bloatware?

протокол

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

> что именно bloatware?

протокол

доказательство: как выясняется, от обезжиривания протокола никто в сущности не пострадает:

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

т.е. атака возможна ТОЛЬКО если в середине сессии идет запрос СЕРТИФИКАТА ? так и только так?

в обычных сессиях типа (допустим) DHE->AES re-negotiation исключена получается? Тогда влияние уязвимости получается не очень то большое

в картинках понятнее, спасибо

> я удивлен что при написании mod_ssl не сделали сразу запроса сертификата.

Меньше удивляйтесь, больше думайте :-) Изначальная функция SSL - согласование криптографических параметров канала и аутентификация сервера.

Сервер имеет возможность запросить сертификат клиент, но нужен он или нет, определяет приложение на сервере. Когда вы логинитесь на GMail (а вы делаете это по https) ваш браузер использует ваш сертификат? Ага, щас, разбежались :-)

И именно из-за того, что аутентификация клиента нужна очень даже не всегда, и возникла данная "критическая уязвимость".

Весь мир в опасности!!! Все пропало!!! Я открыл уязвимость траспортой системы по всему миру!!! Все грузовики имеют фатальную уязвимость!!! После погрузки водитель закрывает борт, идет в кабину, заводит машину и уезжает. Злоумышленник может воспользоваться интервалом между закрытием борта и отъездом грузовика, и загрузить в кузов свой груз. Конечно, грузовик поедет не туда куда нужно злоумышленнику, а куда надо водителю, но это дает злоумышленнику возможно отправить свой груз непонятно куда!!!! Все в опасности!!! Всё пропало!!! Конструкторы грузовиков идиоты!!! Весь грузовой транспорт изначально должен иметь закрывающийся на замок крытый фургон!!!

LOL. Эксперты, блин :-)

Вот за такие комментарии я и люблю lor

Приятная новость. До фикса интернет платежами не пользуюсь.

>> я удивлен что при написании mod_ssl не сделали сразу запроса сертификата.

> Меньше удивляйтесь, больше думайте :-) Изначальная функция SSL - согласование криптографических параметров канала и аутентификация сервера.

> Сервер имеет возможность запросить сертификат клиент, но нужен он или нет, определяет приложение на сервере. Когда вы логинитесь на GMail (а вы делаете это по https) ваш браузер использует ваш сертификат? Ага, щас, разбежались :-)

я кстате удивлён тоже. но вот пояснение
"вы делаете это по https) ваш браузер использует ваш сертификат?"
наталкивает только на одну мысль:

ну тыг если серверу не нравиться ситуации когда мой клиент подключается без сертификата
(например если я захожу на https://light.webmoney.ru/ , а не на https://www.gmail.com/)
-- то пусть ТУПО _закрывает_ HTTPS-соеденение с HTTP-ошибкой код которой соответствует смыслу "без сертификата заходить нелья".

я не конешно не специалист по всем этим SSL/TLS , но помоему очевидно что всё должнобыть чотко и логично -- поочереди: рукопожатие (обмен ключами, идентификация) , сессия , закрытие-сеcсии . зачем чтото усложнять %) %)

>>зачем чтото усложнять %) %)

НУ! ЁПТЫТЬ!

аргумент! =)

а, я хотел написать "НУ, ЁПТЫТЬ!"

> зачем чтото усложнять %) %)

;)

>т.е. атака возможна ТОЛЬКО если в середине сессии идет запрос СЕРТИФИКАТА ? так и только так?
Не только. Можно атаковать когда нет вообще клиентского сертификата.
Вот пример как послать себе пиццу от имени юзера:
http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html

Ну вместо пиццы, может быть и пароль, конечно :)

>Приятная новость. До фикса интернет платежами не пользуюсь.

А ты несколько банков крупных под собой держишь, что тебя волнуют эти моменты, да ?

> ну тыг если серверу не нравиться ситуации когда мой клиент подключается без сертификата

Тут на самом деле сертификат ничего не меняет, и вообще ни при чем - я повелся на картинки постные rymes'ом. Дело вообще в разрешении вторичного handshake. На картинках не приведено самое интересное, когда атакующий может повторно инициировать handshake. Вот тогда получается по-настоящему весело :-)

Меня волнует сохранность 3$ на виртуале.

Специалисты, объясните-таки на пальцах, решето или нет и что именно.

И что? Ну хорошо, инициировал он еще один handshake. Пробросил он его от пользователя. Прочитать данные он не может, как он был на анонимном SSL так и остался (если нет сертификата), так на фига ему это делать?

Единственным интересным моментом остается случай наличия сертификата у пользователя и отсутствие такового у злоумышленника. А в такой ситуации запрос сертификата при первичном negotiationе и есть решение проблемы. Если пользователь сертификат дал - он авторизован, иначе аноним. В дальнейшем можно не делать renegotiation.

IETF больше пишет про HTTPS, в котором нет кода ошибки: запроси еще раз, но с полномочиями.

Кстати на картинках о том и речь. Но, еще раз, атакующий может инициировать хендшейк, но полномочия его должны быть повышены ПОСЛЕ этого, а проблема в том, что mod_ssl повышает полномочия ДО того как прошел handshake.