SSL работает без сертификата клиента

Question

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

Спасибо

Answer 1

Насколько я понимаю ( вид с 15000 метров. )

У сервера есть открытый ключ, который он публикует в своем сертификате. Это используется вашим браузером для шифрования всего, что он отправляет. Только сервер может расшифровать информацию, поскольку только он (надеюсь) имеет закрытый ключ.

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

Так что мне: Вы можете совершенно свободно отправлять информацию о своей кредитной карте, зная, что ее может прочитать только сервер. Затем клиент может либо отправить надлежащий сертификат, либо создать временный сертификат для сеанса, а затем «открытый» ключ шифрования на сервер в безопасности, зная, что никто другой не отправит его. Затем связь зашифровывается в обоих направлениях, но отдельно.

Теперь с здесь

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

• Рукопожатие начинается, когда клиент подключается к серверу с поддержкой TLS запросить безопасное соединение и представляет список поддерживаемых CipherSuites (шифры и хэш функции).

• Из этого списка сервер выбирает самый сильный шифр и хэш функция, которую он также поддерживает и уведомляет клиента о принятом решении.

• Сервер отправляет обратно свои идентификация в виде Цифровой сертификат. Сертификат обычно содержит имя сервера, доверенный центр сертификации (CA), и публичное шифрование сервера ключ.

• Клиент может связаться с сервером который выдал сертификат ( доверенный CA, как указано выше), и подтвердите, что сертификат является подлинным до продолжение.

• Для генерации сеансовые ключи, используемые для безопасного соединение, клиент шифрует случайное число (RN) с сервера открытый ключ (PbK) и отправляет результат на сервер. Только сервер должен быть в состоянии расшифровать его (с его закрытый ключ (PvK)): это один Тот факт, что ключи скрыты от третьи лица, так как только сервер и клиент имеет доступ к этому данные. Клиент знает PbK и RN, и сервер знает PvK и (после расшифровка сообщения клиента) RN. Третья сторона может знать RN, только если PvK был скомпрометирован. От случайное число, обе стороны генерируют ключевой материал для шифрования и дешифрования.

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

Эта статья в википедии , вероятно, дает больше информации, чем вы когда-либо хотели.

Answer 2

Думайте о сертификате не с точки зрения шифрования-дешифрования, а с точки зрения аутентификации. Шифрование может быть сделано без сертификатов - достаточно знать, что открытый ключ достаточно. Но сертификат содержит разные поля, среди которых личность владельца сертификата. Для сети это значение - доменное имя сервера, к которому вы хотите подключиться. Поскольку существуют способы проверить, что IP-адрес сервера всегда равен имени, указанному в сертификате (прямые и обратные запросы DNS), вы можете быть уверены, что говорите с тем, который хотите.

В этом смысле вопрос с сертификатом клиента должен быть намного проще для понимания. Сертификат клиента позволяет серверу аутентифицировать клиента, поэтому аутентификация будет взаимной. Например, сервер может проверить, что сертификат клиента действителен (не истек, не занесен в черный список и т. Д.).

Answer 3

Я тоже нашел это

Клиентские сертификаты: http://support.microsoft.com/kb/895971

более практически: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/751c99bd-9657-41a5-b541-569d305872ef.mspx?mfr=true

Спасибо

Answer 4

Использование сертификата с сервера или клиента даст конечным точкам возможность обмена общим секретом (симметричный ключ шифрования - или начальное число).

A вторичная цель для сертификата (и та, которая в наши дни гораздо менее эффективна, чем "шифрование канала между конечными точками") состоит в аутентификации конечной точке, предоставляющей их цифровой сертификат (с использованием сертификата и подтверждения владения, которое они также отправляют).

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

Другими словами, сертификат клиента был бы полезен для проверки подлинности (более или менее «более сильным» образом) того, что сервер взаимодействует либо с (а) «более доверенным» клиентом (если все, что вы делали, это проверяло что сертификат входит в пул сертификатов, которым вы доверяете - например, сопоставлен с каталогом LDAP / AD пользователей, которых вы считаете «доверенными», или выдан центром сертификации, которому вы доверяете, или (б) конкретному пользователю, которому вы доверяете проверять подлинность (например, снова через базу данных пользователей LDAP / AD, одна - или несколько необычно, или более - из которых была сопоставлена ​​с этим сертификатом с помощью некоторого автоматического или внеполосного подключения - но в любом случае, надеюсь, достаточно безопасная - процесс).