TL;DR

SSLv3 está muerto. Configurar Apache con las siguientes directivas (generales, por VirtualHost no funciona del todo correctamente)

SSLProtocol all -SSLv2 -SSLv3

SSLHonorCipherOrder on

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA

Un año complicado

Este año está siendo movido para los administradores de servidores web. Primero fue Heartbleed y ahora Poodle. Vulnerabilidades diferentes que han puesto de manifiesto que no basta con activar HTTPS en un sitio web, hay que configurarlo correctamente. La parte positiva ha sido que muchos sysadmins hemos ganado este conocimiento y ahora disponemos de mejores herramientas y un procedimiento para configurar y mantener seguro un servicio HTTPS.

Configurando HTTPS

Ahora que ya somos conscientes que la configuración por defecto del servidor web puede no ser la ideal vamos a ver los cambios de configuración que debemos hacer actualmente.

SSLv2

Este protocolo ya está desactivado en todos los servidores modernos pero algunos siguen activos por ser configuraciones de hace algunos años y que no se revisan.

SSLv3

La última vulnerabilidad descubierta (POODLE) afecta directamente a este protocolo. Sin embargo, al contrario que con otras vulnerabilidades, se ha decidido no arreglar el protocolo. Se recomienda su desactivación.

Hasta hace poco este protocolo estaba vigente en casi todos los servidores. La razón principal es la compatibilidad. El caso principal es Internet Explorer sobre Windows XP. Qualquier versión de IE sobre XP sólo puede utilizar SSLv3. Así que su desactivación impide al acceso por HTTPS a usuarios de estas combinaciones. Teniendo en cuenta que XP ya no tiene soporte hace meses y que su uso va claramente a la baja.

CipherSuite

La elección del protocolo (SSLv3, TLSv1, TLSv1.1…) es sólo una parte del mecanismo de cifrado entre el navegador y el servidor. Hay otros parámetros como el algoritmo de hash de mensajes, el intercambio de claves, el algoritmo de cifrado… Toda esa serie de parámetros juntos conforman lo que se suele denominar CipherSuite del nombre del parámetro de configuración habitual en servidores web o la libreria OpenSSL.

En el servidor no podemos configurar una sola combinación sino que debemos proporcionar varias y el navegador y el servidor, durante el establecimiento del canal seguro, negocian un conjunto de parámetros concreto. Cuantas más opciones configuremos más navegadores soportaremos. Sin embargo hay conjuntos de parámetros más seguros que otros y algunos claramente inseguros.

No hay una solución óptima, cada entorno tendrá su solución adecuada. La que os pongo arriba es una solución correcta que incluye a la mayoría de los navegadores. Sin embargo en este blog utilizo una más estricta a cambio de perder más navegadores.

Una buena web con ejemplos y explicaciones se puede encontrar en la wiki de Mozilla.

Perfect Forward Secrecy (PFS)

La vulnerabilidad Heartbleed permite obtener las claves privadas de un certificado. Es el peor escenario de vulnerabilidad. Tener las claves privadas permite, entre otras cosas, descifrar mensajes pasados. Para que nos entendamos: capturamos y guardamos el tráfico encriptado antes de la vulnerabilidad o de tener la clave privada. En ese momento no sirve de nada, está cifrado. Pero llega la vulnerabilidad y obtenemos las claves privadas. Entonces podemos volver a ese antiguo tráfico capturado y descifrarlo.

Perfect Fordward Secrecy es un mecanismo para evitar esto. Citando la Wikipedia:

El término perfect forward secrecy (siglas PFS), traducido normalmente al castellano por secreto-perfecto-hacia-adelante, es la propiedad de los sistemas criptográficos que garantiza que el descubrimiento de las claves utilizadas actualmente no compromete la seguridad de las claves usadas con anterioridad (no las revela).

HTTP Strict Transport Security

Cada vez vemos que Internet se está expandiendo a más y más dispositivos (IoT) y la seguridad, ya importante, cada vez es más crucial. Utilizar exclusivamente HTTPS es una opción que, actualmente, se perfila casi como una necesidad.

Un ejemplo claro es el ataque del SSLStrip en el que un atacante intercepta nuestro tráfico y nos redirige a la versión HTTP de un servicio al que normalmente accedemos via HTTPS. Podemos además ocultarnos un poco enviando, por ejemplo, un favicon con un candado. “Si ves el candado, todo correcto”.

HSTS es el mecanismo que obliga a los navegadores a no aceptar una conexión HTTP a un sitio web, y usar HTTPS en su lugar siempre. Incluso si reciben un enlace para HTTP. Ni siquiera intenta ir por HTTP. Hay que implementarlo en el servidor pero es muy sencillo, tan sólo requiere enviar una cabecera con la respuesta HTTP.

Comprobando nuestra configuración

Bien, ya tenemos nuestro servidor web sin soporte SSLv2 ni SSLv3, con un buen conjunto de cifrados, que además soportan principalmente PFS, y además servimos nuestra aplicación por HTTPS forzado mediante HSTS. ¿Bien? Sí, por ahora. Podemos comprobarlo ahora y de manera periodica mediante esta completísima herramienta gratuita de los expertos en seguridad Qualys:

Qualys SSL Server Test

No hay que obsersionarse con sacar un 100 en todo ni un A+ porque no es un tema de configurar bien sino de tomar decisiones. ¿Quieres soportar Windows XP? No podrás tener puntuación muy alta. Se puede sacar un A- o A de manera relativamente sencilla y soportando muchos navegadores. Mención especial para Google (probad un test contra google.com) que parece encontrar la solución ideal (con servidores parcheados por sus expertos en seguridad, por supuesto).

Conclusión

El 2014 marca un punto de inflexión desde el punto de vista de la mayoría de sysadmins que han de mantener servidores web. Ya no sirve simplemente activar HTTPS. Y ahora somos conscientes.

Como lectura final recomiendo este artículo de Reset The Net.