TLS человек в средних сертификатах безопасности

Question

Прежде всего, я приношу свои извинения за отправку еще одного вопроса об этом наблюдении, поскольку есть так много связанных должностей. Прочитав их и связанные с ними сайты, я по-прежнему не понял несколько моментов.

1. браузер подключается к серверу через защищенный сокет
2. Сервер отвечает с помощью открытого ключа с его сертификатом. Это тот самый шаг, с которым я столкнулся. В этом сообщении от сервера к клиенту можно легко отделить сертификат от открытого ключа сервера? Если это корневой сертификат (тот, который уже включен в браузер), то человек в середине не может подделать его, но что, если это не так? Не может ли этот онлайн-механизм, используемый клиентом для проверки сертификата, захвачен? Кроме того, если компьютер клиента взломан, корневые ЦС могут быть скомпрометированы, правильно? Любые шаги, которые этого избежать? Последнее: сказано, что сертификат не защищен до подписания. Я не могу понять, что это значит, тем более что сертификат может подписать сам. Я думаю, что это должно означать, что кто-то уверен в достоверности сообщения, поэтому сам сертификат подписывается небезопасным («Являетесь ли вы РЕАЛЬНЫМ сертификатом?» ... «Уммм, конечно, конечно, я»). Если механизм аутентификации сертификата - это интернет, мне интересно, как это безопасно. Подписывает ли сертификат то же, что и вещь (буквально), так как клиент проверяет сертификат?
3. Ключ сеанса шифруется открытым ключом и отправляется на сервер. Этот ключ сеанса является симметричным ключом, который оба сервера и клиент будут использовать для остатка зашифрованной связи.

Должен сказать, что большая часть информации в Интернете настолько расплывчата. Так много отверстий в объяснениях и ручных волнах. Мое предположение заключается в том, что очень немногие люди очень хорошо знают реальные механизмы?

Answer 1

Вы оставили несколько шагов. Один из них заключается в том, что сервер отправляет цифровую подпись по всему рукопожатию до сих пор, подписанный своим личным ключом. Только сервер может сделать это со своим собственным сертификатом. Никто другой. Клиент проверяет цифровую подпись, используя открытый ключ в отправленном сертификате. Это доказывает, что сервер владеет сертификатом. Это также доказывает, что сервер - это тот же объект, который отправил все другие сообщения подтверждения.

BTW Ваш шаг 3 является мнимым. Ключ сеанса никогда не отправляется вообще. Он вычисляется независимо с обоих концов.

EDIT Комментарии Ваш ответ:

сервера (от JoesGoods) получает сертификат от ЦС через?

Обычно через интернет-браузер.

Может ли это быть угнано?

Не более, чем любая другая безопасная сессия SSL.

Сертификат "подписан"

Correct.

, что означает, что бит зашифрован с использованием закрытого ключа CA.

Нет. Вы сделали это.

В частности, бит, который имеет данные веб-сервера (сервер информации JoesGoods')

No. Вы сделали, что до.

Подписанный сертификат подписан, и это не означает «зашифрованный» с закрытым ключом CA.

Браузер Боба подключается к серверу через защищенный сокет и отправляет пакет «привет».

Розетка в данный момент не защищена. Это просто текст.

Сервер отправляет свой открытый ключ и сертификат Бобу.

Нет. Сервер отправляет свой сертификат. Открытый ключ уже находится в сертификате.

браузер проверяет, что веб-сервер (JoesGoods) соответствует тому, что находится в подписанной части сертификата

подписывается весь сертификат. Клиент проверяет, что сервер, к которому он подключается, соответствует объектуDN сертификата.

открытый ключ Веб-сервер является также подписал с СА личный ключ

Потому что в сертификате. В противном случае другого пути это не может быть сделано. Вот почему он не отправляется отдельно, и поэтому весь сертификат подписан, а не только нужные вам биты.

Браузер отправляет пакет обмена ключами клиента на веб-сервер (JoesGoods) с использованием открытого ключа веб-сервера, включенного в этап (2).

Эта часть зависит от шифрования. То, что вы описали, относится к наборам шифрования RSA. Диффи-Хеллман - другая история, и есть возможность для расширения, чтобы включить других.

Этот ключ клиента используется для создания симметричных ключей для проведения остальной части обмена. Этот ключ клиента называется «секрет премьера» и является случайным ключом. Поскольку симметричные ключи создаются с использованием этого ключа, мне интересно, почему бы просто не отправить сам симметричный ключ, поскольку соединение зашифровано и проверено на этом этапе.

Потому что это будет не так безопасно.

У вас также есть некоторые из этих шагов не по порядку.

Я действительно не вижу смысла перечислять все эти шаги неофициально, когда они уже полностью указаны в RFC 2246. Существует достаточно дезинформации о TLS, плавающих вокруг Интернета, например, this piece of unmaintained drivel.