为了解决最近发现的 SSLv3 中的 POODLE 漏洞,我们在我们的服务器上禁用了旧协议——包括 Subversion 存储库服务器。
这破坏了我们 RHEL5 机器上的 svn-clients ——它们现在报告以下错误:
svn: OPTIONS of 'https://svn.example.net/foo/trunk/': SSL negotiation failed: Secure connection truncated (https://svn.example.net)
。
svn 版本是 1.6.11。RHEL6 上的相同版本没有问题,因此人们可能会认为差异在于 openssl-libraries。
但是与 svn-client 在同一 RHEL5-box 上运行的 Apache 使用相同的库,并且顺利地提供其自己的 SSL 流量(通过 TLSv1)。
如果 svn-server 不支持 SSLv3,我该如何使 svn-client 工作?
更新:仔细查看ldd
的输出,我发现svn
在 RHEL6 上与 GNUTLS 链接,但在 RHEL5 上与 OpenSSL 链接,这可能是造成差异的原因。但是,我仍然不明白为什么在同一个 RHEL5 系统上使用 OpenSSL 的 Apache 可以毫无问题地提供 TLSv1。
答案1
请尝试此解决方法https://access.redhat.com/solutions/1234843。
svn-client <-- 支持 SSLv3 --> 本地 stunnel <-- 不支持 SSLv3 / 自动回退到 TLS --> SVN 服务器
某些组件不提供允许禁用 SSLv3 的配置参数。目前,已知以下组件属于此类别:
OpenLDAP
杯子
可以使用 stunnel 禁用这些组件的 SSLv3。Stunnel 在远程客户端和本地(inetd 可启动)或远程服务器之间提供加密包装器,使用 OpenSSL 库进行加密。n 要在 stunnel 上禁用 SSLv3,请在 stunnel.conf 文件中使用以下配置参数:
options = NO_SSLv2
options = NO_SSLv3
答案2
一个解决方案是重新编译 Subversion 以使用新版本的 serf (1.3.8)——最新的 serf 也不使用 SSLv3,因此可以与仅支持 TLS 的服务器通信。但是,svn
在数十个系统上更新 -client 本身就存在问题。
我们通过修改服务器上的 Apache 解决了这个问题,具体如下:我对 ServerFault 上问题的回答。祝你好运。