[мы все умерём] ssl и tls поломаны

yroslavasako


Марш Рэй (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 запрос к защищенной области и выполняет его от имени клиента.
fix: ssh -> ssl
P.S. http://extendedsubset.com/Renegotiating_TLS.pdf

jgimi

Ошибочка в заголовке, не ssh, а ssl.
И это видимо еще не последние уязвимости.
SSL, к примеру, уже работает в третьей редакции, TSL тоже кучу раз обновляли.

alfadred

Не SSH, а SSL.

agaaaa

Может имелось в виду, что SSH теперь нельзя считать secure?
Впрочем, в тексте приведёт только способ взлома HTTPS.

jgimi

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

alfadred

Я так понял, уязвимость распространяется только на авторизацию по сертификату и позволяет злоумышленнику получить доступ к закрытым для него областям. Если понял неверно - поправьте.

yroslavasako

Не SSH, а SSL.
А что у SSH нет этапа SSL негоциаций?

Serab

Ну ты же не перечислил все протоколы, в которых присутствует SSL-негоциация, так?

alfadred

А что у SSH нет этапа SSL негоциаций?
Не могу утверждать со всей уверенностью, но вроде бы нет, судя по тому, что в RFC ни разу не встречается слово "SSL".

jgimi

Откуда уверенность в том, что эта инфа имеет хоть какое-то отношение к ssh?
Почитай rfc для начала, протоколы устроены по-разному.
Детально я их не изучал, но что-то мне подсказывает, что ты п.....

Serab

да, по идее вот это оно

alfadred

Почитал подробнее. SSH использует DIffie-Hellman для key negotiation.

Serab

Ну SSL тоже через него может работать. Для key negotiation :grin:

kruzer25

Да ежу очевидно, что ssh просто случайно перепутали с ssl.

Serab

Кто «перепутали»? ?
В оригинальной статье про ssh ни слова нет.

alfadred

Ок, это другое.
Ну в общем я понял, что SSH не использует SSL.

agaaaa

Он тут явно акцентировал на важность SSH по его мнению.
Это если не опечатался, конечно.

Serab

что?

yroslavasako

да нет. Я просто думал, что криптография ssl и ssh работают одинаковым образом, и что ssh является одним из проявлений ssl. А оказался независимым велосипедом.

kruzer25

Ну либо он скопипастил откуда-то заголовок, либо сам опечатался.
А сейчас, имхо, просто пытается показать, что никакой ошибки не было, и всё just as planned.

kruzer25

То есть, по сути - та же опечатка из-за схожести названий.

yroslavasako

ну не думал я, что secure socket layer и secrure shell на самом низком уровне работают по-разному, полагал, что бессмысленно было бы изобретать новый протокол, когда был старый. В статье везде написано ssl, так что тебе придётся признать, что для получения заголовка копипасту нужно было бы править.
P.S. а вообще мне надоело, что пенартур, как и MS, лучше меня знает, что мне нужно и что я имел в виду

yroslavasako

Он тут явно акцентировал на важность SSH по его мнению.
Это если не ошибся, конечно.
ты прав, а я ошибся в исходных посылках

s507040

суть которого сводится к полному отключению операции согласования (negotiation)
эээ. а ключи откуда браться будут?

jgimi

На сменных носителях :grin:

s507040

клиент: отсюда и далее все мои сообщения будут гарантированно авторизованы.
сервер: схуяли?
клиент: мамой клянусь.
сервер: мама в качестве третьей удостоверяющей стороны --- принято.

jgimi

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

s507040

я так и знала, что кэп заподозрит аналогию :]

Spin

ИМХО тут больше PR чем реальной жопы.
Вся проблема в том что веб сервак выполняет запрос который пришел ДО авторизации пользователя и вообще говоря мог прийти откуда хошь и от кого хошь, только уже с правами аутентифицированого пользователя. Так подумать так это больше бага текущей реализации веб серваков + клиентов то что они не поддерживают resend запроса после handhsake. Ситуация должна быть такая по идее.
Клиент: Я Вася хочу бабу рыжую + мильен баксов
Сервер: Реально? Покажь сертификат?
----skip handshake-----
Сервер: <зашифровано> Ну лан ты точно Вася, так чего ты там хотел? </зашифровано >
Клиент: <зашифровано>Бабу рыжую + мильен баксов</зашифровано>
Сервер: <зашифровано>На вот тебе.</зашифровано>

kruzer25

По идее, должно быть так:

Клиент: хочу бабу рыжую + мильен баксов
Сервер: Хуй тебе

Клиент: Я Вася, вот сертификат, хочу бабу рыжую + мильен баксов
Сервер: На вот тебе.

Spin

Если зашифровано то сертификат клиента уже известен.

s507040

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

Spin

Если ты про
skip handshake

то тут имеется ввиду что мне не хотелось описывать как это происходит.

kruzer25

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

s507040

нет, про
Для OpenSSL уже выпущен временный патч, суть которого сводится к полному отключению операции согласования (negotiation)

Spin

может там про renegotiation имелось ввиду?
Да про него.
It’s obviously going to take a little while for the world to patch this – and since the news is spreading like wildfire I’ve put up a patch to OpenSSL that bans all renegotiation. I’m sure an official release will follow very shortly.
 

yroslavasako

это все круто, конечно, но мне действительно неясно, что имеется в виду под "выкинуть negotiation".
если negotition включает в себя пересылку зашифрованного с помощью сертификата сервера публичного ключа клиента, то, выкинув его, можно слать зашифрованные сообщения до усрачки, серверу свои зашифровывать будет нечем.
Ткнувшись в вики по настоятельным советам здесь отписавшихся, обнаружил более детальное описание протокола. Первый этап negotiaions - это собственно выбор алгоритма шифрования. В том числе SSL может выбрать тот же алгоритм, что и ssh. Именно на этом этапе сломана безопасность. Дальше идёт этап обмена ключами, вот он уже безопасен и не сломан.

s507040

Первый этап negotiaions - это собственно выбор алгоритма шифрования.
negotiation --- это не только выбор алгоритма, но и обмен premasterkey, который используется далее (для построения раундовых ключей для симметричного шифрования, например) и (опционально, если необходимо) публичными ключами. его невозможно выкинуть без концептуального пересмотра протокола.
выше было правильно написано, что в патче был запрещен только renegotiation. вообще, еще предлагалось при пересогласовании включать в ClientHello или ServerHello данные последнего завершенного сообщения, чтобы атакущая стороны не могла воспользоваться незавершенными сообщениями.
Оставить комментарий
Имя или ник:
Комментарий: