Взаимная аутентификация TLS

Какая польза от взаимной аутентификации в TLS без ограничения сертификата клиента?

Вот мое понимание клиентской / взаимной аутентификации с использованием TLS.

Идея состоит в том, что оба сервера и клиент аутентифицируют / проверяют сертификаты друг друга, поэтому

1- The client verifies the server cert based on its CA trust store 
2- The server verifies the client cert based on its *CA trust store*

Теперь ключевым моментом для меня является второй: сервер должен доверять сертификату клиента, либо сохраняя его в хранилище доверенных сертификатов сервера, либо сохраняя CA / ICA сертификата клиента, который должен быть частным для клиента, а не через общедоступный ЦС, частный ЦС для того клиента, которому сервер желает доверять.

Теперь rfc5246 говорит следующее

If the client has sent a certificate with signing ability, a digitally-signed
CertificateVerify message is sent to explicitly verify possession of
the private key in the certificate.

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


authentication certificate tls1.2 client-certificates mutual-authentication
person ZKA    schedule 05.06.2020    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Когда сервер получает сертификат клиента (как часть протокола TLS), сервер выполняет все обычные проверки сертификатов, включая связывание с доверенным корнем. Чтобы сервер мог доверять сертификату клиента, выданному Foo CA, на сервере должен быть уже установлен корень Foo CA.

Краеугольным камнем сертификатов X.509 являются корневые сертификаты CA. Хост должен доверять только сертификатам, выпущенным центрами сертификации, которым он доверяет. Поэтому, когда администратор устанавливает корни FooCA, администратор заявляет: «Я доверяю сертификатам, выданным Foo, и я верю, что Foo выполнил соответствующие проверки, что сертификат действителен и назначен правильному объекту».

Серверу не нужно хранить сертификат клиента, нет причин для этого. Когда сертификат поступает как часть TLS, сервер просто проверяет его. Никакой настойчивости не требуется, и если что-то выйдет из строя, включая отсутствие установленного корневого сертификата Foo CA, соединение не будет установлено.

Сервер ДЕЙСТВИТЕЛЬНО аутентифицирует клиента. Сертификат связывает открытый ключ (в сертификате) с сущностью; например [email protected]. Когда клиент подключается и сервер запрашивает сертификат клиента, сервер проверяет, соответствует ли имя в сертификате ([email protected]) имени пользователя, но он также заставит клиента зашифровать некоторые данные с помощью закрытый ключ, связанный с открытым ключом в сертификате, и если сервер успешно расшифровывает данные, то клиент ([email protected]) действительно тот, кем они себя называют. Или, в худшем случае, самозванец, получивший доступ к закрытому ключу Фродо :)

Это помогает?

person MichaelHoward-MSFT    schedule 05.06.2020
comment
Я очень помогаю, у меня есть дополнительный вопрос, основанный на вашем последнем абзаце, могу ли я установить цепочку CA на моем сервере, эта цепочка подписывает сертификаты для theshire.com и foo.com, но мне нужно, чтобы сервер принял Возможно ли соединение TLS только с сайта theshire.com? или это возможно ТОЛЬКО, когда два клиента используют два разных CA / ICA, но сервер доверяет / устанавливает только один из этих CA / ICA? имеет ли вопрос смысл? - person ZKA; 05.06.2020
comment
Как работает X.509, после установки сертификата корневого ЦС (и любых других сертификатов в цепочке) вы доверяете любым листовым сертификатам из этого ЦС. Так что, если Foo CA выдает сертификаты на адрес [email protected] и [email protected], вы доверяете им обоим. Теперь, предполагая, что ваш код делает правильные вещи и выполнил всю правильную криптографическую проверку, теперь вы можете принимать любые другие решения, которые захотите, включая удаление имени из сертификата и разрешение только theshire.com. Однако важно, чтобы вы сначала выполнили всю криптографическую работу, например, привязку к корню. Если у вас есть дальнейшие вопросы, дайте мне знать. - person MichaelHoward-MSFT; 05.06.2020
comment
Я вижу, что балансировщики нагрузки всегда устанавливают / доверяют ICA, который выдает сертификат клиента, обычно клиент создает этот ICA внутри компании и выдает сертификат только для целей аутентификации клиента, почему они не делают это по имени CN? не так ли проще? или есть проблема безопасности при проверке подхода имени? - person ZKA; 05.06.2020
comment
При связывании с корневым сертификатом CA никогда не следует ТОЛЬКО подключать к промежуточным сертификатам CA, вы всегда должны идти наверх. Проверка имени - это нормально, до тех пор, пока вы сначала выполнили все настоящие криптографические вещи, в первую очередь привязку к корню и проверку допустимости подписи на сертификате. Конечно, есть и другие вещи, такие как диапазоны дат, но это делается после криптографии. - person MichaelHoward-MSFT; 06.06.2020
comment
Спасибо, да, root включен, я хотел отредактировать свой вопрос, но это не позволило мне :), большое спасибо за то, что продолжаете отвечать на мои последующие вопросы. - person ZKA; 06.06.2020
comment
ставите - в любое время :) - person MichaelHoward-MSFT; 09.06.2020
comment
Это было очень полезно. Почему в 99% руководств по внедрению эта часть обычно не упоминается? : The server DOES authenticate the client. A certificate binds a public key (in the cert) to an entity; for example [email protected] - person RobOhRob; 09.01.2021