Como usar o svn-client no RHEL5 depois que o servidor desabilitou o SSLv3?

Question

Para lidar com a vulnerabilidade POODLE recentemente descoberta no SSLv3, desativamos o protocolo antigo em nossos servidores - incluindo o servidor do repositório Subversion.

Isso quebrou os svn-clients em nossas máquinas RHEL5 - eles agora relatam o seguinte erro:

svn: OPTIONS of 'https://svn.example.net/foo/trunk/': SSL negotiation failed: Secure connection truncated (https://svn.example.net) .

A versão do svn é a 1.6.11. A mesma versão no RHEL6 é boa, então pode-se pensar que a diferença está nas bibliotecas openssl.

Mas o Apache rodando no mesmo RHEL5-box que o svn-client usa as mesmas bibliotecas e está atendendo seu próprio tráfego SSL sem um engate (por TLSv1).

Como faço o svn-client funcionar sem o svn-server suportando SSLv3?

Atualização : Olhando mais de perto a saída de ldd , vejo que svn se vincula ao GNUTLS no RHEL6, mas ao OpenSSL no RHEL5, o que pode explicar a diferença. Eu ainda não entendo, porque o Apache usando o OpenSSL no mesmo sistema RHEL5 não tem problema em oferecer o TLSv1, no entanto.

    

Answer 1

Por favor, tente esta solução alternativa link .

svn-client < - suporta SSLv3 - > Stunnel local < - sem SSLv3 / automatic voltar para TLS - > Servidor SVN

Some components do not provide configuration parameters that allow SSLv3 to be disabled. Currently, the following components are known to fall into this category:

OpenLDAP

cups

It is possible to disable SSLv3 for these components by using stunnel. Stunnel provides an encryption wrapper between a remote client and a local (inetd-startable) or remote server, using the OpenSSL library for cryptography. n To disable SSLv3 on stunnel, use the following configuration parameters in the stunnel.conf file:

options = NO_SSLv2
options = NO_SSLv3

    

Answer 2

Uma solução foi recompilar o Subversion para usar a nova versão do servo (1.3.8) - o servidor mais novo também não usa o SSLv3 e, portanto, pode conversar com o servidor somente TLS. No entanto, a atualização de svn -client em dezenas de sistemas é problemática por si só.

Resolvemos esse problema modificando o Apache no servidor, conforme descrito em minha resposta à minha própria pergunta no ServerFault . Boa sorte.