¿Es posible establecer un protocolo SSL en Apache para un solo VirtualHost (poodle)?


13

Estoy tratando de probar un parche para la vulnerabilidad de poodle que implica deshabilitar SSLv3 en mi servidor web. Para probar esto primero en un entorno que no sea de producción, estoy configurando SSLProtocol en un VirtualHost para un servidor de prueba diferente. Mi configuración se parece a esto:

<VirtualHost *:443>
    SSLEngine On
    SSLProtocol All -SSLv2 -SSLv3
    ServerName test.mysite.com
    # bunch of other stuff omitted
</VirtualHost>

Sin embargo, incluso después de reiniciar Apache, mi sitio de prueba sigue siendo vulnerable. ¿Se espera que esto funcione? Me pregunto si tengo que configurarlo en la configuración ssl global o si hay algo más sutil que está causando que la configuración no tome y / o funcione.

Respuestas:


16

Puede configurar SSLProtocol solo para el primer VirtualHost en el archivo de configuración. Todas las entradas posteriores de VirtualHost heredarán esa configuración de la primera entrada e ignorarán silenciosamente su propia configuración debido a un error de OpenSSL .

Hay un informe de error correspondiente para mod_ssl , pero como se describe en el informe de error, el problema debe resolverse en OpenSSL (el certificado se hereda pero no los protocolos).

Los conjuntos de cifrado se deben configurar de forma independiente para cada VirtualHost, de lo contrario, terminará con la lista predeterminada, que incluye muchos cifrados inseguros. Además, tenga en cuenta que los clientes más antiguos que no admiten la Indicación de nombre del servidor (SNI) siempre usarán el host predeterminado (a menos que se bloquee el usoSSLStrictSNIVHostCheck ), lo que puede confundir sus pruebas.

En resumen, debe poder especificar conjuntos de cifrado y certificados personalizados para cada host virtual, pero hasta que se solucione el error, no espere un comportamiento correcto con protocolos personalizados para cada host virtual.

Encontré este problema con Apache 2.4 y modssl con OpenSSL 1.0.1k, y espero que Apache 2.2 esté sujeto a los mismos problemas.

Actualización (octubre de 2016): el error de OpenSSL se marcó como resuelto el 13 de octubre de 2016. Sin embargo, fue parte de un cierre masivo de problemas abiertos y, aunque se proporcionó una 'solución parcial', el problema nunca se resolvió por completo.

Actualización (abril de 2018): el error de OpenSSL reenviado ahora tiene un parche disponible (a partir del 9 de abril de 2018). Este parche cambiará el comportamiento de las instancias de Apache configuradas con múltiples hosts virtuales SNI:

Rechazar conexiones que no se ajustan a vhost SSLProtocol

Esto fue desarrollado y probado con 2.4.27 y en producción con esa versión. El parche se modificó para 2.4.33 y se probó ligeramente.

Esto verifica la versión de la conexión con el protocolo SSL configurado para el host virtual que coincide con el SNI. Debido a que la conexión se realiza inicialmente con el protocolo SSL configurado para el host predeterminado para el puerto, el host predeterminado debe incluir todos los protocolos que serán compatibles con cualquier host virtual.

Este parche agrega un estado de retorno adicional de APR_EMISMATCH a la función init_vhost para que la devolución de llamada ssl_callback_ServerNameIndication registrada con OpenSSL pueda devolver la alerta fatal SSL_AD_PROTOCOL_VERSION. Esto tiene la intención de producir la misma respuesta al ClientHello que tener un protocolo SSL especificado que no incluye la versión en cuestión. Debido a que la devolución de llamada SNI se llama durante el procesamiento de ClientHello y antes de que se produzca una respuesta, parece hacer exactamente eso.

Si de repente ve mensajes con el siguiente formato:

Rejecting version [version] for servername [hostname]

Luego, debe verificar su SSLProtocolhost predeterminado.


La información adicional agregada por @anx con respecto SSLStrictSNIVHostCheckes muy apreciada. Sin embargo, también debe tenerse en cuenta a partir de la documentación citada que si se establece en el de cualquier otra máquina virtual, los clientes desconocen SNI no se les permite acceder a este host virtual en particular .
vallismortis

5

Puede tener diferentes protocolos SSL para cada Vhost si están escuchando en una IP diferente.

Ejemplo con un host específico que permite TLSv1 y todos los demás que solo permiten TLSv1.1 y TLSv1.2, y uno que solo permite TLSv1.2:

<VirtualHost *:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3 -TLSv1
  ServerName test.mysite.com
  # bunch of other stuff omitted
</VirtualHost>

<VirtualHost 10.0.0.2:443>
  SSLEngine On
  SSLProtocol All -SSLv2 -SSLv3
  ServerName test2.mysite.com
</VirtualHost>

<VirtualHost 10.0.0.3:443>
  SSLEngine On
  SSLProtocol TLSv1.2
  ServerName test2.mysite.com
</VirtualHost>

Además, si lo necesita solo con fines de prueba, puede usar otro puerto en lugar de otra IP, por ejemplo, un puerto HTTPS alternativo común 8443.
Esa Jokinen

0

Si está utilizando la Indicación de nombre del servidor (SNI) con su vhost, de hecho, no puede definir una versión SSL múltiple.

Sin embargo, si está utilizando un servidor dedicado, probablemente pueda agregar otra dirección IP a su servidor. De esta manera, podrá utilizar una versión SSL diferente por IP. Solo tiene que cambiar la configuración de vhost como se esperaba IP: 443.


-2

O puedes usar:

SSLProtocol TLSv1 TLSv1.1 TLSv1.2

¡Fui probado en muchos servidores y funciona para mí! Puedes probar tu sitio en este sitio web


44
Esta línea SSLProtocol solo parece estar funcionando porque Apache no se queja de eso. En realidad, solo se utiliza SSLProtocol en la primera entrada de VirtualHost.
vallismortis
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.