双向SSL验证

我想了解双向SSL验证的详细信息。我想知道的是当一个客户收到另一个客户的证书时进行的验证。（请参阅下面的图像中的验证圆）双向SSL验证

Two way verification http://publib.boulder.ibm.com/infocenter/tivihelp/v5r1/topic/com.ibm.itim.infocenter.doc/images/imx_twowaysslcacert.gif

是否有人拥有所有的步骤清单？有没有我可以指出的标准文件？每台服务器是否以不同的方式实施？

主要是什么我问的是...服务器是否做对其他服务器的主机名验证VS证书通用名（CN）？

来源

2011-06-16 Ryan H

[RFC 5246]（http://tools.ietf.org/html/rfc5246）是规范，如果你想要协议本身的血统细节。 – Nemo 2011-06-17 01:26:23

@Nemo，链接到TLS RFC的好点（关于步骤列表）。我会添加[RFC 5280（PKIX）]（http://tools.ietf.org/html/rfc5280）用于证书验证（验证它是可信的）和[RFC 6125]（http://tools.ietf.org/html/rfc6125）用于验证证书是否与服务器的预期标识匹配。尽管这些RFC在大多数情况下倾向于一起使用，但它们是独立的，并且根据应用可以有其他验证模型。 – Bruno 2011-06-17 17:47:36

正如@ user384706所说，它是完全可配置的。

你在谈论该方案是其中一台机器既是服务器和客户端（并且是客户端尽可能的SSL/TLS连接而言）。

你不一定通过验证的连接从所提供的证书的CN（或者主题备用名称）发起获得更安全。

有几个问题：

如果SSL/TLS服务器是指由都是最终用户和服务器本身客户端使用，你将有两个不同的规则具体取决于您对特定证书的期望类型。您可以根据客户端证书是否具有“服务器”扩展密钥使用扩展或者仅具有客户端证书的规则来制定规则，但这会变得有点复杂（为什么不）。
客户端（也是服务器）可能会通过代理服务器，具体取决于它所在的网络，在这种情况下，源IP地址将与您所期望的不匹配。
通常情况下，客户端证书身份验证依赖于一个事实，即假定私钥保存保护。如果私钥被服务器上的攻击者破解，则攻击者在进行连接时（或直接与受感染的服务器建立连接）也可能具有欺骗源IP地址的能力。这就是说，服务器倾向于拥有不受密码保护的私钥，所以如果它被分散地复制，它可能会有所帮助。

我觉得有些工具是如此严格，他们不仅验证CN是传入连接的FQDN：他们也确认它是源IP地址反向DNS条目。这在实践中会导致很多问题，因为某些服务器可能在DNS中有多个CNAME条目，在这种情况下，CN将是合法的，但不一定是该IP地址的主要FQDN。

这一切都取决于系统的总体协议和一般体系结构。

RFC 6125 (Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS))最近发布，认为这种情况超出了范围。

我能想到的最接近的参考是SIP。

来源

2011-06-16 22:30:09 Bruno

主要是什么我问的是...请问服务器也针对其他服务器的主机名VS的证书通用名（CN）验证？

这是可配置的。
它可以配置严格检查和不接受发送证书的CN并不尽管该证书被认为是可信的匹配FQDN实体连接（例如，通过信任的CA签名）。
可以放松一下，不要做这个检查并接受证书或委托决定给用户。例如。 IE显示弹出警告，指出证书名称与FQDN不匹配。你想继续吗？
从安全的角度来看，最安全的是做严格的验证

来源

2011-06-16 21:24:35 Cratylus

回答

相关问题