[мы все умерём] ssl и tls поломаны
И это видимо еще не последние уязвимости.
SSL, к примеру, уже работает в третьей редакции, TSL тоже кучу раз обновляли.
Не SSH, а SSL.
Впрочем, в тексте приведёт только способ взлома HTTPS.
Да и способ вполне тривиальный и давно известный.
Не очень понятно, зачем панику поднимать.
Я так понял, уязвимость распространяется только на авторизацию по сертификату и позволяет злоумышленнику получить доступ к закрытым для него областям. Если понял неверно - поправьте.
Не SSH, а SSL.А что у SSH нет этапа SSL негоциаций?
Ну ты же не перечислил все протоколы, в которых присутствует SSL-негоциация, так?
А что у SSH нет этапа SSL негоциаций?Не могу утверждать со всей уверенностью, но вроде бы нет, судя по тому, что в RFC ни разу не встречается слово "SSL".
Почитай rfc для начала, протоколы устроены по-разному.
Детально я их не изучал, но что-то мне подсказывает, что ты п.....
вот это оно
да, по идее
Почитал подробнее. SSH использует DIffie-Hellman для key negotiation.
Ну SSL тоже через него может работать. Для key negotiation
Да ежу очевидно, что ssh просто случайно перепутали с ssl.
В оригинальной статье про ssh ни слова нет.
Ну в общем я понял, что SSH не использует SSL.
Это если не опечатался, конечно.
что?
да нет. Я просто думал, что криптография ssl и ssh работают одинаковым образом, и что ssh является одним из проявлений ssl. А оказался независимым велосипедом.
А сейчас, имхо, просто пытается показать, что никакой ошибки не было, и всё just as planned.
То есть, по сути - та же опечатка из-за схожести названий.
P.S. а вообще мне надоело, что пенартур, как и MS, лучше меня знает, что мне нужно и что я имел в виду
Он тут явно акцентировал на важность SSH по его мнению.ты прав, а я ошибся в исходных посылках
Это если не ошибся, конечно.
суть которого сводится к полному отключению операции согласования (negotiation)эээ. а ключи откуда браться будут?
На сменных носителях
сервер: схуяли?
клиент: мамой клянусь.
сервер: мама в качестве третьей удостоверяющей стороны --- принято.
Аналогичный анекдот есть про доказательство свойств треугольника в Грузинской школе.
я так и знала, что кэп заподозрит аналогию :]
Вся проблема в том что веб сервак выполняет запрос который пришел ДО авторизации пользователя и вообще говоря мог прийти откуда хошь и от кого хошь, только уже с правами аутентифицированого пользователя. Так подумать так это больше бага текущей реализации веб серваков + клиентов то что они не поддерживают resend запроса после handhsake. Ситуация должна быть такая по идее.
Клиент: Я Вася хочу бабу рыжую + мильен баксов
Сервер: Реально? Покажь сертификат?
----skip handshake-----
Сервер: <зашифровано> Ну лан ты точно Вася, так чего ты там хотел? </зашифровано >
Клиент: <зашифровано>Бабу рыжую + мильен баксов</зашифровано>
Сервер: <зашифровано>На вот тебе.</зашифровано>
Клиент: хочу бабу рыжую + мильен баксов
Сервер: Хуй тебе
Клиент: Я Вася, вот сертификат, хочу бабу рыжую + мильен баксов
Сервер: На вот тебе.
Если зашифровано то сертификат клиента уже известен.
если negotition включает в себя пересылку зашифрованного с помощью сертификата сервера публичного ключа клиента, то, выкинув его, можно слать зашифрованные сообщения до усрачки, серверу свои зашифровывать будет нечем.
skip handshake
то тут имеется ввиду что мне не хотелось описывать как это происходит.
Если зашифровано то сертификат клиента уже известен.Если говорить абстрактно - то известен ключ клиента, то, что позволяет нам общаться с ним так, чтобы не прочитал никто другой. Подтверждение личности клиента при этом ещё не известно.
Для OpenSSL уже выпущен временный патч, суть которого сводится к полному отключению операции согласования (negotiation)
Да про него.
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.
это все круто, конечно, но мне действительно неясно, что имеется в виду под "выкинуть negotiation".Ткнувшись в вики по настоятельным советам здесь отписавшихся, обнаружил более детальное описание протокола. Первый этап negotiaions - это собственно выбор алгоритма шифрования. В том числе SSL может выбрать тот же алгоритм, что и ssh. Именно на этом этапе сломана безопасность. Дальше идёт этап обмена ключами, вот он уже безопасен и не сломан.
если negotition включает в себя пересылку зашифрованного с помощью сертификата сервера публичного ключа клиента, то, выкинув его, можно слать зашифрованные сообщения до усрачки, серверу свои зашифровывать будет нечем.
Первый этап negotiaions - это собственно выбор алгоритма шифрования.negotiation --- это не только выбор алгоритма, но и обмен premasterkey, который используется далее (для построения раундовых ключей для симметричного шифрования, например) и (опционально, если необходимо) публичными ключами. его невозможно выкинуть без концептуального пересмотра протокола.
выше было правильно написано, что в патче был запрещен только renegotiation. вообще, еще предлагалось при пересогласовании включать в ClientHello или ServerHello данные последнего завершенного сообщения, чтобы атакущая стороны не могла воспользоваться незавершенными сообщениями.
Оставить комментарий
yroslavasako
fix: ssh -> sslP.S. http://extendedsubset.com/Renegotiating_TLS.pdf