為了處理最近發現的 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 函式庫。
但是，在與 svn 用戶端相同的 RHEL5-box 上執行的 Apache 使用相同的庫，並且可以順利地提供自己的 SSL 流量（透過 TLSv1）。
在 svn-server 不支援 SSLv3 的情況下，如何讓 svn-client 運作？
更新：仔細觀察ldd的輸出，我發現它svn與 RHEL6 上的 GNUTLS 鏈接，但在 RHEL5 上與 OpenSSL 鏈接，這可能是造成差異的原因。我仍然不明白，為什麼 Apache 在同一 RHEL5 系統上使用 OpenSSL 提供 TLSv1 沒有問題。
答案1
請嘗試這個解決方法https://access.redhat.com/solutions/1234843。
svn-client <-- 支援 SSLv3 --> 本地 stunnel <-- 無 SSLv3 / 自動回退到 TLS --> SVN 伺服器
某些元件不提供允許停用 SSLv3 的設定參數。目前，已知以下組件屬於此類：
開放LDAP
杯子
可以使用 stunnel 來停用這些元件的 SSLv3。 Stunnel 使用 OpenSSL 函式庫進行加密，在遠端用戶端和本機（inetd 可啟動）或遠端伺服器之間提供加密包裝器。若要在 stunnel 上停用 SSLv3，請在 stunnel.conf 檔案中使用下列設定參數：
options = NO_SSLv2
options = NO_SSLv3
答案2
一種解決方案是重新編譯 Subversion 以使用新版本的 serf (1.3.8)——最新的 serf 也不使用 SSLv3，因此可以與僅 TLS 伺服器通訊。然而，在數十個系統上更新svn-client 本身就是有問題的。
我們透過修改伺服器上的 Apache 解決了這個問題，如下所述我對自己關於 ServerFault 的問題的回答。祝你好運。