Здравствуйте, TailWind, Вы писали:
Pzz>>Оно случайное, но всегда одна сторона его придумывает, другая — подписывает. Тем самым гарантируется изменчивость подписанных данных.
TW>Клиент придумал случайное число TW>Отправил его Man in Middle TW>Man in Middle отправил это число серверу TW>Сервер подписал его приватным ключом сертификата и отправил Man in Middle TW>Man in Middle отправил его клиенту TW>Клиент проверил подпись публичным ключом сертификата
TW>Атака удалась
Заметим, что сетевой провайдер делает в точности то, что в твоем рассказе делает Man in the Middle. Передаёт данные туда-сюда.
Если Мужику Посерёдке охота поработать гуртовщиким пакетов, флаг ему в руки.
Там еще попутно сессионные ключи выводятся, и начиная с некоторого момента траффик идет зашифрованным. Мужик Посерёдке из твоего рассказа вправе передавать пакеты, но у него не получится их подменить. Поэтому сессионные ключи останутся для него неизвестными.
Здравствуйте, TailWind, Вы писали:
TW>Я только что реализовал весь механизм TLS на практике TW>Лучше прочитайте что я пишу
Хм, у меня тут два вопроса
1) Вы реализовали TLS, но не понимаете самых основ (судя по соседним письмам)? Почему и как?
2) Нафига 1.2 (судя по заголовку темы), когда сейчас уже владельцы веб-сайтов массово пишут в конфигах "ниже 1.3 не принимаем"?
Здравствуйте, netch80, Вы писали:
N>2) Нафига 1.2 (судя по заголовку темы), когда сейчас уже владельцы веб-сайтов массово пишут в конфигах "ниже 1.3 не принимаем"?
Слушай, а я правильно понимаю, что в 0-RTT TLS 1.3 первая порция данных от клиента (HTTP GET чего-то там) идет практически не зашифрованной?
N>1) Вы реализовали TLS, но не понимаете самых основ (судя по соседним письмам)? Почему и как?
Мне надоело с вами спорить
Вы говорите общими фразами не передавая суть проблемы и решения
N>2) Нафига 1.2 (судя по заголовку темы), когда сейчас уже владельцы веб-сайтов массово пишут в конфигах "ниже 1.3 не принимаем"?
Для изучения криптографии
Если посмотрите 1.3, то там одни костыли на костылях
Каждое сообщение начинается с фразы: все коробки в интернете привыкли к 1.2, поэтому мы тут сейчас обернём все сообщения в обёртки, и будем делать вид что мы 1.2, а внутри у нас будет завёрнут 1.3
1.2 нормально структурирован и рекомендую начинать изучения именно с него
Хотя конечно и достаточно сложно. Были не очевидные моменты
Я раз 10 бросал со словами — да ну вас с вашим утюгом! )
N>1) Вы реализовали TLS, но не понимаете самых основ (судя по соседним письмам)? Почему и как?
Ладно напишу ещё раз суть проблемы и решения более развёрнуто
Там было коротко. Может быть не понятно
Итак обмен зашифрован симметричным шифром
Ключи у нас к нему эфемерные на основе эллиптической кривой
Клиент и Сервер генерируют случайным образом приватные ключи
И отправляют друг другу публичные
Потом каждый вычисляет по ним Мастер ключ
Это даёт нам классную особенность, что у нас соединение каждый раз зашифровано новым ключом. Взломав одно, не узнаешь что было в другом. Просто подслушав нельзя выяснить ключ шифрования
Но такой подход уязвим к атаке Man in Middle
Man in Middle прикинется сервером для клиента и клиентом для сервера
Будет расшифровывать ваши данные и потом опять зашифровывать и отправлять серверу и обратно
Чтобы защититься от такой атаки, когда Сервер отправляет свой публичный ключ от эллиптической кривой он подписывает его приватным ключом от сертификата:
(тут public_key это ключ от эллиптической кривой Сервера)
Суть в том, что у Man in Middle нет приватного ключа от сертификата
И он не сможет создать соединение с клиентом
То есть он не сможет уловками заставить Сервер подписать ему публичный ключ от эллиптической кривой, который сгенерил Man in Middle для клиента
Потому что сервер каждый раз генерит рандомный ключ от эллиптической кривой)
А записать их все невозможно
А подпись эту мы уже проверяем открытым ключом из сертификата
А сертификат мы проверяем открытым ключом выдавшей его организации
Здравствуйте, TailWind, Вы писали:
N>>Если он смог корректно подписать свои сообщения ключом сервера, то он знает приватный ключ и поэтому он и есть сервер.
TW>Какой конкретно ключ вы имеете в виду? TW>Там их несколько
TW>Если от эллиптической кривой, то это не поможет
struct {
select (KeyExchangeAlgorithm) {
case dh_anon:
ServerDHParams params;
case dhe_dss:
case dhe_rsa:
ServerDHParams params;
digitally-signed struct {
opaque client_random[32];
opaque server_random[32];
ServerDHParams params;
} signed_params;
case rsa:
case dh_dss:
case dh_rsa:
struct {} ;
/* message is omitted for rsa, dh_dss, and dh_rsa */
/* may be extended, e.g., for ECDH -- see [TLSECC] */
} ServerKeyExchange;
signed_params передаётся подписанным. А чем именно оно подписано?
Как раз приватным ключом, который указан в конечном сертификате.
Здравствуйте, TailWind, Вы писали:
N>>signed_params передаётся подписанным. А чем именно оно подписано? N>>Как раз публичным ключом, который указан в конечном сертификате.
TW>Вот, теперь почти правильно
TW>Приватным ключом, который не указан в конечном сертификате, а не публичным
TW>Если бы публичным мог бы каждый подписать
Я чуть поспешил и скомкал фразу. Приватным ключом, таким, что соответствующий ему публичный указан в сертификате. По-моему, это очевидно, но если вы хотите уточнения, вот вам оно.
TW>А проверяют уже публичным
Ну тогда я в упор не понимаю, где вы видите проблему, если сами сразу же об этом сказали. И повторю то, что уже говорил:
1) Клиенту уже передали на этот момент (RFC5246 строки 1970-1971, если совсем уточнять), как себя идентифицирует сервер — цепочкой сертификатов. Там указан публичный ключ, который подписан этой цепочкой.
2) Клиент расшифровывает (подтверждает подпись в этом digitally-signed struct, если совсем точно) ключ в сообщении ServerKeyExchange, пользуясь этим публичным ключом. Так как никто больше кроме сервера не знает приватный ключ и не может соответственно подписать, то присылка ключа является в этом сообщении аутентичной.
3) С помощью DH KEX вырабатывается общий ключ (master secret в терминах RFC), на основании знаний, которые есть у обеих сторон, но отсутствуют (и не могут быть вычислены) MitM.
N>Ну тогда я в упор не понимаю, где вы видите проблему, если сами сразу же об этом сказали. И повторю то, что уже говорил:
Я видел проблему, пока юзер rudzuk не подсказал мне что там есть подпись, которую я упустил из вида
Это было в первых нескольких постах
И тогда я понял, как классно всё придумано в TLS
Для меня тема была закрыта
Потом пришли вы с Pzz и начали писать общими словами, возможно не понимая сути проблемы, которая возникает без этой подписи
Как всегда в интернете кто-то не прав
И я втянулся в объяснения ))
Здравствуйте, 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>А сертификат мы проверяем открытым ключом выдавшей его организации
Здравствуйте, TailWind, Вы писали:
N>>Ну тогда я в упор не понимаю, где вы видите проблему, если сами сразу же об этом сказали. И повторю то, что уже говорил:
TW>Я видел проблему, пока юзер rudzuk не подсказал мне что там есть подпись, которую я упустил из вида TW>Это было в первых нескольких постах TW>И тогда я понял, как классно всё придумано в TLS TW>Для меня тема была закрыта
TW>Потом пришли вы с Pzz и начали писать общими словами, возможно не понимая сути проблемы, которая возникает без этой подписи
Я как раз понимал проблему изначально, и об этом писал.
Это вы пишете про какой-то ещё один промежуточный одноразовый "эллиптический" ключ, которого там нет и которого может в принципе не быть, если используется не ECDSA.
TW>Как всегда в интернете кто-то не прав TW>И я втянулся в объяснения ))
OK. Для меня тема закрыта, хотя просто освежил память. Вы же пересмотрите, правильно ли вы поняли, что именно реализовали
UPD: "как классно всё придумано"... — TLS ужасен по причине легаси со времён первого SSL. Жаль, нельзя с нуля всё перепроектировать. Но он таки работает.
N>1. Клиентская сторона генерирует ключ и посылает серверу, пользуясь тем, что может легко зашифровывать публичным ключом сервера (том, который в сертификате сервера). Это случай, например, key exchange type (KET) = RSA (не путать с PKI алгоритмом RSA).
Вы опять шифруете публичным ключом
Нет клиент ничего не шифрует
Генерирует случайным образом свой private key для эллиптической кривой
Рассчитывает из него свой public key
И ничего не шифруя и не подписывая отправляет его серверу
Всё в открытую идёт
Сервер генерирует случайным образом свой private key
Рассчитывает из него свой public key
И ничего не шифруя, но подписывая его приватным ключом, который пара к публичному, указанному в сертификате сервера отправляет его клиенту
Потом оба считают Мастер Key, и из него все остальные ключи
Может вы изучали старые стандарты SSL?
Или иной протокол обмена ключами?
Я вам описываю как работает Cipher_Suites = TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA;
Здравствуйте, netch80, Вы писали:
n> Я как раз понимал проблему изначально, и об этом писал. n> Это вы пишете про какой-то ещё один промежуточный одноразовый "эллиптический" ключ, которого там нет и которого может в принципе не быть, если используется не ECDSA.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, netch80, Вы писали:
N>>2) Нафига 1.2 (судя по заголовку темы), когда сейчас уже владельцы веб-сайтов массово пишут в конфигах "ниже 1.3 не принимаем"?
Pzz>Слушай, а я правильно понимаю, что в 0-RTT TLS 1.3 первая порция данных от клиента (HTTP GET чего-то там) идет практически не зашифрованной?
Ну так тупо бы они не облажались. В RFC прямо сказано
IMPORTANT NOTE: The security properties for 0-RTT data are weaker
than those for other kinds of TLS data. Specifically:
1. This data is not forward secret, as it is encrypted solely under
keys derived using the offered PSK.
2. There are no guarantees of non-replay between connections.
Protection against replay for ordinary TLS 1.3 1-RTT data is
provided via the server's Random value, but 0-RTT data does not
depend on the ServerHello and therefore has weaker guarantees.
This is especially relevant if the data is authenticated either
with TLS client authentication or inside the application
protocol. The same warnings apply to any use of the
early_exporter_master_secret.
PSK этот это запомненный из прошлого состояния соответствующей сессии, если я правильно понял. Но по идее должно этого хватить...
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, netch80, Вы писали:
n>> Я как раз понимал проблему изначально, и об этом писал. n>> Это вы пишете про какой-то ещё один промежуточный одноразовый "эллиптический" ключ, которого там нет и которого может в принципе не быть, если используется не ECDSA.
R>Про эфемерный ключ он говорит. Который в описываемой схеме присутствует. Невыделенную часть цитаты читайте: http://rsdn.org/forum/network/8864950.1
Так, я понял. Коллега TailWind смешал несколько разных режимов в одно определение.
Есть static DH — которое непонятно кому нужно такое. В 1.3 его запретили, и IMHO это правильно и надо было сделать сто лет назад.
Есть DHE (с ephemeral key), которое ХЗ почему так зовётся, это и есть нормальный DH, когда параметры для ключей генерируются на ходу. Для forward secrecy этого уже достаточно.
А есть ECDH и ECDHE, которые наконец ещё и усложнёны элементами EC. Вот тут точно требуется глубокое понимание, чтобы объяснить, чем они уже так лучше.
Здравствуйте, netch80, Вы писали:
N>PSK этот это запомненный из прошлого состояния соответствующей сессии, если я правильно понял. Но по идее должно этого хватить...
Вот мне тоже было как-то непонятно, как можно обеспечить полноценную секурность без предшевствующего контекста и без возможности обменяться случайными числами.
Интересно, а разработчики веб-приложений вообще в курсе, что первая порция данных от клиента уходит с пониженными гарантиями?
Какой-нибудь GET /pictures/icon.jpg так можно делать, а выдавать команду на перевод денежек я бы не стал
