Здравствуйте, TailWind, Вы писали:
TW> Как я могу быть уверен, что общаюсь именно с этим сервером?
TW> Ведь злоумышленник может, так же как я подключится к этому серверу и получить этот сертификат TW> А потом прикинуться сервером и послать его мне
TW> В сертификате же нет ничего, что касается данного соединения
Server Key Exchange Generation:
Because the server and client have agreed to perform key exchange with ephemeral keys, they are not using the public and private keys associated with the server certificate. To prove that the server owns the certificate (giving the certificate validity in this TLS session), it signs the ephemeral public key with the private key associated with the server's certificate. This signature can be validated with the public key included in the server's certificate.
Здравствуйте, 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>https://tls12.xargs.org/
TW>Там на третьем шаге сервер присылает клиенту свой сертификат TW>Если я правильно понял, сертификат подписывает не сервер TW>А для него его подписала та компания, которая ему его выдала, причём один раз TW>То есть он всегда один и тот же
TW>Не понимаю TW>Как я могу быть уверен, что общаюсь именно с этим сервером?
At this point, you may note that anyone could have previously received the server's certificate (or picked it up by eavesdropping) and use it to pose as the server. However, continuing with the TLS handshake, the client uses the public key in the server's certificate to encrypt the randomly created symmetric key for the connection. An imposter could receive this encrypted symmetric key, but would not be able to decrypt it, because only the real server posses the private key needed for the decryption. Therefore, a wannabe imposter, who only somehow obtained the server's certificate, cannot successfully establish a secure connection with the client.
Здравствуйте, TailWind, Вы писали:
TW>Ведь злоумышленник может, так же как я подключится к этому серверу и получить этот сертификат TW>А потом прикинуться сервером и послать его мне
Потому что в сертификате есть открытый ключ, а закрытый ключ от него знает только владелец сертификата. И даже подписавшая сертификат контора этого ключа не знает.
Поэтому в процессе установления соединения клиент посылает серверу какую-нибудь чушь (псевдослучайное число), зашифрованную открытым ключем сертификата, а сервер должен продемонстрировать свою способность эту чушь расшифровать, чтобы клиент мог убедиться, что сервер и взаправду знает закрытый ключ сертификата.
Здравствуйте, TailWind, Вы писали:
TW>Ведь злоумышленник может, так же как я подключится к этому серверу и получить этот сертификат TW>А потом прикинуться сервером и послать его мне
Может. И не злоумышленник может.
Честный прокси, передающий данные побайтово, может.
Но больше ничего не сможет, любое изменение будет замечено.
TW>В сертификате же нет ничего, что касается данного соединения
На это есть ключ сеанса. В современных протоколах он у каждого сеанса свой.
В соединении есть, считаем, три фазы. Детали меняются, но не принципиально:
1. Совсем открытая: сервер присылает свой публичный ключ и сертификаты. Тут клиент принимает данные, но ещё их не проверяет.
2. У сервера все сообщения зашифрованы и подписаны. И вот на этом этапе все сообщения от сервера должны быть проверены:
1) Они расшифрованы публичным ключом и после этого корректны (контрольная сумма сходится, содержимое сообщения корректно).
2) Публичный ключ — тот, что указан в конечном сертификате.
3) Предмет (subject) конечного сертификата соответствует серверу.
4) Корректна цепочка сертификатов от конечного до корневого, с подписями на каждом шаге.
5) Корневой сертификат есть в базе доверенных.
На этом этапе договариваются про сеансовый ключ. Методы могут меняться, но в основном это Diffie-Hellman key exchange (DH KEX). Этот же этап способен сам по себе защитить от replay attack, но могут и дополнительно её организовать раньше.
3. Переключаются на симметричное шифрование с сеансовым ключом и теперь могут передавать как данные сеанса, так и ту аутентификацию, что ходит открытым текстом, как пароли.
И этого достаточно.
(Если авторизуют и клиента по ключу, симметрично, выворачиваем то же для клиента.)
Здравствуйте, 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 менял посылки, то у клиента и сервера расхождения в значении ключа (если оно вообще расшифровалось) и дальнейшие переговоры не пройдут.
Атака не удалась.
Возможны дополнительные навороты в протоколах, но они не меняют этот основной метод.
Здравствуйте, TailWind, Вы писали:
N>>Если MitM ничего не менял в посылках, он знает два значения `g^a mod p` и `g^b mod p`, но не может узнать `g^ab mod p` и поэтому грустно сосёт лапу. N>>Если MitM менял посылки, то у клиента и сервера расхождения в значении ключа (если оно вообще расшифровалось) и дальнейшие переговоры не пройдут.
TW>Всё он понял TW>Ты обратился к MitM он сказал, что он сервер и сгенерировал для тебя ключ шифрования по всем твоим модулям
Если он смог корректно подписать свои сообщения ключом сервера, то он знает приватный ключ и поэтому он и есть сервер.
Если он не смог корректно подписать свои сообщения ключом сервера, то клиент его сообщения не принял и не переключился на симметричное шифрование с ключом.
Так что у него ничего не получилось.
И напоминаю, что в DH KEX нет такого, что сервер или клиент "сгенерировал для тебя ключ шифрования". Ключ создаётся только совместными усилиями.
Здравствуйте, Pzz, Вы писали:
Pzz>Потому что в сертификате есть открытый ключ, а закрытый ключ от него знает только владелец сертификата. И даже подписавшая сертификат контора этого ключа не знает.
Pzz>Поэтому в процессе установления соединения клиент посылает серверу какую-нибудь чушь (псевдослучайное число), зашифрованную открытым ключем сертификата, а сервер должен продемонстрировать свою способность эту чушь расшифровать, чтобы клиент мог убедиться, что сервер и взаправду знает закрытый ключ сертификата.
Так делали в протоколе SSH1. Сейчас так не делают.
DSA, ECDSA и прочие не дают возможности, в отличие от RSA, легко зашифровывать открытым ключом. Можно применить ElGamal для этого, но просто незачем.
Современные схемы базируются только на подписи (то есть сообщение снабжено MAC и зашифровано приватным ключом) посылки от владельца приватного ключа. Получатель расшифровывает публичным ключом и сверяет MAC. При попытке подделки MAC не сойдётся.
Уникальность ключа сеанса гарантируется через DH KEX, на сообщениях, которые подписаны таким образом. Этого достаточно для уникальности ключа и что ключ не известен MitM. Поэтому отдельный шаг защиты от replay attack через посылку случайных данных не обязателен.
Pzz>Поэтому в процессе установления соединения клиент посылает серверу какую-нибудь чушь (псевдослучайное число), зашифрованную открытым ключем сертификата, а сервер должен продемонстрировать свою способность эту чушь расшифровать, чтобы клиент мог убедиться, что сервер и взаправду знает закрытый ключ сертификата.
Это не так работает
Сервер подписывает свой публичный ключ от эпилептической кривой приватным ключом сертификата
Это значит, что man in middle не сможет подписать свой публичный ключ от эпилептической кривой, если захочет общаться с клиентом имитируя сервер
Если бы просто случайные числа подписывали, то атака бы удалась. Так как достаточно транслировать те же числа от клиента настоящему серверу и он их сам подпишет
Здравствуйте, TailWind, Вы писали:
Pzz>>Поэтому в процессе установления соединения клиент посылает серверу какую-нибудь чушь (псевдослучайное число), зашифрованную открытым ключем сертификата, а сервер должен продемонстрировать свою способность эту чушь расшифровать, чтобы клиент мог убедиться, что сервер и взаправду знает закрытый ключ сертификата.
TW>Это не так работает
TW>Сервер подписывает свой публичный ключ от эпилептической кривой приватным ключом сертификата
Эпилептическая кривая — это болезнь такая. Эллиптической, от слова эллипс.
А зачем подписывать свой публичный ключ, если сама по себе возможность подписать что-то приватным из того же комплекта демонстрирует факт владения этим приватным ключом?
TW>Это значит, что man in middle не сможет подписать свой публичный ключ от эпилептической кривой, если захочет общаться с клиентом имитируя сервер
Там не могут быть каждый раз одни и те же данные (например, публичный ключ). Иначе вся эта конструкция становится уязвимой к reply attack.
TW>Если бы просто случайные числа подписывали, то атака бы удалась. Так как достаточно транслировать те же числа от клиента настоящему серверу и он их сам подпишет
Оно случайное, но всегда одна сторона его придумывает, другая — подписывает. Тем самым гарантируется изменчивость подписанных данных.
Здравствуйте, Pzz, Вы писали:
N>>По-моему, гарантия достаточна. N>>Присылаете запрос с указанием номера PSK. Если расшифровано и подпись сошлась — принимается. Иначе — нет, назад идёт "неее, устанавливаем заново". N>>То, что я говорил выше, это увеличивает количество таких перезапусков при ложных коллизиях, но не даёт чтение чужих данных или их успешную подделку.
Pzz>Но ты ведь понимаешь, что это должны знать и делать те гаврики, которые на JS скрипты пишут для вебовских страничек какого-нибудь условного банка?
Как раз это должен делать, скорее всего, встроенный http клиент браузера. Именно ему держать пул истории соединений и пытаться переюзать существующие договорённости.
Не будут же писать TLS прямо на JS...
Там на третьем шаге сервер присылает клиенту свой сертификат
Если я правильно понял, сертификат подписывает не сервер
А для него его подписала та компания, которая ему его выдала, причём один раз
То есть он всегда один и тот же
Не понимаю
Как я могу быть уверен, что общаюсь именно с этим сервером?
Ведь злоумышленник может, так же как я подключится к этому серверу и получить этот сертификат
А потом прикинуться сервером и послать его мне
В сертификате же нет ничего, что касается данного соединения
Because the server and client have agreed to perform key exchange with ephemeral keys, they are not using the public and private keys associated with the server certificate. To prove that the server owns the certificate (giving the certificate validity in this TLS session), it signs the ephemeral public key with the private key associated with the server's certificate. This signature can be validated with the public key included in the server's certificate.
По-моему не прозевал, т.к. на страничке по твоей ссылке я этого текста не нахожу.
(а комментатор ссылку на источник не приводит)
Замечу следующее: по твоей ссылке описывается Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) вариант, отличный от RSA key exchange, тем что для формирования shared key, используются не приватный ключ от серверного сертификата, а временная пара ключей, разная для каждого сеанса. Это обеспечивает forward secrecy: даже если злоумышленник получит доступ к приватному ключу сервера, то не сможет расшифровать ранее перехваченный трафик.
signed_params: A hash of the params, with the signature
appropriate to that hash applied. The private key corresponding
to the certified public key in the server's Certificate message is
used for signing.
Pzz>Оно случайное, но всегда одна сторона его придумывает, другая — подписывает. Тем самым гарантируется изменчивость подписанных данных.
Клиент придумал случайное число
Отправил его Man in Middle
Man in Middle отправил это число серверу
Сервер подписал его приватным ключом сертификата и отправил Man in Middle
Man in Middle отправил его клиенту
Клиент проверил подпись публичным ключом сертификата
Здравствуйте, TailWind, Вы писали:
TW>Это не так работает TW>Сервер подписывает свой публичный ключ от эпилептической кривой приватным ключом сертификата
То есть типа публичный ключ подписан этим же публичным ключом? )
Это так не делают.
Я написал рядом, как делают. Публичный ключ передаётся просто открыто. Подтверждение идёт по тому, что сообщения от сервера передаются подписанными приватным ключом, и этого достаточно на данном этапе.
TW>Это значит, что man in middle не сможет подписать свой публичный ключ от эпилептической кривой, если захочет общаться с клиентом имитируя сервер
Про термин уже сказали рядом
Он не сможет подписать, да. Но не сам ключ, а сообщения сервера.
TW>Если бы просто случайные числа подписывали, то атака бы удалась. Так как достаточно транслировать те же числа от клиента настоящему серверу и он их сам подпишет
Я не буду вчитываться, как в какой именно версии TLS тут делают. Именно эта часть менялась недавно.
Но универсальный метод — использовать какую-то MAC. Подделать её нереально. Она может быть и внутри зашифрованных данных, и снаружи. Есть тонкие различия, какой метод в каком случае имеет проблемы, но для общего понимания этого достаточно.
Вы, кажется, пытаетесь вчитываться в детали, не поняв принципа. Надо начать с принципа.
TW>>Это не так работает TW>>Сервер подписывает свой публичный ключ от эпилептической кривой приватным ключом сертификата
N>То есть типа публичный ключ подписан этим же публичным ключом? )
N>Это так не делают.
Я только что реализовал весь механизм TLS на практике
Лучше прочитайте что я пишу
N>Если MitM ничего не менял в посылках, он знает два значения `g^a mod p` и `g^b mod p`, но не может узнать `g^ab mod p` и поэтому грустно сосёт лапу. N>Если MitM менял посылки, то у клиента и сервера расхождения в значении ключа (если оно вообще расшифровалось) и дальнейшие переговоры не пройдут.
Всё он понял
Ты обратился к MitM он сказал, что он сервер и сгенерировал для тебя ключ шифрования по всем твоим модулям
Потом обратился к серверу, как будто это ты и сгенерировал для него все твои модули
Теперь получает данные от клиента расшифровывает, зашифровывает своим ключом и отправляет на сервер
N>Возможны дополнительные навороты в протоколах, но они не меняют этот основной метод.
Это не суть метода
И это вообще не то как защищён TLS от MitM
Здравствуйте, 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 так можно делать, а выдавать команду на перевод денежек я бы не стал
Здравствуйте, Pzz, Вы писали:
N>>PSK этот это запомненный из прошлого состояния соответствующей сессии, если я правильно понял. Но по идее должно этого хватить...
Pzz>Вот мне тоже было как-то непонятно, как можно обеспечить полноценную секурность без предшевствующего контекста и без возможности обменяться случайными числами.
Там контекст как раз передаётся: в ClientHello идёт номер сессии.
Только дальше вопрос, как сервер должен идентифицировать, с кем именно этот номер сессии сравнивать. Например, если по клиентскому IP, то что будет, когда за NAT сидят 100500 клиентов и этих номеров сессий тупо не хватит?
Там целый RFC (5077) под это сделан, но там 16 бит на номер сессии (в 8446 повторено в самом RFC). А тут, мне кажется, меньше 64 (а то и 128) недостаточно.
Pzz>Интересно, а разработчики веб-приложений вообще в курсе, что первая порция данных от клиента уходит с пониженными гарантиями?
По-моему, гарантия достаточна.
Присылаете запрос с указанием номера PSK. Если расшифровано и подпись сошлась — принимается. Иначе — нет, назад идёт "неее, устанавливаем заново".
То, что я говорил выше, это увеличивает количество таких перезапусков при ложных коллизиях, но не даёт чтение чужих данных или их успешную подделку.
Здравствуйте, netch80, Вы писали:
N>По-моему, гарантия достаточна. N>Присылаете запрос с указанием номера PSK. Если расшифровано и подпись сошлась — принимается. Иначе — нет, назад идёт "неее, устанавливаем заново". N>То, что я говорил выше, это увеличивает количество таких перезапусков при ложных коллизиях, но не даёт чтение чужих данных или их успешную подделку.
Но ты ведь понимаешь, что это должны знать и делать те гаврики, которые на JS скрипты пишут для вебовских страничек какого-нибудь условного банка?
Здравствуйте, netch80, Вы писали:
Pzz>>Но ты ведь понимаешь, что это должны знать и делать те гаврики, которые на JS скрипты пишут для вебовских страничек какого-нибудь условного банка?
N>Как раз это должен делать, скорее всего, встроенный http клиент браузера. Именно ему держать пул истории соединений и пытаться переюзать существующие договорённости. N>Не будут же писать TLS прямо на JS...
Он не знает, для какого запроса какие гарантии нужны.
Если это переложить на него, ну он просто будет при открытии нового соединения посылать на всякий случай preflight запрос. Получим 0-RTT TLS и лишний HTTP-ный RTT к нему в довесок
Здравствуйте, Pzz, Вы писали:
Pzz>>>Но ты ведь понимаешь, что это должны знать и делать те гаврики, которые на JS скрипты пишут для вебовских страничек какого-нибудь условного банка? N>>Как раз это должен делать, скорее всего, встроенный http клиент браузера. Именно ему держать пул истории соединений и пытаться переюзать существующие договорённости. N>>Не будут же писать TLS прямо на JS... Pzz>Он не знает, для какого запроса какие гарантии нужны.
Смотрим кэш завершённых соединений, отфильтрованный по ремоту (host+port), выбираем некоторое, скорее всего, самое последнее (для надёжности восстановления). Для соединения записано, каким идентификатором сессии оно было обозначено, такой и посылаем.
Это чисто теоретически, конечно — какие тут грабли, я не в курсе.
)
