Комментарии 2
Судя по описанию EDH, здесь нет «секрета» сервера (постоянного закрытого ключа), который можно было бы украсть и тем самым скомпрометировать переписку.
Значит, этом случае есть уязвимость Man-in-the-Middle, т. к. нет возможности проверить достоверность ключа, предоставленного клиенту.
Правильно ли я понимаю этот механизм?
Значит, этом случае есть уязвимость Man-in-the-Middle, т. к. нет возможности проверить достоверность ключа, предоставленного клиенту.
Правильно ли я понимаю этот механизм?
Сам по себе DH уязвим к MitM. В данном случае EDH используется как один из механизмов образования ключей в SSL/TLS. Последний, как раз-таки и предоставляет аутентификацию (authentication). На финальной стадии рукопожатия SSL/TLS обе стороны обмениваются client finished message & server finished message. Данные сообщения содержат хэш всех сообщений с точки зрения клиента и сервера соответственно. В случае если хэш клиента и сервера не совпадают, соединение обрывается.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Заметки про SSL/TLS: forward, backward secrecy