Здравствуйте, TailWind, Вы писали:

Pzz>>Оно случайное, но всегда одна сторона его придумывает, другая — подписывает. Тем самым гарантируется изменчивость подписанных данных.

TW>Клиент придумал случайное число
TW>Отправил его Man in Middle
TW>Man in Middle отправил это число серверу
TW>Сервер подписал его приватным ключом сертификата и отправил Man in Middle
TW>Man in Middle отправил его клиенту
TW>Клиент проверил подпись публичным ключом сертификата

TW>Атака удалась

Клиент и сервер начали DH KEX и договорились про значение `g`=base и `p`=modulus, а также про тип и режим симметричного шифра по завершению.
Клиент выбрал свой `a` и отправил в сторону сервера `g^a mod p`, открытым текстом без защиты.
Сервер выбрал свой `b` и отправил в сторону клиента `g^b mod p`, зашифрованно своим приватным ключом и подписанно.
(Заметим тут, что `a` и `b` случайные, что защищает от replay attack.)
Сервер прочитал посылку от клиента и сформировал `g^ab mod p`.
Клиент прочитал посылку от сервера, проверил её по всем параметрам (расшифровка выполнилась, сообщение валидно, сумма сошлась, ключ есть в сертификате, цепочка сертификатов верна и доверенна) и сформировал `g^ab mod p`.
Клиент и сервер одновременно переключились на договоренный шифр с ключами, и обмениваются сообщениями, которые зашифрованы данным ключом и, кроме того, подписаны какой-то MAC (чтобы не было, что успешно расшифровалось, но чушь).
Клиент доверяет серверу, данному сеансу, и может посылать ему следующие секреты типа пароля для входа.
Сервер ещё не доверяет клиенту, если клиент симметрично не аутентифицировал себя сертификатом, но доверяет данному сеансу и может принимать по нему следующий шаг аутентификации (пароли и т.п.)

Если MitM ничего не менял в посылках, он знает два значения `g^a mod p` и `g^b mod p`, но не может узнать `g^ab mod p` и поэтому грустно сосёт лапу.
Если MitM менял посылки, то у клиента и сервера расхождения в значении ключа (если оно вообще расшифровалось) и дальнейшие переговоры не пройдут.

Атака не удалась.

Возможны дополнительные навороты в протоколах, но они не меняют этот основной метод.

Здравствуйте, TailWind, Вы писали:

Pzz>>Оно случайное, но всегда одна сторона его придумывает, другая — подписывает. Тем самым гарантируется изменчивость подписанных данных.

TW>Клиент придумал случайное число
TW>Отправил его Man in Middle
TW>Man in Middle отправил это число серверу
TW>Сервер подписал его приватным ключом сертификата и отправил Man in Middle
TW>Man in Middle отправил его клиенту
TW>Клиент проверил подпись публичным ключом сертификата

TW>Атака удалась

Клиент и сервер начали DH KEX и договорились про значение `g`=base и `p`=modulus, а также про тип и режим симметричного шифра по завершению.
Клиент выбрал свой `a` и отправил в сторону сервера `g^a mod p`, открытым текстом без защиты.
Сервер выбрал свой `b` и отправил в сторону клиента `g^b mod p`, зашифрованно своим приватным ключом и подписанно.
(Заметим тут, что `a` и `b` случайные, что защищает от replay attack. UPD: в терминах спецификации TLS это называется ephemeral keys, соответственно, алгоритмы имеют в названии аббревиатуру DHE.)
Сервер прочитал посылку от клиента и сформировал `g^ab mod p`.
Клиент прочитал посылку от сервера, проверил её по всем параметрам (расшифровка выполнилась, сообщение валидно, сумма сошлась, ключ есть в сертификате, цепочка сертификатов верна и доверенна) и сформировал `g^ab mod p`.
Клиент и сервер одновременно переключились на договоренный шифр с ключами, и обмениваются сообщениями, которые зашифрованы данным ключом и, кроме того, подписаны какой-то MAC (чтобы не было, что успешно расшифровалось, но чушь).
Клиент доверяет серверу, данному сеансу, и может посылать ему следующие секреты типа пароля для входа.
Сервер ещё не доверяет клиенту, если клиент симметрично не аутентифицировал себя сертификатом, но доверяет данному сеансу и может принимать по нему следующий шаг аутентификации (пароли и т.п.)

Если MitM ничего не менял в посылках, он знает два значения `g^a mod p` и `g^b mod p`, но не может узнать `g^ab mod p` и поэтому грустно сосёт лапу.
Если MitM менял посылки, то у клиента и сервера расхождения в значении ключа (если оно вообще расшифровалось) и дальнейшие переговоры не пройдут.

Атака не удалась.

Возможны дополнительные навороты в протоколах, но они не меняют этот основной метод.