在SSL握手期间检查服务器的域名 [英] Is domain name of the server checked during SSL handshake
问题描述
示例：假设服务器证书有域mydomain.com。如果服务器在域中运行someotherdomain.com ...这是在SSL握手期间被扣留，因为mydomain.com不是someotherdomain.com？
它取决于...
SSL / TLS标准本身不指定如何以及何时验证服务器证书。
从简介： p>
[...]关于如何启动TLS握手的决定以及如何解释交换的身份验证证书，由设计人员和
这就是说，虽然它没有指定如何进行身份验证，实现是在握手期间（或至少紧随其后）执行此检查：
- 请参阅附录D 。
- 一些错误消息与证书认证失败明显相关（
bad_certificate，certificate_expired，...）。 - handhsake overview ： [...]如果服务器通过身份验证，它可以从客户端请求证书，如果这对于选择的密码套件是适用的。
在大多数情况下，证书验证本身由 RFC 3280 / RFC 5280 。
默认情况下，许多SSL / TLS堆栈将至少执行此操作。
主机名验证可以被认为是证书认证步骤之一，历来是分开实施的。这主要是因为RFC 3280 / RFC 5280没有解决这一步，并将其留给每个应用协议。在 RFC 6125 中有一个相对较近的协调尝试（您可以在附录中找到协议的差异B / B
SSL / TLS握手期间主机名称检查是否完成取决于您正在使用的库，以及如何配置。 >
例如，在Java 7之前，这必须与主要的JSSE API（ SSLSocket / 的SSLEngine ）。 （例如，这是在 HttpsURLConnection 中完成的，但这位于JSSE之上，而不在于。）由于Java 7可以在握手期间执行此检查，在JSSE内使用 X509ExtendedTrustManager ，但必须使用 SSLParameters.setEndpointIdentificationAlgorithm （...） ，其中只支持 HTTPS 和 LDAPS （据说，即使您的服务不使用HTTP，使用 HTTPS 作为端点识别算法不会是一个不好的选择，肯定比没有更好）。
其他SSL / TLS库或在其他l中包装其他库至少有这样的回调。是否由开发人员使用（并正确使用）取决于，如本文所示。 （您也可能对Security.SE中的此问题感兴趣。）
During SSL handshake, is the domain name of the server checked during SSL handshake, I mean is the domain name in the server certificated checked against the domain in which server is running ?
Example: Suppose Server certificate has domain mydomain.com . And if server is running in domain someotherdomain.com ... Is this cheked during SSL handshake and aborted as mydomain.com is not someotherdomain.com ?
It depends...
The SSL/TLS standard itself doesn't specify how and when the server certificate is verified.
From the introduction:
[...] the decisions on how to initiate TLS handshaking and how to interpret the authentication certificates exchanged are left to the judgment of the designers and implementors of protocols that run on top of TLS.
This being said, while it doesn't specify how the authentication has to take place, implementations are meant to perform this check during the handshake (or at the very least, immediately after):
- See Appendix D.
- Some error messages are clearly related to certificate authentication failure (
bad_certificate,certificate_expired, ...). - Some of the text in the handhsake overview: "[...] If the server is authenticated, it may request a certificate from the client, if that is appropriate to the cipher suite selected."
In most cases, the certificate verification itself is guided by RFC 3280/RFC 5280. A number of SSL/TLS stacks will at least do this by default.
The host name verification, which could be considered as one of the certificate authentication step, has historically been implemented separately. This is mainly because RFC 3280/RFC 5280 didn't address this step and left it to each application protocol. There is a relatively recent harmonisation attempt in RFC 6125 (you can find the differences in protocols in Appendix B).
Whether host name checking is done during the SSL/TLS handshake depends on the library you're using, and how you've configured it.
For example, before Java 7, this had to be done separately from the main JSSE API (SSLSocket/SSLEngine). (This was done in HttpsURLConnection, for example, but this sits on top of the JSSE, not within.) Since Java 7, it's possible to perform this check during the handshake and within the JSSE using the X509ExtendedTrustManager, but this has to be configured using SSLParameters.setEndpointIdentificationAlgorithm(...), which only supports HTTPS and LDAPS (this being said, even if your service doesn't use HTTP, using HTTPS for the endpoint identification algorithm wouldn't be a bad choice, certainly better than nothing).
Other SSL/TLS libraries or wrapping other libraries in other languages tend at least to have callbacks for this. Whether they're used (and used correctly) by developers depends, as shown in this paper. (You might also be interested in this question on Security.SE.)
这篇关于在SSL握手期间检查服务器的域名的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
