Регистрация06.11 // В протоколах SSL/TLS найдена критическая уязвимость
Марш Рэй (Marsh Ray) и Стив Диспенса (Steve Dispensa) из компании PhoneFactor обнаружили критическую уязвимость в протоколах SSL/TLS, позволяющую злоумышленнику организовать подстановку своих данных в устанавливаемое между двумя точками защищенное соединение. Для успешного проведения атаки злоумышленник должен иметь возможность вклинится в проходящий защищенный трафик, например, получить контроль над промежуточным шлюзом, прокси сервером или установить свое оборудование в разрыв сетевого кабеля (man-in-the-middle атака).
Удачно проведенная атака позволяет незаметно добавить свой текст в начало SSL/TLS сессии. Так как часто сеанс работы с сайтом состоит из множества разных SSL/TLS сессий, теоретически злоумышленник может под прикрытием обычной активности пользователя совершить угодные атакующему действия на сервере, при этом пользователь будет уверен, что совершает легитимные операции в рамках защищенного соединения. Успешно проведенные примеры атак были продемонстрированы при работе различных типов клиентского ПО с web-серверами Apache и Microsoft IIS, также подобная атака возможна и при использовании TLS в IMAP.
Основная проблема обнаруженной уязвимости состоит в том, что уязвимость связана с недоработками дизайна протокола TLS, а именно методом организации согласования параметров в установленных соединениях, и не зависит от конкретных реализаций протокола. Для OpenSSL уже выпущен временный патч, суть которого сводится к полному отключению операции согласования (negotiation). Так как без изменения протокола решить проблему невозможно, в экстренном порядке ведущими производителями и стандартизирующими организациями отрасли был сформирован проект Project Mogul, задачей которого является разработка и принятие необходимых расширений стандарта TLS.
Сценарий атаки выглядит примерно так: Атакующий вклинивается между клиентом и сервером, устанавливает HTTPS соединение с сервером. Соединение со стороны клиента временно замораживается на незавершенной стадии. Далее серверу отправляется запрос в защищенную область, сервер инициирует полностью новое соединение и запрашивает клиентский сертификат. Атакующий перенаправляет не данной стадии все пакеты между клиентом и сервером в неизменном виде. После завершения фазы проверки сертификата злоумышленник формирует свой HTTP запрос к защищенной области и выполняет его от имени клиента.
Источник: http://www.opennet.ru/opennews/art.shtml?num=24132
комментариев: 9796 документов: 488 редакций: 5664
Вот ссылка (внимание https) tls-renegotiate.
Да, если кто интересуется — Tor неуязвим к данной атаке, т.к. использует согласования другим образом.
Дырке больше десяти лет! Замечательно.
комментариев: 11558 документов: 1036 редакций: 4118
З. Ы. стандарт OpenPGP по моему мнению тоже излишне сложен.
комментариев: 11558 документов: 1036 редакций: 4118
Если убрать из спецификации всё лишнее, оставив только MUST'ы и SHOULD'ы, она становится достаточно компактной и лёгкой. В рабочей группе даже высказывалось предложение выпустить облегчённую спецификацию, этакий OpenPGP Light, но до сих пор никто не смог найти на это время.
Просто так послать нужный запрос не получится, ибо для этого нужно знать клиентский ключ. Совсем тупо выдать себя за клиента нельзя, но, видимо, на стадии согласования можно притвориться клиентом так, чтобы сервер не смог отличить.
комментариев: 155 документов: 20 редакций: 5
А вообще, можно же реализовать SSL4.0 по принципу JS дополнений для Firefox, c загрузкой апдейтов с сервера обновлений или даже с банковского сайта :-)
комментариев: 155 документов: 20 редакций: 5
Противнику достаточно первым пообщаться с сервером и послать специально не законченный ивел-запрос, вследствии чего только ретранслированный легитимный get запрос был бы проигнорирован веб сервером, но успешно распознаны легитимные печенюшки.
Проблема, в первую очередь, касается HTTPS, как протокола-связки SSL и HTTP (которому простота исполнения и однозначности топора недостижима, у ссл одназначности всё-таки больше), плюс дизайн веб серверов. Это особенно видно на примере сценария с клиентскими сертификатами (пересогласования по инициативе сервера).
Отдельно стоит проблема SSL/TLS при пересогласовании по инициативе клиента. В этом случае достаточно выделить пересогласование (по инициативе клиента) в отдельный тип рукопожатия, тогда человек-по-середине не смог бы вещать незамеченно от имени легитимно-cookie'ующего человека по сценарию с незаконченными запросом.
Кстати, единственный вариант лечение при существующих возможностях эффективен на 100 процентов, также как исцеление от головной боли через гильотину.
Красота, а главное как отрезал.
P. S. Тор может и не уязвим к такой аттаке на протокол, но точно уязвим к такой "атаке" на либу. Ожидаем обновлений торы, пока вся сеть не выключилась.
Насколько я знаю, это касается лишь экзотических случаев, когда идёт работа с клиентским сертификатом в браузере. Вы много таких сайтов видели вживую? Я видел (пользовался) только двумя: вебмани и андедли.