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