Там на третьем шаге сервер присылает клиенту свой сертификат
Если я правильно понял, сертификат подписывает не сервер
А для него его подписала та компания, которая ему его выдала, причём один раз
То есть он всегда один и тот же
Не понимаю
Как я могу быть уверен, что общаюсь именно с этим сервером?
Ведь злоумышленник может, так же как я подключится к этому серверу и получить этот сертификат
А потом прикинуться сервером и послать его мне
В сертификате же нет ничего, что касается данного соединения
Здравствуйте, 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, Вы писали:
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.
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.
Здравствуйте, TailWind, Вы писали:
TW>Ведь злоумышленник может, так же как я подключится к этому серверу и получить этот сертификат TW>А потом прикинуться сервером и послать его мне
Потому что в сертификате есть открытый ключ, а закрытый ключ от него знает только владелец сертификата. И даже подписавшая сертификат контора этого ключа не знает.
Поэтому в процессе установления соединения клиент посылает серверу какую-нибудь чушь (псевдослучайное число), зашифрованную открытым ключем сертификата, а сервер должен продемонстрировать свою способность эту чушь расшифровать, чтобы клиент мог убедиться, что сервер и взаправду знает закрытый ключ сертификата.
Pzz>Поэтому в процессе установления соединения клиент посылает серверу какую-нибудь чушь (псевдослучайное число), зашифрованную открытым ключем сертификата, а сервер должен продемонстрировать свою способность эту чушь расшифровать, чтобы клиент мог убедиться, что сервер и взаправду знает закрытый ключ сертификата.
Это не так работает
Сервер подписывает свой публичный ключ от эпилептической кривой приватным ключом сертификата
Это значит, что man in middle не сможет подписать свой публичный ключ от эпилептической кривой, если захочет общаться с клиентом имитируя сервер
Если бы просто случайные числа подписывали, то атака бы удалась. Так как достаточно транслировать те же числа от клиента настоящему серверу и он их сам подпишет
Здравствуйте, TailWind, Вы писали:
Pzz>>Поэтому в процессе установления соединения клиент посылает серверу какую-нибудь чушь (псевдослучайное число), зашифрованную открытым ключем сертификата, а сервер должен продемонстрировать свою способность эту чушь расшифровать, чтобы клиент мог убедиться, что сервер и взаправду знает закрытый ключ сертификата.
TW>Это не так работает
TW>Сервер подписывает свой публичный ключ от эпилептической кривой приватным ключом сертификата
Эпилептическая кривая — это болезнь такая. Эллиптической, от слова эллипс.
А зачем подписывать свой публичный ключ, если сама по себе возможность подписать что-то приватным из того же комплекта демонстрирует факт владения этим приватным ключом?
TW>Это значит, что man in middle не сможет подписать свой публичный ключ от эпилептической кривой, если захочет общаться с клиентом имитируя сервер
Там не могут быть каждый раз одни и те же данные (например, публичный ключ). Иначе вся эта конструкция становится уязвимой к reply attack.
TW>Если бы просто случайные числа подписывали, то атака бы удалась. Так как достаточно транслировать те же числа от клиента настоящему серверу и он их сам подпишет
Оно случайное, но всегда одна сторона его придумывает, другая — подписывает. Тем самым гарантируется изменчивость подписанных данных.
Здравствуйте, TailWind, Вы писали:
TW>Ведь злоумышленник может, так же как я подключится к этому серверу и получить этот сертификат TW>А потом прикинуться сервером и послать его мне
Может. И не злоумышленник может.
Честный прокси, передающий данные побайтово, может.
Но больше ничего не сможет, любое изменение будет замечено.
TW>В сертификате же нет ничего, что касается данного соединения
На это есть ключ сеанса. В современных протоколах он у каждого сеанса свой.
В соединении есть, считаем, три фазы. Детали меняются, но не принципиально:
1. Совсем открытая: сервер присылает свой публичный ключ и сертификаты. Тут клиент принимает данные, но ещё их не проверяет.
2. У сервера все сообщения зашифрованы и подписаны. И вот на этом этапе все сообщения от сервера должны быть проверены:
1) Они расшифрованы публичным ключом и после этого корректны (контрольная сумма сходится, содержимое сообщения корректно).
2) Публичный ключ — тот, что указан в конечном сертификате.
3) Предмет (subject) конечного сертификата соответствует серверу.
4) Корректна цепочка сертификатов от конечного до корневого, с подписями на каждом шаге.
5) Корневой сертификат есть в базе доверенных.
На этом этапе договариваются про сеансовый ключ. Методы могут меняться, но в основном это Diffie-Hellman key exchange (DH KEX). Этот же этап способен сам по себе защитить от replay attack, но могут и дополнительно её организовать раньше.
3. Переключаются на симметричное шифрование с сеансовым ключом и теперь могут передавать как данные сеанса, так и ту аутентификацию, что ходит открытым текстом, как пароли.
И этого достаточно.
(Если авторизуют и клиента по ключу, симметрично, выворачиваем то же для клиента.)
Pzz>Оно случайное, но всегда одна сторона его придумывает, другая — подписывает. Тем самым гарантируется изменчивость подписанных данных.
Клиент придумал случайное число
Отправил его Man in Middle
Man in Middle отправил это число серверу
Сервер подписал его приватным ключом сертификата и отправил Man in Middle
Man in Middle отправил его клиенту
Клиент проверил подпись публичным ключом сертификата
Здравствуйте, Pzz, Вы писали:
Pzz>Потому что в сертификате есть открытый ключ, а закрытый ключ от него знает только владелец сертификата. И даже подписавшая сертификат контора этого ключа не знает.
Pzz>Поэтому в процессе установления соединения клиент посылает серверу какую-нибудь чушь (псевдослучайное число), зашифрованную открытым ключем сертификата, а сервер должен продемонстрировать свою способность эту чушь расшифровать, чтобы клиент мог убедиться, что сервер и взаправду знает закрытый ключ сертификата.
Так делали в протоколе SSH1. Сейчас так не делают.
DSA, ECDSA и прочие не дают возможности, в отличие от RSA, легко зашифровывать открытым ключом. Можно применить ElGamal для этого, но просто незачем.
Современные схемы базируются только на подписи (то есть сообщение снабжено MAC и зашифровано приватным ключом) посылки от владельца приватного ключа. Получатель расшифровывает публичным ключом и сверяет MAC. При попытке подделки MAC не сойдётся.
Уникальность ключа сеанса гарантируется через DH KEX, на сообщениях, которые подписаны таким образом. Этого достаточно для уникальности ключа и что ключ не известен MitM. Поэтому отдельный шаг защиты от replay attack через посылку случайных данных не обязателен.
Здравствуйте, TailWind, Вы писали:
TW>Это не так работает TW>Сервер подписывает свой публичный ключ от эпилептической кривой приватным ключом сертификата
То есть типа публичный ключ подписан этим же публичным ключом? )
Это так не делают.
Я написал рядом, как делают. Публичный ключ передаётся просто открыто. Подтверждение идёт по тому, что сообщения от сервера передаются подписанными приватным ключом, и этого достаточно на данном этапе.
TW>Это значит, что man in middle не сможет подписать свой публичный ключ от эпилептической кривой, если захочет общаться с клиентом имитируя сервер
Про термин уже сказали рядом
Он не сможет подписать, да. Но не сам ключ, а сообщения сервера.
TW>Если бы просто случайные числа подписывали, то атака бы удалась. Так как достаточно транслировать те же числа от клиента настоящему серверу и он их сам подпишет
Я не буду вчитываться, как в какой именно версии TLS тут делают. Именно эта часть менялась недавно.
Но универсальный метод — использовать какую-то MAC. Подделать её нереально. Она может быть и внутри зашифрованных данных, и снаружи. Есть тонкие различия, какой метод в каком случае имеет проблемы, но для общего понимания этого достаточно.
Вы, кажется, пытаетесь вчитываться в детали, не поняв принципа. Надо начать с принципа.
TW>>Это не так работает TW>>Сервер подписывает свой публичный ключ от эпилептической кривой приватным ключом сертификата
N>То есть типа публичный ключ подписан этим же публичным ключом? )
N>Это так не делают.
Я только что реализовал весь механизм TLS на практике
Лучше прочитайте что я пишу
Здравствуйте, 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 менял посылки, то у клиента и сервера расхождения в значении ключа (если оно вообще расшифровалось) и дальнейшие переговоры не пройдут.
Атака не удалась.
Возможны дополнительные навороты в протоколах, но они не меняют этот основной метод.
N>Если MitM ничего не менял в посылках, он знает два значения `g^a mod p` и `g^b mod p`, но не может узнать `g^ab mod p` и поэтому грустно сосёт лапу. N>Если MitM менял посылки, то у клиента и сервера расхождения в значении ключа (если оно вообще расшифровалось) и дальнейшие переговоры не пройдут.
Всё он понял
Ты обратился к MitM он сказал, что он сервер и сгенерировал для тебя ключ шифрования по всем твоим модулям
Потом обратился к серверу, как будто это ты и сгенерировал для него все твои модули
Теперь получает данные от клиента расшифровывает, зашифровывает своим ключом и отправляет на сервер
N>Возможны дополнительные навороты в протоколах, но они не меняют этот основной метод.
Это не суть метода
И это вообще не то как защищён TLS от MitM
Здравствуйте, TailWind, Вы писали:
N>>Если MitM ничего не менял в посылках, он знает два значения `g^a mod p` и `g^b mod p`, но не может узнать `g^ab mod p` и поэтому грустно сосёт лапу. N>>Если MitM менял посылки, то у клиента и сервера расхождения в значении ключа (если оно вообще расшифровалось) и дальнейшие переговоры не пройдут.
TW>Всё он понял TW>Ты обратился к MitM он сказал, что он сервер и сгенерировал для тебя ключ шифрования по всем твоим модулям
Если он смог корректно подписать свои сообщения ключом сервера, то он знает приватный ключ и поэтому он и есть сервер.
Если он не смог корректно подписать свои сообщения ключом сервера, то клиент его сообщения не принял и не переключился на симметричное шифрование с ключом.
Так что у него ничего не получилось.
И напоминаю, что в DH KEX нет такого, что сервер или клиент "сгенерировал для тебя ключ шифрования". Ключ создаётся только совместными усилиями.
)