Аутентификация в SSH v.2
Ээ чё? В SSH v2 аутентификация с ключами разве не взаимная? Если сервер не знает открытого ключа клиента, то клиент разве не должен разорвать соединение?
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
Нормы пользования. Некоторые права на материалы сайта защищены по условиям лицензии CreativeCommons. Движок
openSpace 0.8.25a и дизайн сайта © 2006-2007 Vlad "SATtva" Miller.
|
||||||||||||||||||||||||
Кстати, не уверен, что из этого легко можно сделать протокол. Вся суть асимметричного крипто в том, что есть пары приватный-публичный, где информацию, зашифрованную публичным ключом, расшифровывает только владелец приватного. Как заставить это работать иначе? Если я просто вышлю публичный ключ в доказательство владения им по неаутентифицированному и шифрованному каналу, его прочитает митмер. Т.е. стороны не избавятся от митмера, т.к. он подменит информацию при выработке новых ключей обычным способом.
Впрочем, есть протоколы аутентификации основанные на том, что обе стороны владеют какими-то общим секретом (по-моему, они тоже сводятся к DH). В частности, в том же OTR есть аутентификация по общему симметричному ключу, известному обоим абонентам.
в сессионный ключ.
Я даже не говорю о реальности ситуации, когда у атакующего будет закрытый ключ сервера, и саму ситуацию я взял с crypto.se. Просто факт, что SSH при ней может пасовать, хотя от этого можно было бы защититься, пока можно провести аутентификацию по ключу клиента. Неясно, где еще этот недостаток (раздельное установление канала и аутентификация ключами) может боком вылезти.
3. Да, во многих ситуациях это – относительно нормальное положение дел. Добро пожаловать в реальный мир, нео.
4А. Украсть открытый ключ клиента != подменить его на сервере
4Б. Если клиент не знает сервер, сервер все еще имеет открытый ключ клиента.
5. Не совсем, точнее, лишь как одна опция. Атака невозможна в случае использовании DH.
В общем, подведем итог – аутентификация по ключу вроде бы митмом не ломается, но неприятный осадок от сумбурной структуры аутентификации SSH остался.
Дык, это что вообще? Как его ставить, как оно будет работать с существующими программами?
ощущение, что где-то здесь: пост Гость (21/04/2013 07:30), должно закончится обсуждение. ибо все варианты с кражами и физ доступом к машинам, хранящим секретные ключи, – "бондиада" или интерпретации атак без относительно к самому SSH.
По-моему, так везде делается. Сначала устанавливается шифрованный канал со стороной, а потом выясняется, та ли эта сторона или нет. Могу привести в пример шифрование в IM (пусть тот же OTR в XMPP). По умолчанию шифрование там оппортунистическое по DH, причём ключи сторон никак не проверяются. Если у вас есть желание и возможность, после установления шифрованной сессии можно запросить отпечаток OTR, подписанный PGP-ключом собеседника (и выслать ему, соответственной, свой подписанный). Другие протоколы в IM требовали того же: сверки отпечатков по какому-то заранее аутентифицированному каналу (телефон, PGP-переписка и т.д.). Если сверить по каким-то причинам нельзя, то да, MITM будет успешно работать, но провести его надо при самом первом сеансе, т.к. после этого отпечатки ключей запоминаются и попытка MITM'ера сменить ключ тут же вызовет ругнань в IM, и попытка MITM'а будет раскрыта. С SSH аналогично: если MITM'ер не успел провести атаку в самый первый сеанс, то всё: ssh-клиент запомнил отпечаток и сразу же заметит, если он позже сменится.
Как клиент может «забыть» отпечаток сервера? Он сохраняется в настройках автоматически. Если он сохранился хотя бы в одном месте, позже можно его оттуда извлечь и перенести в любой другой профиль, даже автоматически (не логинясь на сервер заново из-под нового профиля).
Более реальная проблема — получить достоверный отпечаток сервера, чтобы зайти туда первый раз и загрузить свой (клиентский) ключ. Можно в крайнем случае поступить так: сначала зайти как есть, приняв любой предложенный отпечаток, а потом узнать валидный отпечаток по сторонним методам (аутентифицированному какому-то каналу). Если сравнение не покажет различий, можно будет постфактум установить, что MITM'а никогда не было.
Я имел в виду случай, когда атакующий взломал (настоящий) сервер и может делать на нём всё, что захочет. Вы же, как я теперь понял, имели в виду подставной сервер, пытающийся скормить клиенту его фейковый публичный ключ.
На мой взгляд, критичнее вывод, к которому пришли в этом треде: если клиент не знает отпечатка ключа сервера и жмёт YES, то, в случае MITM-атаки, атакующий просто-напросто получает его пароль. Масштабы последствий, думаю, пояснять не нужно.
Это не то ли, что вам надо?
Да, согласен. Тем не менее, вопрос «что можно сделать, если похищен ключ, или клиенту всё равно, какой ключ у сервера» я лично для себя нахожу всё же интересным, поэтому и ввязался в обсуждение. Строго говоря — да, это не обсуждение SSH как такового.
Имхо, удалённый сервер, да ещё и такой, на котором ты не администратор — заведомо уязвимая сущность, поэтому годится лишь как перевалочный узел для шифрованных данных или как нода для р(о)утинга трафика. В обоих случаях противник ничего концептуального не получит, даже авторизовавшись на сервере под моими кредентиалсами. Максимум, чего он добётся — порушит сетевую инфраструктуру. Я имею в виду анонимное использование SSH-серверов через Tor, купленных у хостинг-провайдеров.
Можно и из консоли: ssh-keygen -R hostname
Интересный improvement: