Кажется, что SSH дизайнеры очень заботились о человеке в средней атаке.
Их подход состоял в том, чтобы сохранить отпечаток пальца открытого ключа сервера при первом подключении к серверу (и надеяться, что пользователь не подключится из зараженной сети в первый раз, например, если у него есть вирус в компьютере). Затем пользователь использует отпечаток пальца для проверки открытого ключа сервера при следующем подключении к этому серверу.
На практике я обнаружил, что многие пользователи просто игнорируют предупреждения о несоответствующих отпечатках пальцев и предполагают, что это связано с переустановкой сервера. Просто MITM-атака настолько сложна и редка, что вы никогда не беспокоитесь об этом. Более того, много раз пользователь хочет использовать ssh на разных компьютерах, и он не стал бы импортировать все отпечатки пальцев на любой компьютер, с которым он может захотеть использовать SSH (эй, вы можете посмотреть, почему мой сайт не работает, я Я в панике! Я не в офисе, я заскочу в ближайшее интернет-кафе и посмотрю).
Чтобы быть справедливым, можно использовать DNSSEC и использовать DNS серверы в качестве CA. Однако я никогда не видел, чтобы это использовалось на практике. И вообще, это не обязательная часть протокола.
Много лет я думал, что нельзя избежать MITM без общего секрета, но я недавно читал превосходную «Практическую криптографию» Брюса Шнейра, там он упоминает протокол блокировки .
- Алиса посылает Бобу свой открытый ключ.
- Боб посылает Алисе свой открытый ключ.
- Алиса шифрует свое сообщение, используя открытый ключ Боба. Она отправляет половину зашифрованного сообщения Бобу.
- Боб шифрует свое сообщение, используя открытый ключ Алисы. Он отправляет половину зашифрованного сообщения Алисе.
- Алиса отправляет вторую половину своего зашифрованного сообщения Бобу.
- Боб складывает две половины сообщения Алисы и расшифровывает его своим закрытым ключом. Боб отправляет Алисе вторую половину своего зашифрованного сообщения.
- Алиса складывает две половины сообщения Боба и расшифровывает его своим закрытым ключом.
Теперь, Мэллори должен отправить что-то Бобу на шаге (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?Я думаю, что нет, смотрите, например, Часто задаваемые вопросы по замазке :
Эти раздражающие подсказки ключа хоста - весь смысл SSH.Без них все криптографические технологии, которые SSH использует для защиты вашего сеанса, не делают ничего, кроме как усложняют работу злоумышленника;вместо того, чтобы сидеть между вами и сервером с перехватчиком пакетов, злоумышленник должен фактически подорвать маршрутизатор и начать модифицировать пакеты, возвращаясь назад и вперед.Но это не намного сложнее, чем просто нюхать;и без проверки ключа хоста он не будет полностью обнаружен клиентом или сервером.
Он явно говорит об атаке MITM, а не об аутентификации сервера.Я думаю, что использование протокола блокировки явно предотвратит атаку, упомянутую в FAQ по замазке, и я до сих пор не понимаю, почему они его не использовали.