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

489
Adrian Wydmanski

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

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

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

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

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

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

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

1

2 ответа на вопрос

3
jakub_d

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

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

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

Я думаю, что OP ссылается на процесс обмена ключами (который является асимметричным и, следовательно, дорогим), и спрашивает, почему это не откладывается до окончания аутентификации. grawity 6 лет назад 1
Спасибо за ваш ответ. Не могли бы вы предоставить мне какие-либо источники, объясняющие, почему симметричное шифрование быстрее, чем асимметричное? Adrian Wydmanski 6 лет назад 0
@AdrianWydmanski - если у вас есть машина с Linux, попробуйте openssl speed rsa2048 против openssl speed aes-256-cbc; симметричные aes могут зашифровывать что-то около 40 МБ / с на моей машине, тогда как асимметричная часть может делать только ~ 300 подписей RSA в секунду. jakub_d 6 лет назад 0
Что касается того, почему - это может быть сложным философским вопросом. RSA включает в себя довольно неприятную математику и большие простые числа, в то время как симметричные шифры просто должны составлять достаточно данных из беспорядочной математики. jakub_d 6 лет назад 0
2
grawity

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

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

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

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

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

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

Похожие вопросы