Сообщение Re[6]: Вопрос про TLS 1.2 (https) от 10.12.2024 9:35
Изменено 10.12.2024 9:45 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
Потому что сервер каждый раз генерит рандомный ключ от эллиптической кривой)
А записать их все невозможно
А подпись эту мы уже проверяем открытым ключом из сертификата
А сертификат мы проверяем открытым ключом выдавшей его организации
Ладно напишу ещё раз суть проблемы и решения более развёрнуто
Там было коротко. Может быть не понятно
Итак обмен зашифрован симметричным шифром
Ключи у нас к нему эфемерные на основе эллиптической кривой
Клиент и Сервер генерируют случайным образом приватные ключи
И отправляют друг другу публичные
Потом каждый вычисляет по ним Мастер ключ
Это даёт нам классную особенность, что у нас соединение каждый раз зашифровано новым ключом. Взломав одно, не узнаешь что было в другом. Просто подслушав нельзя выяснить ключ шифрования
Но такой подход уязвим к атаке 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
Потому что сервер каждый раз генерит рандомный ключ от эллиптической кривой)
А записать их все невозможно
А подпись эту мы уже проверяем открытым ключом из сертификата
А сертификат мы проверяем открытым ключом выдавшей его организации
Ладно напишу ещё раз суть проблемы и решения более развёрнуто
Там было коротко. Может быть не понятно
Итак обмен зашифрован симметричным шифром
Ключи у нас к нему эфемерные на основе эллиптической кривой
Клиент и Сервер генерируют случайным образом приватные ключи
И отправляют друг другу публичные
Потом каждый вычисляет по ним Мастер ключ
Это даёт нам классную особенность, что у нас соединение каждый раз зашифровано новым ключом. Взломав одно, не узнаешь что было в другом. Просто подслушав нельзя выяснить ключ шифрования
Но такой подход уязвим к атаке 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
Потому что сервер каждый раз генерит рандомный ключ от эллиптической кривой)
А записать их все невозможно
А подпись эту мы уже проверяем открытым ключом из сертификата
А сертификат мы проверяем открытым ключом выдавшей его организации