openssl - 客户端向您提供其公共(public)证书时的相互认证

标签 openssl ssl-certificate mutual-authentication

通常2种方式的ssl aka相互认证包括生成服务器ca密钥和证书等。然后,客户端生成一个csr,将其提供给您,然后您对他们的csr签名并为他们提供客户端证书。

然而,

我遇到了一种情况,即客户端要求我通过互相交换x509公共证书来实现“相互认证”。听说过吗?可能称为“ 2向SSL”或“相互身份验证”以外的名称。

我正在努力用openssl查找与此有关的任何文档或信息。

最佳答案

我遇到了一种情况,即客户端要求我通过互相交换x509公共证书来实现“相互认证”。听说过吗?


我相信它仍称为相互认证。

通常,基于证书的相互认证属于两种模型之一。第一个是具有CA层次结构的企业模型,并且组织的CA会对客户端证书和服务器证书进行签名。

第二种模型是客户端使用称为Origin Bound Certificates的自签名证书。之所以称其为“原始绑定”,是因为每个需要证书的站点(起源)都会让客户端提供一个证书。原始绑定证书是IETF Token Binding protocol的基础。

我尚不清楚令牌绑定是否具有与原始绑定证书相同的安全属性。您会看到,通过将身份验证作为通道设置的一部分,我们可以使用原始绑定证书来阻止中间人攻击。令牌绑定将绑定解耦并在堆栈中向上移动。我相信它可以使MitM充当中介。



企业证书

在企业模型中,这是您使用OpenSSL所要做的。

在服务器上执行以下操作。服务器将处理客户端证书验证:


SSL_CTX_set_verifySSL_VERIFY_PEER调用SSL_VERIFY_FAIL_IF_NO_PEER_CERT
调用CTX_set_client_CA_list设置服务器将接受的颁发者CA的列表。这将导致适当的SSL / TLS消息发送到客户端,提示输入证书。这只会将名称列表发送给客户端。他们仍然必须在服务器上受信任
与服务器接受的发行者呼叫SSL_CTX_load_verify_locations。这在服务器端增加了信任。


在客户端,执行以下操作:


调用SSL_CTX_use_certificate_file加载客户端证书
根据需要致电SSL_CTX_use_certificate_chain_file
调用SSL_CTX_use_PrivateKey加载私钥




原产地证明

原始绑定证书和自签名证书有所不同,因为没有CA层次结构。

在服务器上执行以下操作。服务器不调用SSL_CTX_load_verify_locationsCTX_set_client_CA_list,因为它是自签名证书。


SSL_CTX_set_verifySSL_VERIFY_PEER调用SSL_VERIFY_FAIL_IF_NO_PEER_CERT
交换密钥后呼叫SSL_get_peer_certificate。验证提供给服务器的客户端证书。


在客户端,执行以下操作。它与企业模型相同。


调用SSL_CTX_use_certificate_file加载客户端证书
根据需要致电SSL_CTX_use_certificate_chain_file
调用SSL_CTX_use_PrivateKey加载私钥


缺少企业CA意味着需要将客户端的自签名证书带外传送到服务器。然后,服务器需要保留某种目录,以根据专有名称和序列号查找客户端证书。您真正关心的是客户的公钥。在这种情况下,X509证书是显示详细信息。它只是包装,因为它通常通过授权机构的签名将身份绑定到公共密钥(但在此模型中不是)。

此模型中的攻击-房间中的500磅大猩猩-是坏人,因为没有注册机构(RA),因此使用相同的专有名称和序列号来冒充用户。您将需要采取一些措施来确保自己不受欺骗,例如向用户发送电子邮件以确认他们的公钥更改是可预期的。

该攻击意味着注册用户时,您需要三或四件事:


唯一的{专有名称,序列号}对
公钥(X509证书的一部分)
确认/恢复电子邮件地址


为了进一步弄清水面,用户可能拥有3或4个设备,因此他们为每个设备创建了一个新的原产地证书。您也需要优雅地处理该注册。

总体来说,真正重要的是电子邮件地址以及与该电子邮件地址相关联的不同公钥/身份。身份包含在具有唯一{专有名称,序列号}对的X509证书中。您可能希望它们具有唯一性以进行审核,但是在设备之间可能会进行一些复制/粘贴。




我正在努力用openssl查找与此有关的任何文档或信息。


您可能很难找到信息,因为这是更高级别的安全体系结构和设计问题。为了提供一些参考,请先阅读Dietz,Czeskis,Balfanz和Wallach的Origin-Bound Certificates: A Fresh Approach to Strong Client Authentication for the Web。另请访问Peter Gutmann的Engineering Security和Ross Anderson的Security Engineering

原始绑定证书可用于替换几乎所有基于密码的身份验证系统。它几乎适用于所有系统,从基于用户名/密码的身份验证到Web服务中使用的API密钥。该密码仍用于保护本地私钥,但该密码未置于网上。

当数据敏感度级别需要更强的安全控制时,客户端证书将成为我们制止密码误操作以及错误的身份验证和授权控制的首要任务之一。不要购买苹果,微软,谷歌等人使用和处理密码。多年来一直存在缺陷。它只是一家公司,它使用户轻松自如,从而可以抓住业务。

关于openssl - 客户端向您提供其公共(public)证书时的相互认证,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/37016795/

相关文章:

openssl - 如何使用 SHA256 而不是 sha1 制作 OpenSSL?

c++ - cmake目标链接openssl错误

ssl-certificate - 为什么我们信任 SSL 证书?

java - SSL套接字服务器在握手后获取证书cn

authentication - 相互认证 TLS

java - 提供的证书和 key 作为 SSL 握手的一部分

php openssl_encrypt 在使用 openssl_decrypt 时生成空值

ios - 使用 NSURLConnection 通过自签名证书连接到 https 时出现 kSecTrustResultRecoverableTrustFailure

ssl - 何时/为何需要在 TLS 协商中使用 CACert?

c# - 仅在服务器端使用证书