¿Qué tipo de ataques previene SSL?

SSL/TLS evita la interceptación, la manipulación y la suplantación de identidad al cifrar los datos en tránsito y verificar la identidad del servidor mediante un certificado digital, aunque las implementaciones mal configuradas o desactualizadas siguen siendo vulnerables a ataques específicos de degradación y de protocolo.

SSL/TLS impide que los atacantes lean o modifiquen datos en tránsito y suplanten la identidad de un servidor de confianza, protegiendo contra la interceptación de comunicaciones, los ataques de intermediario y la manipulación de datos. Sin embargo, no previene automáticamente ataques a nivel de protocolo como POODLE, FREAK o Logjam, que explotan versiones obsoletas, conjuntos de cifrado débiles o configuraciones incorrectas en lugar de romper el cifrado directamente.

Puntos Clave

• TLS 1.3, definido en el RFC 8446, es el estándar de seguridad actual. SSL y TLS 1.0/1.1/1.2 están obsoletos; las versiones anteriores siguen siendo vulnerables a ataques de degradación como POODLE.
• La mayoría de los ataques conocidos contra SSL/TLS explotan la configuración, no el protocolo en sí. POODLE, FREAK, Logjam y DROWN dependen de un servidor que aún admite protocolos obsoletos o conjuntos de cifrado débiles junto con TLS 1.3.
• Los fallos en el ciclo de vida de los certificados provocan tantos incidentes como los ataques a los protocolos. Los certificados caducados, autofirmados o comprometidos que no han sido revocados crean vulnerabilidades que permiten ataques de intermediario (man-in-the-middle) que no tienen nada que ver con el protocolo de enlace TLS en sí.
• Los certificados comodín no deben cubrir subdominios sensibles. Una única clave comodín comprometida puede exponer todos los subdominios que abarca, incluidas las páginas de inicio de sesión y de pago.
• Deshabilitar la compatibilidad con protocolos heredados elimina la mayoría de los vectores de ataque conocidos. Al admitir únicamente TLS 1.2 y TLS 1.3, con conjuntos de cifrado modernos, se eliminan POODLE, FREAK, Logjam y BEAST como ataques viables.

SSL frente a TLS

TLS es el sucesor directo de SSL, y TLS 1.3 es la versión actual, la más segura y de uso generalizado en la actualidad.

TLS 1.3 se define en la RFC 8446 y protege el protocolo de enlace contra ataques de degradación que afectaban a versiones anteriores. SSL y TLS 1.0/1.1 están obsoletos en los principales navegadores debido a vulnerabilidades conocidas, y TLS 1.2 sigue siendo compatible, pero se está eliminando gradualmente en favor de la versión 1.3.

Ataques comunes a SSL/TLS y cómo mitigarlos

Seis ataques específicos representan la mayoría de las técnicas históricas de explotación de SSL/TLS, y cada uno tiene una solución concreta y bien documentada.

Ataque	Lo que explota	Mitigación
CANICHE	Vulnerabilidad de Oracle por relleno SSLv3	Deshabilitar SSLv3; solo se admite TLS 1.2 o superior.
FREAK	Conjuntos de cifrado RSA débiles para exportación	Deshabilitar la compatibilidad con conjuntos de cifrado de grado de exportación
Atolladero	Grupos Diffie-Hellman de 512 bits con calidad de exportación	Deshabilitar los conjuntos de cifrado Diffie-Hellman de grado de exportación
AHOGAR	Servidores que aún admiten SSLv2	Asegúrese de que las claves privadas nunca se utilicen en servidores habilitados para SSLv2.
Sweet32	Cifrados de bloques de 64 bits en modo CBC	Deshabilitar los cifrados heredados de 64 bits como DES y 3DES.
BESTIA	Fallo en la implementación de CBC en TLS 1.0	Utilice navegadores y servidores que admitan TLS 1.1 o superior.

Cada uno de estos ataques apunta a una característica específica de un protocolo heredado o a un conjunto de cifrado débil, en lugar de romper directamente TLS 1.3, razón por la cual deshabilitar la compatibilidad con protocolos heredados los desactiva casi todos a la vez.

Ataques que explotan la gestión de certificados, no el protocolo.

Los ataques de intermediario suelen tener éxito debido a una mala gestión de los certificados, más que a un fallo en el propio TLS.

• Certificados autofirmados en producción. Un certificado autofirmado no cuenta con validación independiente y debe limitarse a entornos de prueba, nunca a sistemas de producción.
• Certificados comprometidos no revocados. Un certificado que debería haber sido revocado tras una vulneración de claves sigue siendo utilizable por un atacante hasta que sea revocado realmente, no solo reemplazado.
• Autoridades de certificación no confiables o desconocidas. Los certificados emitidos por autoridades de certificación desconocidas y no auditadas conllevan un riesgo si dicha autoridad se ve posteriormente comprometida o suplantada.
• Eliminación de SSL y secuestro de sesión. Estos ataques engañan al usuario para que establezca una conexión sin cifrar o roban un ID de sesión activo, en lugar de atacar directamente el cifrado; HSTS y las banderas de cookies seguras son las defensas estándar.

Reducción de la superficie de ataque SSL/TLS

Un pequeño conjunto de opciones de configuración cierra la mayor parte de la superficie de ataque descrita anteriormente.

• Evite utilizar certificados comodín en subdominios sensibles. Utilice certificados individuales para los subdominios de inicio de sesión, pago y administración, de modo que una única clave comprometida tenga un alcance limitado.
• Evite las autoridades de certificación desconocidas o que no sean de confianza. Identifique todas las autoridades de certificación (CA) en uso y reemplace los certificados de fuentes desconocidas por certificados de autoridades de certificación confiables y auditadas.
• Mantenga actualizados los ciclos de vida de los certificados. Los certificados caducados siguen siendo una de las causas más comunes de interrupciones del servicio y de vulnerabilidades ante ataques de intermediario (MITM).
• Habilitar HSTS. HTTP Strict Transport Security obliga a los navegadores a utilizar HTTPS Por defecto, se cierra la solicitud inicial no cifrada de la que depende el filtrado SSL.

Ataques de vulnerabilidad SSL/TLS

Al igual que con otros protocolos, los protocolos SSL/TLS también presentan sus propias fallas. A continuación, se presentan ataques que afectan a SSL/TLS 1.2 y versiones anteriores.

• Ataque de la BESTIA

  Los ataques BEAST (Browser Exploit Against SSL/TLS) afectan a SSL 3.0 y TLS 1.0 al explotar la vulnerabilidad (CVE-2011-3389). En este ataque, el atacante puede explotar una vulnerabilidad en la implementación de CBC (cipher block chaining) en TLS 1.0. Esto le permite descifrar los datos cifrados entre dos usuarios/sistemas inyectando los paquetes manipulados en flujos TLS mediante técnicas MITM.

  Estas técnicas permiten al atacante adivinar el vector de inicialización utilizado con el mensaje inyectado. Posteriormente, puede comparar los resultados con los del bloque que desea descifrar. Este ataque requiere acceso al navegador del equipo del cliente (víctima). Para ejecutarlo con éxito, el atacante podría usar otros vectores de ataque en las etapas iniciales. Para contrarrestar este ataque, utilice navegadores compatibles con TLS 1.1 o superior.

• Ataque del CRIMEN

  En los ataques CRIME (Filtración de información sobre la relación de compresión facilitada), se explota el mecanismo de los algoritmos de compresión, cubierto por la vulnerabilidad (CVE-2012-4929). Generalmente, el método de compresión se incluye en el mensaje de saludo del servidor en respuesta al mensaje de saludo del cliente para reducir el ancho de banda requerido para el intercambio de datos. Para facilitar este proceso, el servidor envía el método de compresión (DEFLATE es el más común) al cliente, mientras que envía el método de compresión "NULL" si no se requiere compresión.

  Una de las principales técnicas utilizadas por los algoritmos de compresión consiste en reemplazar las secuencias de bytes repetidas en el mensaje con un puntero a la primera instancia de dicha secuencia. Cuanto mayor sea la repetición de las secuencias, mayor será la tasa de compresión. Para solucionar este ataque, utilice su navegador para que sea compatible con el protocolo TLS más reciente (TLS 1.3).

• Ataque BREACH

  El ataque BREACH (Reconocimiento y Exfiltración del Navegador mediante la Compresión de Hipertexto) busca explotar el mecanismo de compresión utilizado por HTTP en lugar de TLS, como ocurre en los ataques CRIME. Esta vulnerabilidad figura en la base de datos NIST NVD como CVE-2013-3587. Puede explotarse incluso con la compresión TLS desactivada. Esto se logra redirigiendo el tráfico del navegador del cliente (víctima) a cualquier URL de terceros con TLS habilitado y monitorizando el tráfico entre el servidor y el cliente mediante técnicas de ataque MITM. Los servidores web que utilizan compresión HTTP reflejan las entradas/secretos del usuario en los cuerpos de respuesta HTTP y son propensos a ser vulnerables. Para controlar esta vulnerabilidad, puede desactivar la compresión a nivel HTTP, separar los secretos de las entradas del usuario y enmascarar los secretos.

• Ataque de sangrado del corazón

  Heartbleed fue un ataque crítico que descubrió la vulnerabilidad en la extensión Heartbeat de la biblioteca openssl y figura en la base de datos NIST NVD como CVE-2014-0160. La extensión Heartbeat se utiliza para mantener una conexión activa mientras ambas partes permanezcan conectadas.

  Comprendamos la funcionalidad Heartbleed en la biblioteca OpenSSL. El cliente envía el mensaje de latido con los datos y el tamaño al servidor. El servidor responde con los datos recibidos y el tamaño del cliente. La vulnerabilidad Heartbleed buscaba explotar que, si el cliente enviaba una longitud de datos falsa al servidor, este respondía con datos aleatorios de su memoria para cumplir con el requisito de longitud especificado por el cliente.

  Los datos aleatorios sin cifrar de la memoria del servidor pueden contener información crítica, como claves privadas, datos de tarjetas de crédito y otra información confidencial. Para corregir la vulnerabilidad Heartbleed, actualice a la última versión de la biblioteca openssl o recompile la versión instalada con el indicador "DOPENSSL_NO_HEARTBEATS".

¿Cómo protegerse de los ataques SSL?

Como se explicó en las secciones anteriores sobre algunos de los ataques SSL más comunes, es importante que las organizaciones revisen sus políticas de seguridad relacionadas con la protección SSL. Implementar SSL o TLS por sí solo no garantiza la seguridad de su infraestructura ni de su negocio. En cambio, debe gestionarse con las políticas, los procesos y los procedimientos adecuados para minimizar los riesgos. Además, existen diversas técnicas y herramientas disponibles en el mercado para proteger su empresa. Sin embargo, la selección de dichas herramientas o productos de seguridad depende de la naturaleza y los objetivos de seguridad de su empresa y debe decidirse tras un análisis exhaustivo de todos los aspectos de la seguridad.

¿Cómo puede ayudar la consultoría de cifrado?

CertSecure Manager reduce el riesgo asociado a la gestión de certificados SSL/TLS mediante la automatización de la detección, revocación y renovación, evitando así que los certificados caducados, autofirmados o no revocados permanezcan en producción. Los Servicios de Asesoramiento en Cifrado de Encryption Consulting evalúan la configuración del protocolo y del conjunto de cifrado para minimizar la superficie de ataque restante relacionada con protocolos heredados y degradaciones. Respaldado por las prácticas certificadas ISO/IEC 27001:2022 y SOC 2.

Preguntas frecuentes

¿Garantiza SSL/TLS que un sitio web sea completamente seguro?

No. SSL/TLS cifra los datos en tránsito y verifica la identidad del servidor, pero no protege contra todas las amenazas. Servidores mal configurados, certificados caducados o no revocados, conjuntos de cifrado débiles y vulnerabilidades a nivel de aplicación siguen siendo posibles incluso con TLS habilitado.

¿Cuál es la diferencia entre SSL y TLS?

TLS es el protocolo sucesor de SSL, y su nombre cambió cuando SSL 3.0 se actualizó a TLS 1.0. SSL y TLS 1.0/1.1 están ahora en desuso debido a vulnerabilidades conocidas; TLS 1.3, definido en RFC 8446, es el estándar actual.

¿Por qué los certificados comodín suponen un problema de seguridad?

Un certificado comodín utiliza una única clave privada para todos los subdominios que abarca. Si esa clave se ve comprometida, todos los subdominios quedan expuestos simultáneamente. Los subdominios sensibles, como las páginas de inicio de sesión o de pago, deberían utilizar certificados individuales.

¿Puede un certificado caducado dar lugar a un ataque de intermediario (man-in-the-middle)?

Sí. Las organizaciones que no gestionan adecuadamente el ciclo de vida de los certificados pueden terminar con certificados comprometidos o caducados que nunca se revocaron. Un atacante puede seguir utilizando dicho certificado para establecer confianza con un sitio comprometido e interceptar el tráfico que parece cifrado.

¿Qué es HSTS y por qué es importante para la seguridad SSL/TLS?

El protocolo HTTP Strict Transport Security (HSTS) ordena a los navegadores que se conecten siempre mediante HTTPS, evitando así la solicitud inicial sin cifrar de la que dependen los ataques de eliminación de SSL. Requiere añadir una cabecera de respuesta específica y es una de las defensas más eficaces y sencillas contra los ataques de tipo downgrade.

Cierre su superficie de ataque SSL/TLS

Vea cómo funciona CertSecure Manager para mantener los certificados actualizados y revocados a tiempo, o hable con un asesor de Encryption Consulting sobre su configuración TLS.