Информация об изменениях

Сообщение Re[6]: Вопрос про TLS 1.2 (https) от 10.12.2024 9:35

Изменено 10.12.2024 9:42 TailWind

Re[6]: Вопрос про TLS 1.2 (https)
N>1) Вы реализовали TLS, но не понимаете самых основ (судя по соседним письмам)? Почему и как?

Ладно напишу ещё раз суть проблемы и решения более развёрнуто
Там было коротко. Может быть не понятно

Итак обмен зашифрован симметричным шифром
Ключи у нас к нему эфемерные на основе эллиптической кривой
Клиент и Сервер генерируют случайным образом приватные ключи
И отправляют друг другу публичные
Потом каждый вычисляет по ним Мастер ключ

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

Но такой подход уязвим к атаке Man in Middle

Man in Middle прикинется сервером для клиента и клиентом для сервера
Будет расшифровывать ваши данные и потом опять зашифровывать и отправлять серверу и обратно

Чтобы защититься от такой атаки, когда Сервер отправляет свой публичный ключ от эллиптической кривой

Он подписывает его приватным ключом от сертификата:

RSA_Sign(SHA256(client_hello_random + server_hello_random + curve_info + public_key))

(тут public_key это ключ от эллиптической кривой)

Суть в том, что у Man in Middle нет приватного ключа от сертификата
И он не сможет создать соединение с клиентом

То есть он не сможет уловками заставить Сервер подписать ему ключ, который сгенерил Man in Middle

А подпись эту мы уже проверяем открытым ключом из сертификата
А сертификат мы проверяем открытым ключом выдавшей его организации
Re[6]: Вопрос про TLS 1.2 (https)
N>1) Вы реализовали TLS, но не понимаете самых основ (судя по соседним письмам)? Почему и как?

Ладно напишу ещё раз суть проблемы и решения более развёрнуто
Там было коротко. Может быть не понятно

Итак обмен зашифрован симметричным шифром
Ключи у нас к нему эфемерные на основе эллиптической кривой
Клиент и Сервер генерируют случайным образом приватные ключи
И отправляют друг другу публичные
Потом каждый вычисляет по ним Мастер ключ

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

Но такой подход уязвим к атаке Man in Middle

Man in Middle прикинется сервером для клиента и клиентом для сервера
Будет расшифровывать ваши данные и потом опять зашифровывать и отправлять серверу и обратно

Чтобы защититься от такой атаки, когда Сервер отправляет свой публичный ключ от эллиптической кривой

Он подписывает его приватным ключом от сертификата:

RSA_Sign(SHA256(client_hello_random + server_hello_random + curve_info + public_key))

(тут public_key это ключ от эллиптической кривой)

Суть в том, что у Man in Middle нет приватного ключа от сертификата
И он не сможет создать соединение с клиентом

То есть он не сможет уловками заставить Сервер подписать ему ключ, который сгенерил Man in Middle
Потому что сервер каждый раз генерит рандомный ключ от эллиптической кривой)
А записать их все невозможно

А подпись эту мы уже проверяем открытым ключом из сертификата
А сертификат мы проверяем открытым ключом выдавшей его организации