Зачем создавать общий ключ сеанса перед аутентификацией в SSH?

Question

Я хотел понять, как именно работает SSH, и наткнулся на эту статью: https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

Автор пишет, что сессия SSH устанавливается в два этапа:

1. Клиент и сервер устанавливают шифрование для защиты связи
2. Аутентификация клиента

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

6. Клиент объединяет расшифрованный номер с общим ключом сеанса , который используется для шифрования связи, и вычисляет MD5-хэш этого значения.

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

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

Answer 1

Это асимметричные (публичные / частные) операции, которые дороги (чем меньше вы делаете, тем лучше), симметричная криптография дешева. Сначала SSH устанавливает полное симметричное шифрование между клиентом и сервером, а затем начинает обсуждение методов аутентификации.

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

Бонусный аргумент: ваше предложение удешевляет попытки удешевления, на самом деле мы этого не хотим, они должны быть как минимум такими же дорогими, как и успешные.

Answer 2

Нет. Это основной уровень шифрования. Там нет другого слоя.

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

Это не так. Шифрование / дешифрование с открытым ключом никогда не используется для защиты всего трафика по разным причинам (например, значительно более низкая производительность асимметричных алгоритмов по сравнению с симметричным шифрованием или отсутствие прямой секретности, или просто протокол, использующий алгоритмы, подходящие для подписи, но не шифрования).

Вместо этого и SSH, и TLS/SSL используют "гибридную" модель, в которой пары открытого и закрытого ключей используются только для согласования ключа сеанса (или, более часто, просто для обеспечения согласования) и впоследствии вообще не используются.

Кроме того, как сервер будет шифровать данные, если у клиента вообще не будет пары ключей? Помните, что у SSH есть различные методы аутентификации клиента (пользователя), такие как простой пароль, который необходимо каким-то образом зашифровать. (И для сравнения, в целом при использовании TLS/SSL клиент вообще не проходит проверку подлинности.) В идеале процесс аутентификации не должен раскрываться посторонним лицам, которые в настоящее время проходят аутентификацию

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