Что-то я не понимаю. Когда я вообще не ставил сертификат, соединение SSL установлено успешно, мне интересно, как сервер расшифровывает сообщение без сертификата клиента.SSL работает без сертификата клиента
Что такое сертификат на стороне клиента?
Благодаря
Think о сертификате не с точки зрения шифрования-дешифрования, но с точки зрения аутентификация. Шифрование может выполняться без сертификатов вообще - достаточно знать открытый ключ. Но сертификат содержит разные поля, среди которых личность владельца сертификата. Для Интернета это значение является доменным именем сервера, к которому вы хотите подключиться.Поскольку есть средства для проверки того, что IP-адрес сервера всегда равен имени, указанному в сертификате (запросы вперед и назад DNS), вы можете быть уверены, что разговариваете с тем, который хотите.
В этих условиях проблема с сертификатом клиента должна быть намного проще для понимания. Сертификат клиента позволяет серверу аутентифицировать клиента, поэтому аутентификация будет взаимной. Сервер может проверить, например, что сертификат клиента действителен (не истек, а не черный, и т. Д.).
Как я понимаю (вид 15000 метра.)
Сервер имеет открытый ключ он публикует в своем серт. Это используется вашим браузером для шифрования всего, что он отправляет. Только сервер может расшифровать информацию, поскольку только она (надеюсь) имеет закрытый ключ.
Если у вас есть сертификат клиента, вы даете это серверу, чтобы убедиться, что он шифрует материал, чтобы вы могли его расшифровать (опять же с помощью вашего личного ключа).
Так что для меня: вы можете бесплатно отправить информацию о своей кредитной карте, зная, что только сервер может ее прочитать. Клиент может либо отправить надлежащий сертификат, либо создать «темп» для сеанса, а затем «общедоступный» ключ шифрования на сервере, безопасный, зная, что его никто не отправит. Затем сообщения шифруются в обоих направлениях, но отдельно.
В настоящее время из here
ДУС клиент и сервер переговоры с учетом состояния соединения, используя квитирования процедуру. В течение этого квитирования клиент и сервер соглашаются с по различным параметрам, используемым для , для обеспечения безопасности соединения.
Рукопожатие начинается тогда, когда клиент подключается к TLS с поддержкой сервера запрашивающего защищенное соединение, и представляет список поддерживаемых CipherSuites (шифров и хэш-функций ).
Из этого списка, сервер выбирает самый сильный шифр и хэш функцию, что он также поддерживает и уведомляет клиента о принятом решении.
Сервер отправляет обратно свой идентификатор в форме цифрового сертификата . Сертификат обычно содержит имя сервера, доверенный центр сертификации (CA) , и общедоступное шифрование сервера .
Клиент может связаться с сервером , который выдал сертификат ( доверенный центр сертификации, как указано выше) и убедитесь, что сертификат является подлинным, прежде чем производства.
Для того, чтобы генерировать сессии ключи, используемые для безопасного соединения, клиент шифрует случайное число (RN) с открытого ключа сервера (ПБК), и посылает результат к серверу.Только сервер должен быть в состоянии расшифровать его (с его закрытого ключа (ПКА)): это один факт, что делает ключи скрытых от третьих лиц, так как только сервер и клиент имеет доступ к этому данные. Клиент знает PbK и RN, а сервер знает PvK и (после дешифрование сообщения клиента) RN. Третья сторона может знать только RN, если PvK был скомпрометирован. Из случайного числа обе стороны генерируют ключевой материал для шифрования и дешифрование .
Это завершает квитирование и начинает обеспеченного соединение, которое зашифровано и расшифрованный с ключевым материалом, пока соединение не закрывается.
Этот wikipedia article, вероятно, дает больше информации, чем вы когда-либо захотите.
Как получилось? Если у вас есть сертификат сервера (pfx), и вы отправляете запрос с любого веб-браузера в мире, вы сможете генерировать клиентский сертификат (cer), поэтому любой, у кого есть сниффер, сможет расшифровать сообщения, отправленные сервером. – Costa
Клиент генерирует случайное число, а затем отправляет его на сервер с использованием открытого ключа сервера. Только сервер сможет расшифровать случайное число, используя его закрытый ключ, поэтому в конце оба из них будут иметь доступ к одному и тому же случайному числу. После этого связь будет продолжаться с использованием симметричного алгоритма шифрования, такого как AES или RC4, со случайным числом (или некоторой его производной), используемой в качестве ключа. –
Этот ответ неверен. Клиент не может создать временный сертификат для сеанса. Клиент не связывается с ЦС для проверки сертификата. Часть о шифровании случайного числа применяется только к некоторым наборам шифров. – EJP
Использование сертификата с сервера или клиента даст конечным точкам возможность обмена общим секретом (симметричный ключ шифрования - или семя).
вторичной цели сертификата (и тот, который гораздо менее заемные средств в эти дни, по сравнению с «шифрованием канала между конечными точками») является аутентификацией конечной точки подачи их цифрового сертификата (с использованием сертификата и доказательство владения, которое они также посылают).
В настоящее время подавляющее большинство транзакций SSL фактически беспокоит только «шифрование канала», а не аутентификацию конечной точки. (Практически говоря, это побочный эффект от коммерческого интернета, хотя масса нападений «человек-в-середине» там дает нам все больше стимулов, чтобы попытаться выяснить, как на самом деле знаю вы разговариваете с сервером - или клиент - вы считаете себя.)
Другими словами, сертификат клиента был бы полезен для аутентификации (более или менее «более сильной»), с которой сервер взаимодействует либо с (a), либо с «более» (если все, что вы делали, было гарантией того, что сертификат входит в список доверенных сертификатов, например, сопоставлен с каталогом LDAP/AD пользователей, которые вы считаете «доверенными», или выданными из ЦС, методы выдачи которых вы «доверяете» ») или (б) конкретный пользователь, который вы аутентифицируете (например, снова через базу данных LDAP/AD пользователя, одну или несколько необычных или более), которые были сопоставлены с этим за счет некоторых автоматических или внеполосных - но в любом случае, надеюсь, достаточно безопасный процесс).
Проверка не имеет ничего общего с IP-адресом; это всего лишь базовый механизм передачи данных, но не играет никакой роли в каких-либо действиях с сертификатами. Проверка выполняется на основе клиента, проверяющего содержимое сертификата на доверенную стороннюю подпись и данные, которые сервер может генерировать только в том случае, если он имеет секретный секретный ключ, принадлежащий сертификату. * Сервер, доказывающий владение секретным ключом + доверенная сторонняя подпись сертификата + имя сертификата равна контактному домену = доверие. * – deceze
@deceze Проверка имени хоста является частью HTTPS, но не TLS. Сертификат проверяется против доверенного стороннего * сертификата * плюс цифровая подпись сервера на всей бирже Si far, которую может генерировать только закрытый ключ сервера. – EJP
@ EJP Достаточно честно, проверка домена не входит в сферу TLS в частности. – deceze