id: Гость   вход   регистрация
текущее время 11:09 28/03/2024
Автор темы: Гость, тема открыта 16/04/2013 06:23 Печать
Категории: право, политика
https://www.pgpru.com/Форум/Криптография/АутентификацияВSSHV2
создать
просмотр
ссылки

Аутентификация в SSH v.2


Ээ чё? В SSH v2 аутентификация с ключами разве не взаимная? Если сервер не знает открытого ключа клиента, то клиент разве не должен разорвать соединение?


 
На страницу: 1, 2, 3, 4 След.
Комментарии
— Гость (17/04/2013 20:36)   <#>

Сами-то смотрели? 24-часовой таймаут не смущает?
Интересно, как обстоят дела с регенерацией симметричных ключей в SSH-сессии...
— Гость (17/04/2013 20:54)   <#>
https://www.pgpru.com/comment63281
Я не про Вашу ссылку, запрятанную в ебенях форума, я про что-то, что видно сразу по заходу на сайт.

Компрометации закрытого ключа клиента нет. Читать научитесь, чтоли.

И действительно, научитесь. Я вроде бы обьяснил, что у меня другой сценарий.

Вы хоть что-то по теме написать можете, или только балаболить в состоянии?
— Гость (17/04/2013 22:29)   <#>

Вам шашечки или ехать? Ссылка дана на мнение модератора ресурса, благодаря вкладу которого этот ресурс вообще существует в том виде, к какому все уже давно привыкли и воспринимают, как само собой разумеющееся. Есть /proekt, из него тоже негласно это следует, но уточнять не решили. Не то, чтоб здесь запрещено обсуждение чего-то иного, просто иное мало кому интересно. На тему принуждения к соблюдению ИБ в государственных и коммерческих компаниях есть другие интернет-ресурсы с другой публикой.


Лично я отвечал Гостю (17/04/2013 00:07), ссылка была дана им.


Если вам прошлого раза мало, и выводы не сделаны, ваши глубокие мысли по теме могут проредить ещё раз. И, наконец, потрудитесь вставлять ссылки не кишками, а как положено в wiki.
— Гость (17/04/2013 23:26)   <#>
Ахаха, так это таки ты. Вали, дорогой, ты все равно нихера не знаешь, только время на тебя просирать. Все с тобой понятно, и уже давно.
— _ТС_ (17/04/2013 23:32)   <#>
Гость (17/04/2013 00:07) это я и есть, ака топикстартер, дубинушка. Лучше бы имя ТС освободили.
— Гость (18/04/2013 19:18)   <#>
https://www.pgpru.com/comment63277
Интересно, можно подробности? Или это через DNSSEC, который появится лет через 15?

По делу писать пробовали?
— Гость (18/04/2013 22:23)   <#>

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


Зачем так толсто? Если не видите связи аутентификации с имперсонацией (а равно и со следствиями при краже ключа) — это должно быть поводом подумать, а не потроллить.
— Гость (19/04/2013 05:31)   <#>
Не надо мне давать поводы и на что-то намекать. Я дал ссылку на то, что, похоже, SSH сосет у митма даже при аутентификации по ключам, хотя возможности защититься есть. Кто хочет аргументированно обсудить (аргументированно – это с аргументами) – давайте.
— Гость (20/04/2013 00:12)   <#>
Есть кто живой из тех, кто шарит?
— Гость (20/04/2013 19:36)   <#>

Прежде, чем делать громкие заявления, вопрос:

По ссылке
Ээ чё? В SSH v2 аутентификация с ключами разве не взаимная?

Чёрным по белому написано

3. сервер (имея этот ключ) отсылает некий челендж клиенту.

Вопрос 1: «Этот ключ» — это какой? Напоминаю, что сервер имеет
  1. Приватный свой ключ.
  2. Публичный свой ключ.
  3. Публичный клиентский ключ (приватный клиентский хранится только у клиента).

Вопрос 2: Откуда у сервера-митмера возьмётся этот ключ?
— Гость (20/04/2013 20:25)   <#>
Не читайте то, читайте это. Там написано, что c RSA вместо DH митм возможен.
— Гость (20/04/2013 20:28)   <#>
Для тех, кто считает, что RSA – это днище, везде есть DH, напомню о downgrade. Т.е. небезопасные протоколы должны быть отключены как минимум на одном конце.
— Гость (20/04/2013 22:54)   <#>

Отвечаю на ссылку здесь, вы мне орёте, что надо читать пост на хабре. Читаю пост на хабре — опять даёте ссылку stackexchange. Может, вы-таки определитесь со своим вопросом?

Про пост со stackexchange я уже написал. Могу повторить ещё раз:

DH:
So, in effect, if the attacker has the server's key she can pretend being the server (to the client). She would have to accept the public key login, and show the client some shell or similar.

RSA:
MiTM-attack (knowing the server's transient private key) is feasible

Итак, снова возвращаюсь к своему вопросу 2:
Откуда у сервера-митмера возьмётся этот ключ?
Соответственно, в случае RSA, откуда у него возьмётся «transient private key»? Для незнающих, что это, даю ссылку.
— Гость (21/04/2013 05:10)   <#>
Гость (20/04/2013 22:54), я уже не помню, где кто на что отвечал, плюс нету ников и мало кто ставит ссылки на посты, на которые отвечают (на имиджбордах и то так делают). Ставь ссылку на свой пост и скажи спасибо своим соседям по форуму, нафлудившими 3 страницы.

Похоже, я экстраполировал ответ на crypto.se на другую ситуацию


The RSA key-exchange method consists of three messages. The server
sends to the client an RSA public key, K_T, to which the server holds
the private key. This may be a transient key generated solely for
this SSH connection, or it may be re-used for several connections.
The client generates a string of random bytes, K, encrypts it using
K_T, and sends the result back to the server, which decrypts it. The
client and server each hash K, K_T, and the various key-exchange
parameters to generate the exchange hash, H, which is used to
generate the encryption keys for the session, and the server signs H
with its host key and sends the signature to the client. The client
then verifies the host key as described in Section 8 of [RFC4253].


Т.е.



Если бы в него не входил открытый ключ сервера, то все бы прошло. Отсос пока отменяется.

Однако, все-таки проблемы в алгоритме ssh есть – при знании секретного ключа сервера и RSA аутентификации митм возможен, хотя этого можно было бы избежать. Раздельные установление шифрованого канала и аутентификация по ключам с точки зрения криптографии – бред.
— Гость (21/04/2013 07:30)   <#>

Наверно, я отвечал. И мои «соседи» — тоже я. Полный список моих постов в этой ветке (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 — клиент-серверный, в самом этом определении заложено неравенство, поэтому клиент доказывает свою идентичность и аутентифицируется перед сервером, прежде всего, а не наоборот.

Восстаналиваю логику этого треда:
  1. Вы постите сюда ссылку на пост на хабр (ужас, SSH сломан, все умрём).
  2. SATtva и др. ещё на первой странице треда пишут, что это курам на смех. Уязвимость, которая требует кражи ключа или безалаберного отношения клиента — не узявимость.
  3. Вы говорите про случаи многих серверов, когда неизвестны отпечатки и пр. Типа, незнание серверного ключа — это нормальное положение дел, и протокол должен работать даже в этом случае (я лично с этим не согласен). Более того, вы приводите в аргумент, что сервер знает публичный ключ клиента, а митмер нет (дескать, на это можно было бы завязаться в протоколе).
  4. Я отвечаю, что
    1. Если митмер украл серверный приватный ключ, он может украть и клиентский публичный — они оба лежат на одном и том же компе. Концептуального отличия нет. Поэтому уловки с надеждой, что, дескать, настоящий-то сервер должен знать и проверить публичный ключ для случая кражи не работают.
    2. В случае, когда клиент забыл отпечаток сервера это остаётся, извините, проблемой клиента: крипто — не магическая палочка. Если одна сторона не знает достоверных данных о другой априори, установить аутентифицированное и шифрованное соединение невозможно.
  5. Я примерно понял, что вы предлагаете. Типа, пусть клиент не знает отпечатка сервера, но сервер имеет публичный ключ клиента (считаем, что кражи ключа сервера не было). Тогда клиент должен требовать с сервера знания своего публичного ключа. Митмер подсовывает, дескать, левый ключ, но клиент просит доказать владение своим публичным. А поскольку последнего у митмера нет, митм-атака обламывается. В этом примерно состоит ваша логика, как я понял. Если чисто как по мне, то это смотрится предельно криво: грубо нарушить все основные требования протокола, а потом надеяться на костыль, который якобы должен чем-то «помочь».

5-ый пункт проще всего объяснить в терминах PGP. Чтобы было в точности параллельно ситуации с SSH, предположим, что для каждого собеседника каждый использует уникальную ключевую пару «публичный/приватный ключ». Дальше первый из собеседников теряет ключ второго. Второй при этом якобы может доказать свою идентичность владением публичным ключом первого. Что-то в этом разумное есть, конечно. Можно формализовать это, как требование раскрыть информацию, которая ранее была известна только между этими сторонами и никогда не передавалась третьей стороне. Случай кражи, впрочем, тут вообще не защищается: раз атакующий может похитить приватный ключ второго собеседника, он может у него же похитить и публичный ключ для первого.


В /comment50979 была дана ссылка (заметьте, это ещё 2006-ой год). Для собственных целей не пользовался, подробностей сказать не могу. Была попытка обсуждать это на форуме.
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3