Возможно ли расшифровать хотя бы часть SSH траффика, имея ключ и сертификат одной стороны?

Мне это не кажется правдоподобным, т.к. до генерации общего ключа K каждая из сторон как минимум должна иметь возможность расшифровать то, что ей прислала другая сторона.

Посмотри видео, оно понятно объясняет как работает алгоритм:
http://www.youtube.com/watch?v=3QnD2c4Xovk

Как вариант-минимум, подойдёт расшифровка одного направления траффика.

Сам трафик (кроме как в момент аутентификации) не шифруется rsa/dsa ключами.
Там используется симметричная криптография, а потому наличие у тебя просто приватного ключа ничего не даст.

путём пассивного подслушивания - нельзя, только активно модифицируя трафик, т.е. человекпосередине

Посмотри видео, оно понятно объясняет как работает алгоритм:

Посмотрел. Не увидел противоречий ни статье в вики, на которую я привёл ссылку, ни опровержения своего мнения из заголовка темы.

Там используется симметричная криптография, а потому наличие у тебя просто приватного ключа ничего не даст.

Для получения симметричного ключа используется свои ключи + ответ собеседника. Как на стороне клиента, так и на стороне сервера. При обмене ключами они, если не ошибаюсь, шифруются как раз ассимметричным алгоритмом. Да пофиг чем, главно что и клиент, и сервер должны иметь возможность из присланных данных должны иметь возможность расшифровать присланную информацию и на основе её и свиох ключей получить , да, симметричный ключ. Но возможность-то есть

Что мне мешает, имея ключи одной из сторон, расшифровать статию генерации ключа сессии, а затем использовать его же?

Или ты хочешь сказать, что для генерации ключа используется что-то ещё, что не передаётся по сети и не входит в ключи сторон? Например, время? Но их есть у меня. Есть время начала сбора дампа и время остановки, есть логи более высокого уровня, которые могут с точностью до 1 секунды сказать, в какой именно момент в дамп попал первый пакет ( и, соответственно, с какого момента отсчитывать относительное время дампа )

Я до сих пор не вижу, в чём заключается принципиальная невозможность расшифровки. Ещё раз, речь идёт не о подмене трафика и не о постороннем, который не имеет наших закрытых ключей. Есть ключи одной из сторон. Есть дамп, собранный на той же самой стороне.

Удалил верхнее сообщение, т.к туплю. Именно «слушать трафик» не имея на руках оба ключа невозможно.
DH все же является уязвимым к MiTM, но сам SSH нет (при наличии у тебя только одного из ключей).
Т.к не имея у себя на руках оба ключа (и сервера и клиента) ты просто не сможешь получить обе части DH даже находять по середине, т.к часть которую клиент шлет серверу зашифрована уже приватным ключиком сервера.
А без подмены прослушка трафика невозможна.

Да какое нафиг подслушивание? Сервер мой, ключи есть, дамп есть. Мне ничего не надо подслушивать, у меня закрытый ключ есть

Да, про расшифровку пароля тоже речь не идёт. Нужна именно расшифровка дампа

только активно модифицируя трафик, т.е. человекпосередине

В этом случае ты сам и будешь выполнять роль клиента, т.к сессионный ключ имея только один их приватных (сервера и клиента) вычислить невозможно.

Т.к не имея у себя на руках оба ключа (и сервера и клиента) ты просто не сможешь получить обе части DH даже находять по середине

Да не по середине я, а участник обмена. И мой ключ используется

, т.к часть которую клиент шлет серверу зашифрована уже приватным ключиком сервера.

ДЛЯ приватного ключа сервера, открытым ключом сервера. И сервер может ещё дешифровать своим закрытым ключом, получив всё что нужно для генерации сессионного симметричного ключа

Удалил верхнее сообщение, т.к туплю. Именно «слушать трафик» не имея на руках оба ключа невозможно.

Зачем мне ДВА ключа, если сессионный ключ одновременно и независимо получается на ОБОИХ сторонах на основании закрытоко ключа стороны и того, что прислал собеседник ( что зашифровано для того же закрытого ключа стороны )?

Что мне мешает, имея ключи одной из сторон, расшифровать статию генерации ключа сессии, а затем использовать его же?

Пишу так, как я понимаю работу ssh.
При инициализации сессии Боб (клиент) шлет серверу свою часть DH зашифрованную публичным ключем сервера.
Алиса (сервер) в ответ отправляет свою часть DH зашифрованную публичным ключем Боба.
Далее они могут обмениваться сообщениями используя общий ключ.

Даже если у тебя есть один из ключей (Боба или Алисы) ты не сможешь получить обе части нужные для генерации сессионного ключа.
А если ты просто подменишь одну из частей, то трафик ты не послушаешь, т.к сессия не будет инициализирована.

Даже если у тебя есть один из ключей (Боба или Алисы) ты не сможешь получить обе части нужные для генерации сессионного ключа.

Вдумайся в то что говоришь. Сессионный ключ - СИММЕТРИЧНЫЙ. Он должен быть у обоих сторон. Каким образом хоть одна из сторон может не знать этого ключа? Он создаётся в процессе обмена, на основании ассиметричной криптографии но результатом является независимое получение сессионного ключа НА ОБОИХ сторонах ( и клиент, и сервер )

Да не по середине я, а участник обмена. И мой ключ используется

Участник обмена это тот у кого и так есть две половинки ключа и который и так видит свои запросы и ответы сервера (или наоборот).
В этом случае для расшифровки трафика тебе надо не только сохранять трафик и иметь свой ключ, но и сохранять своё свою секретную часть используемую при DH во время этой сессии.

Он создаётся в процессе обмена, на основании ассиметричной криптографии

Нет же блин! Ассиметричная криптография используется только для первичного (чтобы нельзя было перехватить DH который уязвим к MiTM) шифрования данных и проверок подписей.
А ключ (в одной из части обмена) генерируется именно с помощью DH.

но результатом является независимое получение сессионного ключа НА ОБОИХ сторонах ( и клиент, и сервер )

Ну да! Только вот тебе мало просто иметь ключ сервера и дамп трафика чтобы получить сессионный ключ.
В дампе трафика ты найдешь нужную для работы DH часть клиента, но не свою.
Т.к твоя часть используемая клиентом для DH в дампе будет зашифрована публичным ключем клиента.

Участник обмена это тот у кого и так есть две половинки ключа

Снова здорово. Сам термин «половинки ключа» относится исключительно к асимментричной криптографии. Открытый и закрый ключ. А алгоритм Диффи-Хеллмана позволяет и помощью ключей сервера и клиента получить ОДИН ОБЩИЙ СИММЕТРИЧНЫЙ ключ. После создания этого ключа асимметричная криптография, как излишне ресурсоёмкая, отступает и используется тот самый ОБЩИЙ ( без никаких половинок ) ключ, который был выработан

О каких ПОЛОВИНКАХ ключа ты говоришь? Об RSA ( DSA ) ключах сервера? В пытый раз повторю, они у меня есть. Это ключ моего сервера, и дамп сессии к моему серверу. О СИММЕТИЧНОМ ключе, который получен в результате работы алгоритма Диффи-Хеллмана? К нему неприменим термин половинка, это симметричный ключ

В дампе трафика ты найдешь нужную для работы DH часть клиента, но не свою.

СВОЯ получается из этой <части клиента> и из своего закрытого ключа. Массаракш.

Имея какой ключ? По идее для расшифровки данных необходимо знать оба публичных ключа и оба секретных. Для расшифровки входящих данных надо знать только секретный ключ сервера, исходящих - клиента.

А, уже про симметричную стадию речь.. Тогда должно быть возможно и полный траффик расшифровать. Вопрос в том, что происходит после обмена данными по DH. Если там передаются какие-то существенные для создания симметричного ключа данные ДО симметричной стадии обмена, то тогда ничего не выйдет. Сервер-то знал, что он зашифровывал на публичном ключе клиента, но эти данные в сыром виде в дампе не присутствуют.

Зависит от того, сколько у тебя времени :D

В случае ассиметричной криптографии. Но она используется ровно до того момента, как будет выработан общий симметричный ключ, после чего трафик шифруется симметричным ключом

Для расшифровки входящих данных надо знать только секретный ключ сервера,

Именно. На этапе генерации симметричного ключа сервер получает трафик, который зашифрован асимметричным алгоритмом, для закрытого ключа сервера. Сервер расшифровывает эти данные, и на основании их и своего же закрытого ключа получает сессионный ключ. Особенность алгоритма Диффи-хелмана как раз в том, что то же самое происходит на стороне клиента. Он точно так же на основании присланных данных, которые он может расшифровать, и своего закрытого ключа получает тот же самый симметричный ключ, который получил и сервер. В дальнейшем этот симметричный ключ используется и сервером, и клиентом для шифрации передаваемых данных, и в результате, имея этот симметричный ключ, можно расшифровать оба направления текущей ssh сессии.

А из дампа всё необходимое для генерации этого симметричного ключа, можно получить имея закрытый ключ одной из сторон.

Почитал бы хоть вики, что ли

Сам термин «половинки ключа» относится исключительно к асимментричной криптографии. Открытый и закрый ключ.

Я не магистр по теме ИБ, но как работает SSH я в принципе понимаю, вот стараюсь на твой вопрос ответить.
Так что извини если у меня плохо с терминологией. :(

О каких ПОЛОВИНКАХ ключа ты говоришь?

Я говорю о наборах данных используемых при работе DH, видео выше кидал.
Оставим работу алгоритма в стороне, но для создания сессионного ключа использую DH нужно грубо говоря три числа:
1 - Одно общее число которое из дампа трафика МОЖНО извлечь.
1 - Одно личное число которое клиент шлет серверу. Если ты имеешь приватный ключ сервера, то ты его из дампа трафика можешь извлечь.
2 - Второе личное число которое сервер шлет клиенту. ВНИМАНИЕ! Ты не можешь его извлечь из дампа трафика, т.к до отправки зашифровал его публичным ключем клиента!

Если одной из частей нет, то ты не можешь повторить процедуру DH и получить сессионный ключ.
Что не понятного?

СВОЯ получается из этой <части клиента> и из своего закрытого ключа. Массаракш.

Ещё раз: если у тебя своя часть (которую ты шлешь клиенту зашифрованную его ключем) есть, то ты МОЖЕШЬ расшифровать трафик.
К приватным ключам это отношения не имеет.

Но тогда непонятно к чему вообще твой вопрос.

Ну вот тут есть одна тонкость: допустим, сервер перед выработкой сессионного симметричного ключа пересылает клиенту случайное число, которое участвует в процессе создания симметричного ключа. Он шифрует его публичным ключом клиента и отправляет. В дампе эти данные уже присутствуют в зашифрованном виде, и не зная секретного ключа клиента, их расшифровать нельзя. Исходное случайное число было только у сервера в памяти, и если он никуда его не записал, то восстановить его и, соответственно, симметричный ключ не удастся.

Щито?

А из дампа всё необходимое для генерации этого симметричного ключа, можно получить имея закрытый ключ одной из сторон.

НЕЛЬЗЯ! Данные по которым клиент генерит сессионный ключ в дампе зашифрованы публичным ключем клиента.

2 - Второе личное число которое сервер шлет клиенту. ВНИМАНИЕ! Ты не можешь его извлечь из дампа трафика, т.к до отправки зашифровал его публичным ключем клиента!

Мне НЕ нужно извлекать это число, поскольку для МЕНЯ оно бесполезно. Оно используется ТОЛЬКО клиентом для получения сессионного ключа.

На стороне сервера я использую

1 - Одно общее число которое из дампа трафика МОЖНО извлечь.
1 - Одно личное число которое клиент шлет серверу. Если ты имеешь приватный ключ сервера, то ты его из дампа трафика можешь извлечь.

плюс свой закрытый ключ, и на выходе имею симметричный ключ К.

Клиент использует

1 - Одно общее число которое из дампа трафика МОЖНО извлечь.
2 - Второе личное число которое сервер шлет клиенту. ВНИМАНИЕ! Ты не можешь его извлечь из дампа трафика, т.к до отправки зашифровал его публичным ключем клиента!

И получает РОВНО ТОТ ЖЕ САМЫЙ симметричный ключ К. Конкретные формулы в вики.

Ни одно из двух чисел

1 - Одно личное число которое клиент шлет серверу. Если ты имеешь приватный ключ сервера, то ты его из дампа трафика можешь извлечь.
2 - Второе личное число которое сервер шлет клиенту. ВНИМАНИЕ! Ты не можешь его извлечь из дампа трафика, т.к до отправки зашифровал его публичным ключем клиента!

Не представляет из себя ценности. Это временные данные. На основании первого числа симметричный ключ получит сервер, на основании второго числа - тот же самый ключ получит клиент.

Надо смотреть не в вики, а в RFC: http://www.openssh.com/txt/rfc4419.txt

Если у тебя есть ключ сессии, то все ок. Но у тебя скорее всего его нет

Ну вот тут есть одна тонкость: допустим, сервер перед выработкой сессионного симметричного ключа пересылает клиенту случайное число, которое участвует в процессе создания симметричного ключа.

Не угадал. Это рандомное число ( точнее, два ) генерит клиент. И шлёт на сервер, зашифровав их асимметричным алгоритмом, и сервер их может расшифровать.

Фатальным роком, о которого никуда не деться, является то, что клиент и сервер в результате обмена по определйнному алгоритму должны получить ОДИН И ТОТ же ключ. В вики формулы.

На стороне сервера я использую
Клиент использует

Нет и ещё раз нет! Посмотри видео про DH ещё раз 10, я серьёзно!
И сервер и клиент используют все три числа, не имея всех трех получить сессионный ключ нельзя.

Не представляет из себя ценности. Это временные данные. На основании первого числа симметричный ключ получит сервер, на основании второго числа - тот же самый ключ получит клиент.

Ещё раз: ты видео что я дал смотрел?

В вики формулы.

Ты явно их не понял. :(

Я не угадывал, я предложил схему, в которой знание полного дампа и всех ключей, кроме секретного клиентского не поможет расшифровать трафик. А значит, надо курить маны. Как в действительности работает SSH, я не знаю.

Короче, попробуй ответить на следующий вопрос: в вики приведены два числа, a и b - большие случайные. b генерится сервером. Откуда из дампа или из ключей ты возьмешь это число, чтобы создать сессионный симметричный ключ?

Это число хранилось только у сервера в оперативной памяти. Если он его никуда не записал, то взять его неоткуда, а следовательно и восстановить симметричный ключ нельзя.

P.S. подзабыл я алгоритм DH, да..

Ты явно их не понял. :(

Перечитал вики ещё раз. Да, был не прав. Для получения сессионного ключа используется не закрытый ключ, а рандомное число, которое затем шифруется и отправляется серверу, о чём ты и говорил.

Хорошо, в принципе на сервере можно включить отладку ( или в крайнем случае пропатчить его ).

Тогда вопрос в следующем: существует ли софт, который на входе примет дамп и необходимые данные, а на выходе выдаст дешифрованный трафик?

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

b генерится сервером.

Да, в этом я и ошибся. Почему-то считал что вместо него берётся закрытый ключ.

Тогда вопрос в следующем: существует ли софт, который на входе примет дамп и необходимые данные, а на выходе выдаст дешифрованный трафик?

Для ssh, на сколько я знаю, нет. Но можно написать )

Если использовался алгоритм именно _шифрования_ ключа (а не выведения общего), и ключ сервера не sign-only, то можно.

Предположим, я пропатчил сервер и в логе получил, например, ключ сессии ( симметричный, который дальше и будет использоваться ). Существует ли ПО, которое примет дамп, сессионный ключ и расшифрует ту часть дампа что сможет?

Готового ПО не подскажу, но его за час можно написать самому. Ну часа 3-4, если не знаком с SSL. Если что, симметричных ключа там два, но выводятся из так называемого мастер-ключа, который известен обеим сторонам.

Wireshark имея приватный ключ и дамп SSL сессии (включая начало - SSL handshake) дешифрует весь галдёж на ура, только на днях проверял. С SSH хз, но думаю там принцип аналогичен.