background_header


ACTUALIZACIÓN 08/2016: Se ha agregado el servicio “Observatory” de la Fundación Mozilla para la validación de configuración HTTPS.

ACTUALIZACIÓN 01/2016: Se ha agregado el ataque “logjam” (CVE-2015-4000) dentro del índice de vulnerabilidades críticas de SSL/TLS y diferentes páginas de referencia para validación. Adicionalmente, se han listado nuevas URL con descripciones de configuración segura de cifrados en diferentes servicios y aplicaciones para automatización en la elección de cifrados fuertes para Microsoft IIS.

ACTUALIZACIÓN 10/2015: Se han agregado nuevas URL de servicios de comprobación de configuración de SSL y TLS y guías de configuración para servidores web, como parte de las tareas dentro de los planes de mitigación de riesgos y migración de SSL conforme con PCI DSS v3.1.

ACTUALIZACIÓN 03/2015: Se ha publicado una nueva vulnerabilidad denominada FREAK (Factoring Attack on RSA-EXPORT Keys) bajo el CVE-2015-0204. Esta vulnerabilidad permite atacar los protocolos SSL/TLS y debe ser mitigada cuando antes. Este artículo ha sido actualizado con las instrucciones que se deben seguir. Recomendamos a nuestros lectores actualizar los componentes de SSL/TLS a las últimas versiones disponibles. Más información aquí. Un análisis técnico de esta vulnerabilidad y la explicación de su explotación se pueden encontrar aquí.

ACTUALIZACIÓN 09/03/2015: La Fundación Mozilla ha desarrollado una Wiki en la cual describe una serie de configuraciones para la implementación de TLS en diversos servidores. Así mismo, cuenta con una herramienta para la generación en línea de configuraciones con base en las parametrizaciones del usuario. Invitamos a todos nuestros lectores a revisarlo.


SSL (Secure Sockets Layer) es un protocolo criptográfico desarrollado por Netscape para proporcionar confidencialidad e integridad en la comunicación de datos entre dos extremos. Su primera versión (SSL v1) nunca fue publicada debido a una gran cantidad de fallos en su desarrollo, mientras que las versiones posteriores (que corregian dichos problemas) datan de 1995 (SSL v2) y 1996 (SSL v3 – RFC 6101).  En Enero de 1999 fue publicada la RFC 2246  que definia las bases para el protocolo que remplazaría a SSL: Transport Layer Security (TLS) v1.0. Esta nueva especificación traía consigo múltiples mejoras en términos de operación con primitivas criptográficas y desempeño. Siete años más tarde (en 2006) se publicó la versión 1.1 de TLS bajo la RFC 4346  y en 2008 con la RFC 5246 se vería la versión más actual de TLS, la versión 1.2. Hasta ese momento las implementaciones de SSL y TLS eran compatibles entre sí (“backward compatibility”), lo cual bloqueaba el desarrollo autónomo de algunas características de seguridad de TLS, por lo que en el 2011 con la RFC 6176 se prohibía la negociación entre TLS y la versión 2.0 de SSL y ambas implementaciones se independizaban.

A lo largo de 20 años después de la primera implementación oficial de SSL se han identificado una serie de vulnerabilidades que afectan seriamente a los niveles de seguridad provistos por estos protocolos, siendo algunas de las más notables las siguientes (en orden de aparición):

  • BEAST (“Browser Exploit Against SSL/TLS”) – CVE-2011-3389
  • CRIME (“Compression Ratio Info-leak Made Easy”) – CVE-2012-4929
  • BREACH (“Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext”)
  • HEARTBLEEDCVE-2014-0160
  • POODLE (“Padding Oracle On Downgraded Legacy Encryption”) – CVE-2014-3566
  • FREAK (“Factoring Attack on RSA-EXPORT Keys”) – CVE-2015-0204
  • logjamCVE-2015-4000

Una línea de tiempo de la historia y vulnerabilidades de SSL y TLS se puede encontrar en la página “SSL/TLS and PKI History“.

No obstante – y a pesar de estas vulnerabilidades – el estándar PCI DSS v3.0 cita de forma explícita el uso de SSL como un protocolo “seguro” para la protección durante el transporte de datos de tarjetas de pago en los requerimientos 1.1.6.a,  2.2.3, 2.3 y 4.1. A pesar de ello, es muy importante que se tenga presente la necesidad de actualizar las guías de configuración seguras (req. 2.2.b) y la actualización/configuración continua de componentes con base en las vulnerabilidades de seguridad publicadas (req. 6.1) con el fin de gestionar de forma correcta los potenciales riesgos derivados de estos problemas que podrían afectar seriamente tanto el cumplimiento con PCI DSS así como la seguridad de los datos de tarjeta transmitidos. Por otro lado, todas estas vulnerabilidades al ser detectadas son reportadas como PCI FAIL en escaneos ASV (req. 11.2.2), justificación adicional para proceder de forma inmediata con la corrección de estos problemas.

Para ello, a continuación se enumeran una serie de acciones recomendables para mitigar estos problemas:

  • Actualizar a la versión más reciente todos los componentes de SSL o TLS existentes en el entorno (prestar especial atención a OpenSSL, cuyas versiones desde la 1.0.1 hasta la 1.0.1f (inclusive) son afectadas por la vulnerabilidad HeartBleed)
  • Emplear algoritmos robustos en las configuraciones de cifrado de SSL/TLS (evitar el uso de Triple-DES CBC, RC4, MD5 y SHA-1)
  • En aquellos servicios que lo soporten, activar TLS Fallback Signaling Cipher Suite Value (SCSV) para prevenir la renegociación con protocolos débiles
  • Habilitar el soporte de HTTP Strict Transport Security (HSTS) en los servicios que lo soporten
  • Configurar Perfect Forward Secrecy (PFS) en donde sea soportado (ver aquí)
  • Habilitar el soporte para Elliptic-Curve Diffie-Hellman (ECDH) en el intercambio de claves y utilizar grupos de Diffie-Hellman como mínimo de 2048-bit para evitar ataques de logjam.
  • Configurar los browsers de usuarios para deshabilitar el soporte de SSL (ver https://zmap.io/sslv3/browsers.html y https://www.digicert.com/ssl-support/disabling-browser-support-ssl-v3.htm)

Así mismo, una acción altamente recomendable es deshabilitar completamente el soporte de SSL en los servidores, habilitar TLS y configurarlo de forma segura. Esta acción debe ser analizada detalladamente en cada caso, ya que puede afectar la conectividad de browsers de clientes que no tengan soporte de TLS. La forma de deshabilitar SSL en diferentes servicios se detalla a continuación:

Apache Web Server

Para Apache httpd version 2.2.23 y superiores, se requiere especificar el uso de TLS y deshabilitar SSL v2 y SSL v3:

Para Apache 2.2.22 y anteriores, simplemente especificar el uso de TLSv1

Forzar el uso de algoritmos seguros y el orden de preferencia (ejemplo):

Deshabilitar el uso de compresión:

Activar los encabezados HSTS:

Con el fin de evitar la exportación de suites de cifrado, se recomienda agregar esta línea en la configuración de Apache. Esta contramedida sirve para minimizar el impacto de ataques tales como FREAK:

Al finalizar estos cambios, ejecutar el siguiente comando para que el servidor aplique la nueva configuración:

NginX Web Server

Agregar o modificar la siguiente línea en el fichero de configuración:

Forzar el uso de algoritmos seguros y el orden de preferencia (ejemplo):

Se recomienda agregar la siguiente línea en el archivo de configuración para evitar la exportación de las suites de cifrado disponibles y minimizar el efecto de ataques como FREAK:

Al finalizar estos cambios, ejecutar el siguiente comando para que el servidor aplique la nueva configuración:

Internet Information Server (IIS)

Para Internet Information Server (IIS) es necesario crear/modificar una serie de claves de registro. La forma más fácil es crear un fichero con extensión .reg con el siguiente contenido:

Posterior a ello y con privilegios de administrador, ejecutarlo.

Para corregir la vulnerabilidad FREAK, Microsoft ha puesto a disposición una serie de instrucciones que deben ser implementadas por el administrador de la plataforma: Vulnerability in Schannel Could Allow Security Feature Bypass

Para automatizar la configuración de algoritmos seguros en IIS se puede hacer uso de la herramienta gratuita Nartac IIS Crypto.

Más información en https://www.digicert.com/ssl-support/iis-disabling-ssl-v3.htm y en https://support.microsoft.com/kb/187498/en-us

Lighttpd Web Server

Para Lighttpd versión 1.4.29 y posteriores, agregar las siguientes líneas en el fichero de configuración:

 Activar los encabezados HSTS:

Al finalizar estos cambios, ejecutar el siguiente comando para que el servidor aplique la nueva configuración:

Sendmail Mail Server

Agregar las  siguientes líneas en el fichero de configuración sendmail.mc en el apartado LOCAL_CONFIG:

Al finalizar estos cambios, ejecutar el siguiente comando para que el servidor aplique la nueva configuración:

Postfix Mail Server

Agregar o modificar las siguientes líneas en el fichero de configuración:

Forzar el uso de algoritmos seguros y el orden de preferencia (ejemplo):

Al finalizar estos cambios, ejecutar el siguiente comando para que el servidor aplique la nueva configuración:

Courier-imap Mail Server

Agregar o modificar las siguientes líneas en el fichero de configuración:

Al finalizar estos cambios, ejecutar el siguiente comando para que el servidor aplique la nueva configuración:

Otras páginas de referencia con información adicional son:

Adicionalmente, en el sitio web Cipherli.st se encuentran ejemplos de configuraciones adicionales para diferentes servicios (Apache, Nginx, Lighttpd, Exim, MySQL, PostgreSQL, OpenSSH, etc.)

¿Cómo validar si mi servidor web es vulnerable?

Existen múltiples sitios web que permiten validar si un servidor en particular es susceptible a alguna de las vulnerabilidades descritas anteriormente. Algunos de ellos son:

Específicamente para PCI DSS, se puede hacer una evaluación de cumplimiento a través del servicio de High-Tech Bridge SSL/TLS Server Configuration, que también ofrece resultados de alineación con otros estándares como NIST 800-52.

Por otro lado, se puede emplear alguna de las siguientes herramientas específicas para la detección de estas vulnerabilidades:

Empleando nmap también se puede obtener la información de los algoritmos de cifrado permitidos en un puerto que soporte SSL para validar su configuración:

Dentro de los scripts de nmap se pueden encontrar scripts específicos para revisar si el servidor web es vulnerable a ataques como HeartBleed:

En la página “Testing for Weak SSL/TLS Ciphers, Insufficient Transport Layer Protection (OTG-CRYPST-001)” de la OWASP se pueden encontrar múltiples herramientas para la validación de configuración de SSL y TLS que pueden ser útiles durante la definición de planes de migración y mitigación de riesgos de acuerdo con PCI DSS v3.1.

¿Cómo validar si browser es vulnerable?

Para validar si su browser puede ser vulnerable, puede usar alguno de los siguientes sitios web:

¿Le ha gustado este artículo? Compártalo con sus colegas en Twitter, LinkedIn, Facebook, Google+ y vía RSS. ¿Tiene alguna duda? Le invitamos a participar en el foro o dejar un comentario en este artículo.