El objetivo de este artículo es proveer una guía para mejorar la implementación de un servidor Web seguro utilizando SSL/TLS, particularmente el caso de servidores Apache con mod_ssl (OpenSSL). Se trata de un conjunto de buenas prácticas de seguridad en servidores SSL, junto con un par de herramientas interesantes para determinar en qué estado de seguridad se encuentra tanto nuestro servidor Web como nuestro cliente.



El protocolo SSL/TLS es una tecnología relativamente simple. Es fácil de implementar y casi siempre funciona correctamente, salvo que tengamos algún inconveniente con la cadena de certificación (por ejemplo, un certificado faltante, expirado, inválido, etc.) o la clave privada. Más allá de algún error de configuración común, siempre funcionará correctamente. Sin embargo el principal problema es que no siempre se implementa de forma correcta (segura). Para garantizar que TLS provea el nivel de seguridad necesario, los desarrolladores y administradores de sistemas debemos poner un esfuerzo adicional en la configuración de los servidores y el desarrollo de las aplicaciones.

A continuación se detallan una serie de buenas prácticas en la implementación de un servidor SSL/TLS.

Clave privada y certificado

La calidad de protección provista por TLS depende completamente de la clave privada, la cual es la base de la seguridad, y el certificado, el cual identifica a un servidor con sus clientes.

Utilizar claves privadas de 2048 bits

Las claves privadas de 2048 bits son seguras y deberían serlo por bastante tiempo. Si se poseen claves de 1024 bits, reemplazarlas por claves de 2048 bits lo antes posible. Si se requieren claves más robustas (de más de 2048 bits) es posible utilizar claves ECDSA.

Proteger las claves privadas

Considerar a las claves privadas como un recurso valioso, restringiendo el acceso al menor grupo posible de personas. Es recomendable generar la clave privada y el certificado en una computadora de confianza y no dejar que la CA se encargue de hacerlo por uno. Proteger las claves privadas con contraseña para que no sean vulnerables cunado se almacenan en medios de backup. Renovar los certificados cada año utilizando siempre nuevas claves privadas. En caso de compromiso, revocar todos los certificados y generar nuevas claves.

Asegurar la cobertura de todos los hostnames

Asegurarse de que los certificados cubran todos los nombres de dominio que se utilizan en el sitio, para evitar advertencias de certificados inválidos en los clientes. Aunque el sitio posea un sólo nombre de dominio, asegurarse de que el certificado funcione correctamente para las URL con y sin "www". Un servidor Web seguro debe tener un certificado válido para cada nombre DNS configurado para que apunte al mismo.

Evitar el uso de certificados wildcard, ya que se exponen las claves privadas subyacentes a un grupo grande de personas (a veces cruzando límites fuera de la organización). Cuanto menor cantidad de personas tengan acceso a la clave privada, más seguridad.

Obtener certificados de una CA confiable

Seleccionar una entidad certificante que se tome en serio el negocio de la seguridad. Examinar el historial de seguridad para determinar si la CA escogida tuvo brechas de seguridad y cómo reaccionaron a las mismas. Elegir una CA que tenga una cuota importante de mercado, donde la actividad de certificación constituya una parte primordial de su negocio.

Analizar los servicios ofrecidos por la CA escogida. Como mínimo debe proveer servicios para revocar certificados (CRL y OCSP) con buen rendimiento. Además debe ofrecer certificados validados por dominio o mediante validación extendida (EV), y debe permitir seleccionar el algoritmo de clave pública a utilizar (RSA o ECDSA).

Por otro lado, si es necesario gestionar una gran cantidad de certificados, elegir una CA que posea buenas herramientas de administración y buen soporte.

Utilizar algoritmos de firma robustos

La seguridad de la firma del certificado depende de la fortaleza de la clave privada firmante, y de la fortaleza de la función de hash utilizada. Actualmente muchos certificados utilizan la función SHA1, la cual es considerada débil y debe dejar de utilizarse antes de 2016. Utilizar certificados que se basen en la familia de algoritmos SHA2 (pero antes verificar que los clientes lo soporten, por ejemplo IE6 en Windows XP no lo soporta).

Configuración

Una configuración correcta del servidor TLS permite asegurar que las credenciales del sitio sean presentadas de forma adecuada a los clientes, que sólo se utilicen algoritmos criptográficos seguros, y que todas las debilidades conocidas son mitigadas.

Implementar cadenas de certificación válidas

En muchas implementaciones, sólo el certificado del servidor no es suficiente, generalmente se requiere adicionalmente uno o más certificados intermedios para establecer una cadena de confianza. Un error común es olvidar incluir algún certificado intermedio. También puede suceder que un certificado intermedio expire, lo que invalida toda la cadena. La CA debe encargarse de proveer todos los certificados adicionales requeridos.

Una cadena inválida vuelve inválido al propio certificado del servidor y resulta en warnings en los clientes. En la práctica este problema suele ser difícil de diagnosticar, ya que algunos navegadores tienen la capacidad de lidiar con este problema y reconstruir la cadena.

Utilizar protocolos seguros

Existen cinco protocolos en la familia SSL/TLS: SSL v2, SSL v3, TLS v1.0, TLS v1.1, y TLS v1.2. De los cuales:

  • SSL v2 es inseguro y no debe utilizarse.
  • SSL v3 es inseguro cuando se utiliza con HTTP, y débil cuando se utiliza con otros protocolos. Además es obsoleto.
  • TLS v1.0 es en mayor parte seguro. Cuando se utiliza con HTTP puede ser casi seguro si se configura de forma adecuada. No se conocen fallas de seguridad graves cuando se utiliza con otros protocolos.
  • TLS v1.1 y v1.2 no poseen vulnerabilidades conocidas.

TLS v1.2 debería ser el protocolo principal. Esta versión es superior ya que ofrece características no disponibles en versiones previas. Si el servidor no soporta TLS v1.2, se recomienda planificar una actualización. Para soportar clientes viejos, se debe continuar soportando TLS v1.0 y v1.1.

Utilizar suites de cifrado seguras

Para poder comunicarse de forma segura, antes es necesario asegurarse de que se está estableciendo la comunicación con el servidor deseado. En SSL y TLS las suites de cifrado se utilizan para definir cómo se realiza la comunicación segura. Están compuestas de varios bloques para alcanzar seguridad a través de diversidad. La meta segura consiste en utilizar sólo suites que provean autenticación y encriptación de 128 bits o más. Todo lo demás debe ser evitado: las suites Diffie-Hellman no proveen autenticación; las suites sin cifrado (NULL) no proveen encriptación; las suites export key exchange proveen autenticación fácilmente rompible; las suites con algoritmos de cifrado débiles (40 ó 56 bits) usan encriptación fácilmente rompible; RC4 es débil, debería dejar de ser soportado si no hay un impacto negativo en la interoperabilidad.

3DES provee 112 bits de seguridad, lo cual no es tan malo, pero es mucho más lento que otras alternativas. No se recomienda por cuestiones de performance, pero se puede mantener al final de la lista de algoritmos de cifrado soportados, por cuestiones de interoperabilidad.

Elección del algoritmo de cifrado

Desde SSL v3 en adelante, los clientes envían una lista de suites de cifrado soportadas, y los servidores eligen una suite de la lista para negociar un canal de comunicación seguro. No todos los servidores lo hacen bien, algunos seleccionan la primera suite de la lista, no la más segura. Configurar el servidor para que seleccione la suite adecuada es crítico para la seguridad de la implementación.

Soportar Forward Secrecy

Forward Secrecy es una característica del protocolo de cifrado que permite que las comunicaciones seguras no dependan de la clave privada del servidor. De no ser así, si alguien obtiene la clave privada puede desencriptar todas las comunicaciones anteriores (si posee acceso a las mismas, lógicamente).

Para esto es necesario soportar y preferir las suites ECDHE, y DHE para soportar un número mayor de clientes.

Deshabilitar la renegociación iniciada por el cliente

En SSL/TLS, la renegociación permite detener las comunicaciones para cambiar la forma en la que se realizan (de forma segura). No hay necesidad por la cual un cliente debería iniciar una renegociación, y de permitirse puede volver al servidor blanco de ataques DoS.

Mitigar problemas conocidos

Estar al tanto de lo que sucede en el mundo de la seguridad de la información es una buena práctica para adaptarse rápidamente a las vulnerabilidades que van descubriendo. Como mínimo, los parches de seguridad se deben aplicar lo más rápido posible.

  • Deshabilitar la renegociación: esta característica se descubrió insegura en 2009).
  • Deshabilitar la compresión en TLS: el ataque CRIME demostró como es posible filtrar información sensible desde este mecanismo.
  • Deshabilitar RC4: esta suite es insegura y debe deshabilitarse. A pesar de que el riesgo es bajo (se requieren millones de solicitudes, mucho ancho de banda y tiempo), es posible que en un futuro los ataques sean más eficientes. Verificar el impacto antes de deshabilitarlo (no tener clientes que sólo soporten RC4).
  • Estar consciente del ataque BEAST: similar a un secuestro se sesión, el cual afecta a TLS 1.0. Desafortunadamente para mitigar este ataque desde el lado servidor es necesario utilizar RC4, el cual no se recomienda. si hay un gran número de clientes que sólo soportan RC4, tal vez sea más seguro utilizar TLS v1.0 con RC4. Se debe tomar una decisión por un esquema u otro cuidadosamente entendiendo completamente el entorno y su modelo de riesgo.
  • Deshabiltiar SSL v3: este protocolo es vulnerable al ataque POODLE, el cual puede lograr que los clientes ejecuten malware JavaScript.

Rendimiento

Un servicio seguro que no posee un buen rendimiento, sin dudas terminará siendo dejado de lado, por lo tanto se debe prestar atención a la eficiencia y performance del servicio. TLS generalmente no tiene un impacto significativo en el rendimiento, por lo tanto sólo se debe prestar atención a algunos problemas de configuración comunes que pueden resultar en degradación de la performance.

No utilizar excesiva seguridad

El handshake criptográfico utilizado para establecer conexiones seguras, es una operación cuyo costo está influenciado por el tamaño de la clave privada. Utilizar una clave muy corta es inseguro, pero utilizar una clave excesivamente larga resultará en una degradación de la performance. Para la mayoría de los sitios, utilizar claves RSA de más de 2048 bits, o claves ECDSA de más de 256 bits, es un desperdicio de CPU y puede afectar la experiencia del usuario. Por otro lado hay poco beneficio en incrementar la longitud de la clave más allá de 2048 bits para DHE y 256 bits para ECDHE.

Asegurarse de que el mecanismo de session resumption funcione correctamente

Esta técnica de optimización del rendimiento permite guardar los resultados de operaciones criptográficas costosas en tiempo de ejecución, para ser reutilizados por un período de tiempo. Si este mecanismo está deshabilitado o no funciona correctamente se pueden introducir severas penalizaciones en el rendimiento.

Utilizar conexiones HTTP persistentes

Actualmente, la mayor sobrecarga de TLS no surge de las operaciones criptográficas sino de la latencia de red. Esto se debe a que el handshake de TLS comienza recién luego de finalizar el handshake TCP, lo que requiere un intercambio adicional de paquetes. Para minimizar el costo de latencia, es recomendable habilitar persistencia en las conexiones HTTP (keep-alives), para que los usuarios puedan enviar varios pedidos sobre una misma conexión TCP.

Habilitar caché para recursos públicos HTTP

Al comunicarse sobre TLS, los navegadores asumen que todo el tráfico es sensible. Por lo tanto utilizan típicamente algo de memoria para caché de recursos, pero al cerrar el navegador, todo el contenido posiblemente se pierda. Para mejorar el rendimiento y permitir caché a largo termino de algunos recursos, marcar los recursos públicos (por ejemplo, imágenes, hojas de estilo, scripts) como públicos agregando el encabezado Cache-Control: public en la respuesta HTTP.

Utilizar OCSP Stapling

OCSP Stapling es una modificación al protocolo OCSP que permite enviar información de revocación como parte del handshake TLS, directamente desde el servidor al browser. De esta forma se reducen ampliamente los tiempos de conexión ya que el browser no necesita contactar a ningún servidor OCSP para verificar la validez del certificado enviado por el servidor.

Diseño de la aplicación HTTP

El protocolo HTTP ha evolucionado rápidamente desde que surgió SSL. Como resultado, ahora existen características que pueden ser utilizadas para evitar los mecanismos de encripción.

Encriptar el 100% del sitio

El hecho de que la encriptación sea opcional es probablemente uno de los más grandes problemas de seguridad en la actualidad. Por ejemplo: existen sitios que no soportan TLS cuando deberían (formularios de acceso, cookies de sesión, etc.); sitios que soportan TLS pero de forma opcional (no redirigen automáticamente a HTTPS, notablemente muchos sitios de Home Banking); páginas que mezclan contenido seguro (HTTPS) con contenido no encriptado (aunque actualmente muchos navegadores advierten esta situación); y sitios con errores de programación que permiten corromper o deshabiltiar TLS.

A pesar de que muchos de estos problemas pueden mitigarse, la única forma confiable de proteger las comunicaciones de un sitio Web consiste en forzar la encripción mediante TLS.

Evitar contenido mixto

Las páginas con contenido mixto son aquellas que son transmitidas sobre TLS pero incluyen recursos (JavaScript, imágenes, hojas de estilo) que son transmitidas de forma insegura (a través de HTTP plano). Tales páginas son inseguras. Un atacante puede montar un ataque man-in-the-middle (MITM) y reemplazar un simple recurso JavaScript para secuestrar una sesión (al ejecutarse en el cliente, el malware JavaScript puede obtener y enviar cualquier dato desencriptado).

Prestar especial atención a recursos obtenidos de sitios de terceros, particularmente desde redes sociales (widgets, botones, badges, etc.).

Comprender los riesgos de confiar en servicios de terceros

La mayoría de los sitios Web utilizan servicios de terceros activados mediante código JavaScript descargado desde otros servidores. Un buen ejemplo son los servicios de Google Analytics y Google AdSense. La inclusión de código JavaScript de terceros implica una relación de confianza implícita, que le da a los mismo total control sobre nuestros sitios Web. Estas terceras partes lógicamente no son maliciosas, pero cada vez más están siendo vistas como blanco de ataques. Esto se debe a que si un atacante compromete al proveedor de servicios, automáticamente logra acceso a todos los sitios que dependen del mismo. Imagínense las implicancias si un atacante logra infectar con malware código JavaScript hospedado en un servidor de Google Analytics.

Por lo tanto, además de forzar HTTPS para todo contenido de terceros (para evitar ataques MITM), verificar qué servicios que se están utilizando para reemplazarlos por otros más seguros, o aceptar el risgo y continuar su uso (siendo consciente de esta relación de confianza, y estando siempre al tanto de posibles brechas de seguridad en los mismos).

Proteger las cookies

Para ser completamente seguro, además de requerir TLS, un sitio Web debe marcar todas sus cookies como seguras. Si no se protegen adecuadamente, un atacante puede obtener algo de información encriptada montando ataques MITM.

Habilitar HSTS

HTTP Strict Transport Security es una extensión de seguridad para TLS diseñada para garantizar que la seguridad permanece intacta incluso en el caso de problemas de configuración y errores de implementación. Para activar la protección HTST basta con configurar un header de respuesta en los sitios Web. Luego, los navegadores que soporten HTST (actualmente Chrome, Firefox, Safari, y Opera) lo forzarán automáticamente.

La meta de HSTS es simple: no permitir ningún tipo de comunicación insegura con el sitio que lo utiliza. Para lograrlo, convierte automáticamente todos los enlaces en texto plano a su versión segura (https://). Además impide continuar con un simple clic ante advertencias de seguridad de certificados (estudios han demostrado que los usuarios simplemente ignoran estas advertencias, lo cual suelen ser un indicador de un ataque MITM).

Deshabilitar caché para contenido sensible

Asegurarse de que el contenido sensible se comunica sólo a las partes interesadas y es tratado como sensible. A pesar de que los servidores proxy no ven el tráfico encriptado, y no pueden compartir su contenido entre usuarios, el uso de aplicaciones basadas en la nube requiere cuidado al momento de especificar qué es público y qué no.

Validación

Con tantos parámetros disponibles para ajustar es difícil conocer por adelantado qué impacto tendrá cierto cambio. Por otro lado, muchos cambios se aplican accidentalmente, por ejemplo al aplicar actualizaciones. El sitio Qualys SSL Labs posee un conjunto de herramientas interesantes para analizar el nivel de seguridad de la implementación de SSL/TLS en sitios Web públicos.

SSL Server Test

La herramienta SSL Server Test es un servicio online que permite inspeccionar la configuración de cualquier servidor SSL público. Se encarga de verificar la implementación de diferentes protocolos (SSL, TLS); validez del certificado; renegociación; reutilización de sesiones; suites de cifrado disponibles, obsoletas y poco comunes; vulnerabilidad a ataques BEAST y POODLE; OCSP Stapling; simulación de handshakes de diferentes; etc.

Con toda la información que recopila elabora un reporte detallado y asigna una calificación de la A (excelente) a la F (desastroso) de acuerdo a la configuración del servidor y a las vulnerabilidades encontradas.

Por ejemplo, para linuxito.com presenta el siguiente reporte:

La calificación para linuxito.com es B (bastante bien GoDaddy). Se debe principalmente a que soporta TLS v1.0 t TLSv1.1:

Si deshabilitara estos protocolos, muy seguramente la calificación sería A.

Esta herramienta es muy útil para darnos un pantallazo de cómo está la implementación de SSL en nuestros servidores. Lo alarmante, es probar esta misma herramienta contra los servidores de Home Banking que utilizamos a diario. Muchos bancos y entidades financieras tiene calificaciones F, lo que implica que son vulnerables a todos los ataques que existen hasta el momento.

Es preocupante cómo los bancos dejan la administración y desarrollo de sistemas críticos (sistemas que manejan dinero) en manos de ineptos, y cómo sus usuarios estamos en peligro constante cada vez que utilizamos estas herramientas. Si no son blanco de ataques más frecuentemente, es sólo porque las implicancias de ejecutar un ataque contra un banco o entidad financiera son muy altas en términos legales.

SSL Client Test

La herramienta SSL Client Test permite verificar las capacidades SSL/TLS que posee el browser que estamos utilizando.

Por ejemplo, mi navegador Mozilla Firefox (actualizado a la versión 33.0) está muy bien protegido contra todos los ataques contra SSL/TLS:

Se observa que no soporta SSL ni TLS < v1.2:

El único detalle es que soporta el algoritmo RC4, supongo que compatibilidad con muchos sitios Web desactualizados, lo que le baja levemente la calificación. Se trata evidentemente de un tradeoff entre seguridad versus usabilidad.

Esta herramienta puede darnos tranquilidad en que, de nuestro lado, hacemos todo lo posible para que las sesiones TLS sean seguras, o puede servirnos como alerta para actualizar o cambiar el browser.

Cómo mejorar la configuración de SSL en servidores Apache

Respecto al certificado, el punto más importante es la longitud de la clave. Utilizar siempre claves de 2048 bits RSA. Por supuesto es importante proteger bien la clave privada, e indispensable completar la cadena de certificación (no olvidarse de ningún certificado intermedio).

El resto de las características de seguridad respecto al certificado dependerán mucho de la CA elegida. Por ejemplo, el algoritmo utilizado para la firma y el tipo de mecanismo que utiliza para mantener la información de revocación (CRL y OCSP). Lógicamente la CA debe ser de confianza. Cabe destacar que estos puntos valen para todos los certificados en la cadena (no sólo el certificado del servidor).

En cuanto a la configuración del servidor SSL, la mayoría de los ataques se evitan simplemente deshabilitando SSLv2 y SSLv3, y seleccionando cuidadosamente las suites de cifrado soportadas (para filtrar aquellas que sean inseguras).

Por ejemplo, en Apache 2, editar el archivo de configuración del módulo ssl:

# nano /etc/apache2/mods-available/ssl.conf

Y agregar (o modificar si ya existen) las siguientes opciones de configuración:


# Deshabilitar SSLv2 y SSLv3
SSLProtocol all -SSLv2 -SSLv3

# Preferir las suites de cifrado más seguras (en orden)
SSLHonorCipherOrder On

# Permitir sólo las siguientes suites de cifrado
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:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384: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-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DHE-DSS-AES256-SHA256:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:CAMELLIA128-SHA:DES-CBC3-SHA

Para deshabilitar la compresión TLS (con el fin de evitar el ataque CRIME) debe contarse con una versión de Apache superior a 2.2.14 (para la rama 2.2) o 2.4.3 (para la rama 2.4). Luego se debe agregar la siguiente línea de configuración en el archivo de configuración del módulo mod_ssl, ssl.conf:


# Deshabilitar compresión TLS
SSLCompression Off

A partir de la versión 2.4.4 viene desactivado por defecto.

El resto de las características soportadas por el servidor SSL (por ejemplo Forward Secrecy) dependerán de la versión de OpenSSL o LibreSSL utilizada. Se recomienda mantener siempre estos paquetes actualizados a la última versión disponible en los repositorios.

Para el caso particular de la configuración de OCSP Stapling, remitirse a la documentación de Apache: SSL/TLS Strong Encryption: How-To - OCSP Stapling.

Referencias

Qualys SSL Labs - SSL/TLS Deployment Best Practices

Apache HTTP Server Version 2.4 - SSL/TLS Strong Encryption: How-To

Vincent Bernat - Speeding up SSL: enabling session reuse

Hynek Schlawack - Hardening Your Web Server’s SSL Ciphers

Acunetix - Recommendations for TLS/SSL Cipher Hardening

bettercrypto.org - AppliedCryptoHardening


Tal vez pueda interesarte


Compartí este artículo