我的工作场所最近修补了我们的一台服务器以解决 POODLE 漏洞。从那时起，较旧的 Oracle Linux 5 客户端（基于 RHEL 5）无法再使用任何应用程序安全地连接到服务器。客户端计算机使用 OpenSSL 版本 0.9.8e；在这些计算机上安装最新可用版本的 OpenSSL (0.9.8e-31) 不会产生任何影响，但会强制客户端仅使用 TLSv1做解决问题。
例如，s_client产生这样的结果：
$ openssl s_client -connect foo.bar.com:443
CONNECTED(00000003)
5529:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
然而，这可以正常工作：
$ openssl s_client -connect foo.bar.com:443 -tls1
同样，wget https://foo.bar.com/testFile失败但wget --secure-protocol=TLSv1 https://foo.bar.com/testFile有效。
我的主要问题是，如何在这些客户端计算机上全局配置 OpenSSL，以便它们可以再次连接没有必须手动重新配置我们使用或将来可能使用的每个应用程序。将这些机器升级到较新版本的 Linux 并不是一种选择。如果您能解释到底是什么导致了这种行为，那就加分了。
谢谢！
答案1
首先，为什么？在里面文档用于s_client据说 openssl 默认情况下会使用握手来为您找出正确的协议。这就是 POODLE 攻击的全部基础。问题是，在 0.9.8 中，握手从 SSL_V23 开始，稍后会尝试 TLSv1 。当客户端使用 SSL_V23 连接时，许多服务器不喜欢它，因为这是一个危险信号，表明客户端正在执行不安全的操作，因此您的问题。
如何修复它？好吧，我找不到 openssl.cnf 的任何选项可以让你说“嘿，默认情况下只使用 TLSv1”。在这个线程，他们似乎暗示这在 v1.0.0+ 中是可能的。经过一个小时的谷歌搜索后，我决定你最好的选择是重新编译 openssl 并禁用 SSLv2 和 SSLv3。如果您要重新编译 openssl，那么使用 0.9.8 可能会更容易，尝试在 RHEL 之类的系统中将 openssl 升级到 1.x+ 可能完全是一场噩梦。
答案2
由于 RHEL 5 也遇到同样的问题，我刚刚检查了他们的 bugzilla：https://bugzilla.redhat.com/show_bug.cgi?id=1152789
他们非常关注 Tomcat 6 和 JBoss 的东西，这归结为更改应用程序服务器配置中的几行。
但在该 bugzilla 中，有一个线程导致 RHEL5 的 openssl 问题。
https://rhn.redhat.com/errata/RHSA-2014-1653.html
openssl-0.9.8e-31.el5_11 是您需要的上游重新编译的 openssl。
所以：恕我直言，您只需要安装该补丁并强制您的网络/应用程序服务器不要使用不安全的协议。