SSL открытых и закрытых ключей

Question

Пожалуйста, помогите мне заполнить пробелы здесь -

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

2. Для связи ssl требуется открытый и закрытый ключ. Эта пара ключей генерируется с использованием самоподписанного сертификата?. Как один самостоятельный сертификат может содержать как открытый, так и закрытый ключи.

Еще одна вещь, на безопасность на уровне сообщений - им смотреть на текущую конфигурацию, и я потянув меня за волосы - Использование IBM Ikeyman смотреть на производителя и потребителя JKS files-- для обеспечения безопасности на уровне сообщений (Digital Signing) есть личный сертификат у Потребителя и сертификат подписчика у Продюсера ... Разве это не так? Не соответствует ли эта конфигурация текущей конфигурации. Оба ключа одинаковы.

Answer 1

1. Сервер сохраняет свой закрытый ключ и открытый ключ разделяется для пользователей.

Исправить.

Таким образом, клиент доверяет содержимому, поступающему с сервера с использованием открытого ключа.

Нет. «Об этом нет». Клиент доверяет серверу сертификат, потому что он подписан кем-то, которому он доверяет, и он знает, что он принадлежит серверу, потому что сервер предоставляет цифровую подпись, которую клиент может проверить, что может сделать только владелец частного ключа. Поэтому он знает, что сервер принадлежит этому открытому ключу.

Как клиент шифрует содержимое, которое он отправляет обратно на сервер?

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

Использование открытого ключа сервера? или клиент отправляет автогенерированный закрытый ключ и шифрует его с помощью открытого ключа, который затем дешифруется сервером вместе с сообщением и используется для более полной связи обеими сторонами.

Ничего, см. Выше. Это довольно большой предмет.

1. Общественный и личный ключ требуется сделать Ssl связи.

No. Один из сторон должна иметь закрытый ключ и соответствующий сертификат о том, что другая сторона доверяет, в противном случае сообщение является небезопасным.

Эта пара ключей генерируются с использованием самоподписанного сертификатом

No. Заявлением даже не имеет смысла. Сначала создаются пары ключей, но ничего общего с сертификатами. Сертификат является оберткой для открытого ключа.

Как отдельный самоподписанный сертификат содержит как открытый, так и закрытый ключи.

Не может, и это не так. Самоподписывание тоже не имеет к этому отношения.

Answer 2

открытого ключа шифрования 101:

Государственные и частные ключи образуют пару: каждый ключ в паре можно расшифровать сообщения, зашифрованные с другой стороны, но не может расшифровать сообщения, зашифрованные с самим собой. Если клиент может расшифровать сообщение открытым ключом, он знает, что сообщение было зашифровано владельцем открытого ключа. И наоборот, сообщение, зашифрованное открытым ключом, может быть дешифровано только владельцем закрытого ключа.

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

Answer 3

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

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

Но использование открытого ключа и частного ключа в связи с ssl может значительно замедлить соединение, поскольку длина этих ключей составляет 1024 или 2048 бит.

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