Двухсторонние проверки SSL - PullRequest
1 голос
/ 17 июня 2011

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

Двусторонняя проверка http://publib.boulder.ibm.com/infocenter/tivihelp/v5r1/topic/com.ibm.itim.infocenter.doc/images/imx_twowaysslcacert.gif

Есть ли у кого-нибудь список всех шагов?Есть ли документ по стандартам, на который я могу указать?Каждый сервер реализует это по-своему?

Главным образом, что я спрашиваю ... Сервер выполняет проверку по имени хоста другого сервера против сертификатов Общее имя (CN)?

Ответы [ 2 ]

0 голосов
/ 17 июня 2011

Как говорит @ user384706, он полностью настраивается.

Сценарий, о котором вы говорите, - это сценарий, в котором машина является одновременно и сервером, и клиентом (и клиентом для соединения SSL / TLS).обеспокоен).

Вы не обязательно получаете гораздо большую безопасность, проверяя, что соединение происходит от CN (или, возможно, Subject Alternative Name) сертификата, который представлен.

Естьпара проблем:

  • Если сервер SSL / TLS предназначен для использования клиентами, которые являются как конечными пользователями, так и самими серверами, у вас будут два разных правила в зависимости отна какой тип клиента вы ожидаете для конкретного сертификата.У вас может быть база правил о том, имеет ли клиентский сертификат расширение расширенного ключа «серверный» или только клиентский, но это может немного усложнить (почему бы и нет).

  • Клиент (который также является сервером) может проходить через прокси-сервер, в зависимости от сети, в которой он находится, и в этом случае исходный IP-адрес не будет соответствовать ожидаемому.

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

Я думаю, что некоторые инструменты настолько строгичто они не только подтверждают, что CN является полным доменным именем входящего соединения: они также проверяют, что это обратная запись DNS для исходного IP-адреса.Это может вызвать ряд проблем на практике, поскольку некоторые серверы могут иметь несколько записей CNAME в DNS, и в этом случае CN будет легитимным, но не обязательно основным FQDN для этого IP-адреса.

Все этодействительно зависит от общего протокола и общей архитектуры системы.

RFC 6125 (Представление и проверка идентичности службы приложений на основе домена в инфраструктуре открытых ключей Интернета с использованием сертификатов X.509 (PKIX) вКонтекст безопасности транспортного уровня (TLS)) , недавно опубликованный, считает, что этот сценарий выходит за рамки.

Ближайшая ссылка, о которой я могу подумать, это SIP .

0 голосов
/ 17 июня 2011

Главным образом я спрашиваю ... сервер делает проверку против имя хоста другого сервера против сертификаты Общее имя (CN)?

Это настраивается.
Можно настроить строгую проверку и , а не принимать соединения от объектов, отправляющих сертификат, что CN не соответствует FQDN, несмотря на тот факт, что сертификат считается доверенным (например, подписанным доверенным CA).
Можно ослабить это и не выполнять эту проверку и принимать сертификат или делегировать решение пользователю. Например. IE показывает всплывающее предупреждение о том, что имя сертификата не соответствует FQDN. Вы все равно хотите продолжить?
С точки зрения безопасности самым безопасным является строгая проверка

...