Para abordar la vulnerabilidad POODLE recientemente descubierta en SSLv3, desactivamos el protocolo antiguo en nuestros servidores, incluido el servidor de repositorio Subversion.
Esto rompió los clientes svn en nuestras máquinas RHEL5; ahora informan el siguiente error:
svn: OPTIONS of 'https://svn.example.net/foo/trunk/': SSL negotiation failed: Secure connection truncated (https://svn.example.net).
La versión svn es 1.6.11. La misma versión en RHEL6 está bien, por lo que uno podría pensar que la diferencia radica en las bibliotecas openssl.
Pero Apache que se ejecuta en la misma caja RHEL5 que el cliente svn usa las mismas bibliotecas y sirve su propio tráfico SSL sin problemas (a través de TLSv1).
¿Cómo hago para que svn-client funcione sin que svn-server admita SSLv3?
Actualizar: Mirando más de cerca lddla salida de , veo que svnse vincula con GNUTLS en RHEL6, pero con OpenSSL en RHEL5, lo que puede explicar la diferencia. Sin embargo, todavía no entiendo por qué Apache que usa OpenSSL en el mismo sistema RHEL5 no tiene problemas para ofrecer TLSv1.
Respuesta1
Pruebe esta soluciónhttps://access.redhat.com/solutions/1234843.
svn-client <-- admite SSLv3 --> stunnel local <-- no SSLv3 / retorno automático a TLS --> servidor SVN
Algunos componentes no proporcionan parámetros de configuración que permitan deshabilitar SSLv3. Actualmente, se sabe que los siguientes componentes entran en esta categoría:
AbiertoLDAP
tazas
Es posible desactivar SSLv3 para estos componentes mediante stunnel. Stunnel proporciona un contenedor de cifrado entre un cliente remoto y un servidor local (inetd-startable) o remoto, utilizando la biblioteca OpenSSL para criptografía. n Para deshabilitar SSLv3 en stunnel, use los siguientes parámetros de configuración en el archivo stunnel.conf:
options = NO_SSLv2
options = NO_SSLv3
Respuesta2
Una solución fue recompilar Subversion para usar la nueva versión de serf (1.3.8); el siervo más nuevo tampoco usa SSLv3 y, por lo tanto, puede comunicarse con el servidor solo TLS. Sin embargo, actualizar svnel cliente en docenas de sistemas es problemático en sí mismo.
Resolvimos este problema modificando Apache en el servidor como se describe enmi respuesta a mi propia pregunta sobre ServerFault. Toda la suerte.