1

我目前正在使用禁用 SSLv3 的 APR 连接器将我的 Tomcat 服务器升级到 Tomcat 7。这是我的连接器：

<Connector port="8443" maxHttpHeaderSize="8192"
           maxThreads="150"
           enableLookups="false" disableUploadTimeout="true"
           acceptCount="100" scheme="https" secure="true"
           SSLEnabled="true" 
           SSLProtocol="TLSv1"
           SSLCertificateFile="${CP_ROOT}/security/tomcat.crt"
           SSLCertificateKeyFile="${CP_ROOT}/security/tomcat.key" />

一切似乎都在正常工作......例如，通过 HTTPS 访问一个页面可以正确地提供该页面。但是，我们使用的是 F5 负载平衡器，一旦我禁用 SSLv3，配置的运行状况监视器就开始为该节点/端口失败。在 F5 方面进行了一些故障排除后，我决定尝试使用 OpenSSL 进行诊断：

$ openssl s_client -connect casrept2.tc.columbia.edu:8443/cas/monitor.jsp      
CONNECTED(00000003)
write:errno=54

做同样的事情，但强制 TLSv1 ( -tls1)，我能够正确连接：

$ openssl s_client -connect casrept2.tc.columbia.edu:8443/cas/monitor.jsp -tls1
CONNECTED(00000003)
... cert chain, etc, etc

我想知道这是否是导致运行状况监视器失败的原因。不管怎样，我很好奇为什么我需要特别强迫-tls1它起作用。我认为它应该自动协商正确的协议？

4

1 回答 1

4

openssl你用的是什么版本s_client？如果是 0.9.8 系列，则默认为协议 ssl2,ssl3,tls1(.0)，这要求它使用 SSL2 格式 ClientHello（但内容可以协商到 tls1.0）。在 Tomcat/APR 中指定了 tls1-only 的 openssl 服务器（而不是默认的自动检测）将根据SSL3+ 格式协商或返回警报，但对于 SSL2 格式，它只会关闭 TCP 连接——至少在Windows 它使用 RST“异常”地执行此操作，这会导致s_client系统调用错误并显示您看到的消息。（虽然 54 是一个 errno 值，但我不记得在 RST 中看到过；你能说一下是什么操作系统吗？）

通过指定s_client -tls1您使其使用包含版本 3.1 = TLS1.0 的 SSL3+ 格式并且它可以工作。如果您改为使用-ssl3它，则无法协商，但它确实会获得更具体的信息alert handshake failure，而不仅仅是 TCP 错误。如果您使用-no_ssl2它使用 SSL3+ 格式并协商 TLS1.0，尽管这在此处不如-tls1.

如果您使用 openssl 1.0.0 或 1.0.1 系列，s_client它们应该默认为 minimum-SSL3 和（因此）SSL3+ hello 格式并且可以工作，除非在构建过程中做了一些不寻常的事情。

我不知道 F5 监视器在这里做什么——或者可以做什么——但是如果它尝试 SSL2 格式 hello 在理论上是——或者过去是——最大互操作性，我不会感到惊讶。如果是这样，那将导致连接失败，这可以理解为服务器的问题。您可以在您的服务器上（或附近）放置诸如 www.wireshark.org 或类似的跟踪，并查看 F5 发送的确切内容，并确认您的服务器以 RST 响应。

于 2014-12-11T02:29:37.600 回答