Почему SSH не использует протокол блокировки?

Question

Кажется, что SSH дизайнеры очень заботились о человеке в середине атаки.

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

На практике я обнаружил, что многие пользователи просто игнорируют предупреждения о несоответствующих отпечатках пальцев и предполагают, что это связано с переустановкой сервера. Просто MITM-атака настолько сложна и редка, что вы никогда не беспокоитесь об этом. Более того, много раз пользователь хочет использовать ssh на разных компьютерах, и он не стал бы импортировать все отпечатки пальцев на любой компьютер, который мог бы использовать SSH с (эй, вы можете посмотреть, почему мой сайт не работает, я в панике! Я не в офисе, я заскочу в ближайшее интернет-кафе и посмотрю).

Чтобы быть справедливым, можно использовать DNSSEC и использовать DNS серверы как CA, Однако я никогда не видел, чтобы это использовалось на практике. И вообще, это не обязательная часть протокола.

Много лет я думал, что нельзя избежать MITM без общего секрета, но недавно я читал превосходную "Практическую криптографию" Брюса Шнейра, там он упоминает протокол блокировки.

1. Алиса посылает Бобу свой открытый ключ.
2. Боб посылает Алисе свой открытый ключ.
3. Алиса зашифровывает свое сообщение, используя открытый ключ Боба. Она отправляет половину зашифрованного сообщения Бобу.
4. Боб шифрует свое сообщение, используя открытый ключ Алисы. Он отправляет половину зашифрованного сообщения Алисе.
5. Алиса отправляет вторую половину своего зашифрованного сообщения Бобу.
6. Боб складывает две половины сообщения Алисы и расшифровывает его своим закрытым ключом. Боб отправляет вторую половину своего зашифрованного сообщения Алисе.
7. Алиса соединяет две половины сообщения Боба и расшифровывает его своим закрытым ключом.

Теперь Мэллори должна что-то отправить Бобу на шаге (3) протокола после того, как он получит половину сообщения Алисы, даже если он не сможет расшифровать его, пока не получит все от Алисы в (5). Он должен сфабриковать сообщение для Боба, и Боб, вероятно, заметит, что он фабрикует, скажем, после того, как он ls его домашний каталог.

Почему не SSH использовать такую ​​схему? Кажется, это действительно соответствует его целям. Это не требует никакой другой сущности, и это делает атаки MITM существенно более сложными.

Это что-то присуще? Недостаток в моем понимании проблемы? Или просто дизайнер подумал, что дополнительная безопасность не стоит усложнять протокол?

PS: Если вы думаете, что это вызовет слишком много накладных расходов, вы можете заставить пользователей протокола использовать блокировку только для первого 10K данных в связи, поэтому на практике это не будет иметь большого значения, но MITM будет сложнее, тем не менее.

Обновление: Атака по протоколу блокировки, описанная здесь, не означает, что атака MITM возможна, это означает, что если во время обмена данными будет отправлен один пароль, MITM сможет его перехватить, и пользователь увидит только ошибку времени ожидания.

Обновление 2: точка Евгения, рейз действительна. Протокол блокировки не позволяет аутентификацию. То есть вы все еще не можете быть уверены, что если вы подключаетесь к example.com, Это точно example.com, и не malicious.com выдает себя за example.com, Вы не можете знать это наверняка без, скажем, DNSSEC, Так, например, если вы SSHВ бункер ракет и напиши launch_missile -time now (без, скажем, использования ls чтобы убедиться, что сервер действительно является сервером в хранилищах ракет), возможно, вы действительно написали это на вредоносном сервере, и теперь враг знает, что вы собираетесь запустить против него ракеты. Этот тип атаки действительно не будет предотвращен протоколом блокировки.

Однако, если я правильно понимаю протокол, гораздо более опасная атака и очень практичная атака могут быть предотвращены. Если используется протокол блокировки, даже если вы ничего не знаете о example.comНельзя, чтобы ты SSH на ваш сервер, и кто-то подслушивает весь SSH сессия. Я думаю, что этот тип атаки гораздо более вероятен.

Может быть SSH не волнует атака MITM? Я думаю, что нет, см. Например Putty FAQ:

Эти раздражающие подсказки ключа хоста - вот и весь смысл SSH. Без них вся криптографическая технология, используемая SSH для защиты вашего сеанса, не делает ничего, кроме как усложнение работы злоумышленника; вместо того, чтобы сидеть между вами и сервером с перехватчиком пакетов, злоумышленник должен фактически подорвать маршрутизатор и начать модифицировать пакеты, возвращаясь назад и вперед. Но это не намного сложнее, чем просто нюхать; и без проверки ключа хоста он будет полностью не обнаружен клиентом или сервером.

Он явно говорит о MITM-атаке, а не о проверке подлинности сервера. Я думаю, что использование протокола блокировки явно предотвратит атаку, упомянутую в FAQ по замазке, и я до сих пор не понимаю, почему они его не использовали.

Answer 1

Я не вижу, как протокол блокировки предотвращает MITM.

Проблема не в том, как обменяться ключами, а в том, как им доверять. Вы правильно указываете, что люди игнорируют предупреждения о том, что ключи не совпадают. Это действительно самый большой недостаток, но протокол, который вы описываете, не решает проблему проверки происхождения ключа. SSL использует сертификаты X.509 и PKI для проверки доверия. SSH также может использовать сертификаты, но почти никакое программное обеспечение SSH не поддерживает их.