Здравствуйте, TailWind, Вы писали:
N>>1) Вы реализовали TLS, но не понимаете самых основ (судя по соседним письмам)? Почему и как?
TW>Ладно напишу ещё раз суть проблемы и решения более развёрнуто TW>Там было коротко. Может быть не понятно
TW>Итак обмен зашифрован симметричным шифром TW>Ключи у нас к нему эфемерные на основе эллиптической кривой TW>Клиент и Сервер генерируют случайным образом приватные ключи TW>И отправляют друг другу публичные TW>Потом каждый вычисляет по ним Мастер ключ
Так, вы таки путаете разные механизмы. Нельзя тут обобщать.
См. RFC5246 со строки 2676 (пункт 7.4.2). У нас есть, как видно, два принципиально разных случая:
1. Клиентская сторона генерирует ключ и посылает серверу, пользуясь тем, что может легко зашифровывать публичным ключом сервера (том, который в сертификате сервера). Это случай, например, key exchange type (KET) = RSA (не путать с PKI алгоритмом RSA).
2. Клиентская сторона может только проверять подпись сервера. В этом случае включается DH KEX, на сообщениях ClientKeyExchange и ServerKeyExchange. Дальше математика DH KEX обеспечивает, что MitM не получает итоговый master key, хотя видит весь обмен, которым он генерируется. Для аутентификации достаточно, чтобы хотя бы одна сторона подписывала свои сообщения. Это, как минимум, DHE варианты.
Пока вы не различаете эти два случая, а описываете какой-то общий подход, причём неверно ("генерируют случайным образом приватные ключи" — нет такого; "отправляют друг другу публичные" — в DH KEX нет "публичных ключей") — вы не поймёте происходящее.
Собственно то, что я говорил раньше — всё об этом.
TW>Это даёт нам классную особенность, что у нас соединение каждый раз зашифровано новым ключом. Взломав одно, не узнаешь что было в другом. Просто подслушав нельзя выяснить ключ шифрования
Это уже банально. Вы не учитываете другое.
Если злоумышленник записал сессию и потом узнал откуда-то приватный ключ сервера, то в первом подходе он может её прочитать даже спустя годы — он может прочитать сообщение клиента с ключом. А если применялся DH KEX, то даже в этом случае он это не узнает. Он знает g^a mod p и g^b mod p, записанные в истории, но не может вычислить g^ab mod p.
Именно поэтому DH KEX считается правильным вариантом, а генерация полного ключа клиентом и присылка его серверу зашифрованным — это легаси, от которого надо избавляться.
В протоколе SSH1 это решали тем, что сервер ещё и дополнительно к host key (постоянному) генерировал server key, который по умолчанию жил 1 час и который высылался каждый раз клиенту. Тогда зная запись одной сессии — можно было прочитать её товарку в пределах того же часа. В SSH2 это отменили. В TLS наблюдаем хвосты для совместимости со старыми безобразиями, но я бы их оттуда давно удалил.
TW>Но такой подход уязвим к атаке Man in Middle
Нет, и я описал, почему не уязвим.
Повторяю ещё раз: подпись сервером, на основании своего ключа, удостоверённого сертификатом (цепочкой сертификатов), параметров для DH KEX — позволяет клиенту, после выработки общего ключа, считать, что, если дальнейшее взаимодействие этим ключом будет корректно, то сервер аутентифицирован и никто, кроме сервера, этим ключом не может воспользоваться. MitM не сможет воспроизвести подпись сервера в ServerKeyExchange без знания приватного ключа сервера.
TW>Чтобы защититься от такой атаки, когда Сервер отправляет свой публичный ключ от эллиптической кривой он подписывает его приватным ключом от сертификата:
Да. Именно что подписывает приватным ключом от сертификата для расшифровки тем публичным ключом, который он прислал перед этим.
Я так и говорил. Что теперь не так?
TW>Суть в том, что у Man in Middle нет приватного ключа от сертификата TW>И он не сможет создать соединение с клиентом
Ну.
TW>То есть он не сможет уловками заставить Сервер подписать ему публичный ключ от эллиптической кривой, который сгенерил Man in Middle для клиента TW>Потому что сервер каждый раз генерит рандомный ключ от эллиптической кривой) TW>А записать их все невозможно
Почему вы повторяете "от эллиптической кривой"?
Не циклитесь на ECDSA.
Это работает с любым PKI, где можно зашифровывать приватным ключом и расшифровывать публичным. RSA, DSA, ECDSA, Ed25519 — все это умеют.
Это раз. Второе — что сервер "каждый раз генерит" не "от эллиптической кривой", а для KEX. Тут нет промежуточного ключа для ещё одного уровня PKI (как было в SSH1), он не нужен.
TW>А подпись эту мы уже проверяем открытым ключом из сертификата TW>А сертификат мы проверяем открытым ключом выдавшей его организации
