Аутентификация в SSH v.2
Ээ чё? В SSH v2 аутентификация с ключами разве не взаимная? Если сервер не знает открытого ключа клиента, то клиент разве не должен разорвать соединение?
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
Нормы пользования. Некоторые права на материалы сайта защищены по условиям лицензии CreativeCommons. Движок
openSpace 0.8.25a и дизайн сайта © 2006-2007 Vlad "SATtva" Miller.
|
||||||||||||||||||||||||
Сами-то смотрели? 24-часовой таймаут не смущает?
Интересно, как обстоят дела с регенерацией симметричных ключей в SSH-сессии...
Я не про Вашу ссылку, запрятанную в ебенях форума, я про что-то, что видно сразу по заходу на сайт.
И действительно, научитесь. Я вроде бы обьяснил, что у меня другой сценарий.
Вы хоть что-то по теме написать можете, или только балаболить в состоянии?
Вам шашечки или ехать? Ссылка дана на мнение модератора ресурса, благодаря вкладу которого этот ресурс вообще существует в том виде, к какому все уже давно привыкли и воспринимают, как само собой разумеющееся. Есть /proekt, из него тоже негласно это следует, но уточнять не решили. Не то, чтоб здесь запрещено обсуждение чего-то иного, просто иное мало кому интересно. На тему принуждения к соблюдению ИБ в государственных и коммерческих компаниях есть другие интернет-ресурсы с другой публикой.
Лично я отвечал Гостю (17/04/2013 00:07), ссылка была дана им.
Если вам прошлого раза мало, и выводы не сделаны, ваши глубокие мысли по теме могут проредить ещё раз. И, наконец, потрудитесь вставлять ссылки не кишками, а как положено в wiki.
Интересно, можно подробности? Или это через DNSSEC, который появится лет через 15?
По делу писать пробовали?
Нет, я уже сдристнул. Если с вами кто-то ещё из читателей хочет покидаться говном, пусть для вас ищет ссылки и описывает подробности, с меня хватит.
Зачем так толсто? Если не видите связи аутентификации с имперсонацией (а равно и со следствиями при краже ключа) — это должно быть поводом подумать, а не потроллить.
Прежде, чем делать громкие заявления, вопрос:
По ссылке
Чёрным по белому написано
Вопрос 1: «Этот ключ» — это какой? Напоминаю, что сервер имеет
Вопрос 2: Откуда у сервера-митмера возьмётся этот ключ?
Отвечаю на ссылку здесь, вы мне орёте, что надо читать пост на хабре. Читаю пост на хабре — опять даёте ссылку stackexchange. Может, вы-таки определитесь со своим вопросом?
Про пост со stackexchange я уже написал. Могу повторить ещё раз:
DH:
RSA:
Итак, снова возвращаюсь к своему вопросу 2:
Соответственно, в случае RSA, откуда у него возьмётся «transient private key»? Для незнающих, что это, даю ссылку.
Похоже, я экстраполировал ответ на crypto.se на другую ситуацию
Т.е.
Если бы в него не входил открытый ключ сервера, то все бы прошло. Отсос пока отменяется.
Однако, все-таки проблемы в алгоритме ssh есть – при знании секретного ключа сервера и RSA аутентификации митм возможен, хотя этого можно было бы избежать. Раздельные установление шифрованого канала и аутентификация по ключам с точки зрения криптографии – бред.
Наверно, я отвечал. И мои «соседи» — тоже я. Полный список моих постов в этой ветке (17/04/2013 00:05), (17/04/2013 17:41), (17/04/2013 20:15), (17/04/2013 20:36), (17/04/2013 22:29), (18/04/2013 22:23), (20/04/2013 19:36), (20/04/2013 22:54). Остальные гостевые посты — не мои.
Разве проблема митмеру узнать публичный ключ сервера? Если он инициирует соединение с сервером, сервер ему свой ключ предложит, поэтому митмер его узнает. Или я что-то не понимаю?
Ясно, что MITM в нормальном SSH в документированном его использовании невозможен. Протокол писали не дураки, и если бы сейчас вскрылась возможность MITM'а, это был бы ор на весь интернет ещё похлеще, чем с Debian OpenSSL.
Что касается SSH в недокументированном его использовании, тут может быть всё, что угодно. Я усредно вас подвожу к вопросу, откуда ключи у митмера, но вы молчите. Придётся воспользоваться хрустальными шарами. Итак, первый вариант — кража, второй вариант — клиенту пофиг на отпечаток сервера, он всегда жмёт YES (с функциональной точки зрения этот случай идентичен первому). В частности, именно второй вариант был предложен на хабре. Первый выше предложил я (см. мои посты). Как бы там ни было, кража ключа выводится за рамки угрозы всегда, это ключевой момент. Спекулировать о том, что можно сделать, украв ключ (или если жертве всё равно, какой ключ), можно, но уязвимостью самого протокола это не считается.
Протокол SSH — клиент-серверный, в самом этом определении заложено неравенство, поэтому клиент доказывает свою идентичность и аутентифицируется перед сервером, прежде всего, а не наоборот.
Восстаналиваю логику этого треда:
5-ый пункт проще всего объяснить в терминах PGP. Чтобы было в точности параллельно ситуации с SSH, предположим, что для каждого собеседника каждый использует уникальную ключевую пару «публичный/приватный ключ». Дальше первый из собеседников теряет ключ второго. Второй при этом якобы может доказать свою идентичность владением публичным ключом первого. Что-то в этом разумное есть, конечно. Можно формализовать это, как требование раскрыть информацию, которая ранее была известна только между этими сторонами и никогда не передавалась третьей стороне. Случай кражи, впрочем, тут вообще не защищается: раз атакующий может похитить приватный ключ второго собеседника, он может у него же похитить и публичный ключ для первого.
В /comment50979 была дана ссылка (заметьте, это ещё 2006-ой год). Для собственных целей не пользовался, подробностей сказать не могу. Была попытка обсуждать это на форуме.