ssl - OpenSSL s_client无法通过APR连接到Tomcat 7

我目前正在使用禁用了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使其起作用。我认为它应该自动协商正确的协议？

最佳答案

您为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是一个错误值，我不记得在RST上看到过；您能说出什么操作系统吗？）

通过指定s_client -tls1，可以使其使用包含版本3.1 = TLS1.0的SSL3 +格式，并且可以使用。如果改用-ssl3，则无法协商，但确实会得到更具体的alert handshake failure，而不仅仅是TCP错误。如果您使用使用SSL3 +格式并协商TLS1.0的-no_ssl2，尽管在​​此情况下不如-tls1方便。

如果对s_client使用openssl 1.0.0或1.0.1系列，则它们应默认使用最低SSL3和（因此）SSL3 + hello格式并可以正常工作，除非在构建过程中进行了一些不寻常的操作。

我不知道F5显示器在这里能做什么或可以做什么，但是如果它尝试SSL2格式的问候是（或过去是）最大程度的可互操作性，这也不会令我感到惊讶。如果是这样，将导致它获得连接失败，这可以理解为服务器问题。您可以在服务器上（或附近）放置诸如www.wireshark.org之类的踪迹，或类似的踪迹，以查看F5发送的确切信息，并确认服务器以RST响应。

关于ssl - OpenSSL s_client无法通过APR连接到Tomcat 7，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/27410851/