Un fallo crítico en la validación de dominios de SSL.com —una de las Autoridades Certificadoras (CA) reconocidas por navegadores como Chrome, Firefox y Safari— ha puesto en jaque la integridad del ecosistema SSL/TLS. La vulnerabilidad permitía a actores maliciosos obtener certificados válidos para dominios que no controlaban, abriendo la puerta a ataques de suplantación y espionaje sin que los usuarios recibieran advertencia alguna.
Vulnerabilidad en el método DCV: cómo funcionaba el ataque
El incidente se centra en el mecanismo Domain Control Validation (DCV), específicamente en el método 3.2.2.4.14 definido en los Baseline Requirements del CA/Browser Forum. Este método utiliza un correo electrónico especificado en un registro DNS TXT para validar que el solicitante de un certificado tiene control sobre un dominio.
La implementación defectuosa de SSL.com permitía validar dominios basándose en el dominio del correo electrónico del solicitante, sin verificar que este tuviera control sobre él. En otras palabras, si un atacante usaba una dirección como [email protected] (de un proveedor de correo conocido), SSL.com podía llegar a validar el dominio aliyun.com completo y emitir un certificado para aliyun.com o incluso www.aliyun.com, sin ser el propietario.
Un ejemplo detallado del ataque fue compartido en Bugzilla de Mozilla, donde se demuestra cómo se puede reproducir el error con dominios arbitrarios y cuentas de correo gratuitas.
Certificados válidos, riesgo invisible
El peligro de este fallo radica en que el certificado SSL/TLS emitido es técnicamente válido y confiado por todos los navegadores. Esto significa que un atacante podría:
- Crear una copia exacta de un sitio legítimo con un candado HTTPS válido.
- Realizar ataques Man-in-the-Middle (MITM) sin generar alertas de seguridad.
- Difundir malware o lanzar campañas de phishing difíciles de detectar.
¿Quiénes están en riesgo?
Cualquier organización con correos accesibles públicamente y que no limite explícitamente qué CA puede emitir certificados para sus dominios (mediante registros DNS CAA) es potencialmente vulnerable. Esto incluye:
- Empresas con correos tipo
info@,admin@,webmaster@sin control estricto. - Proyectos de código abierto o dominios personales sin registros CAA configurados.
- Proveedores de servicios de correo que permiten añadir direcciones externas a dominios legítimos.
La respuesta de SSL.com y próximos pasos
SSL.com ha reconocido el problema, revocado el certificado emitido erróneamente y desactivado temporalmente el método DCV afectado. Se espera un informe preliminar antes del 21 de abril de 2025, según ha indicado la empresa.
No obstante, este incidente es un claro recordatorio de que la confianza en HTTPS no puede basarse únicamente en el protocolo o en los candados visibles en el navegador. La infraestructura de las CA —aunque robusta— puede fallar, y cuando lo hace, el impacto puede ser silencioso y devastador.
Recomendaciones para responsables técnicos y de seguridad
Los equipos de infraestructura, DevOps y seguridad deben revisar urgentemente su estrategia de gestión de certificados:
- Implementar registros CAA en todos los dominios corporativos para limitar las CA autorizadas.
- Monitorizar registros de Transparencia de Certificados (CT logs) con herramientas como crt.sh o servicios como TrackSSL.
- Auditar las direcciones de correo utilizadas para validación de certificados.
- Evaluar la fiabilidad de sus Autoridades Certificadoras actuales, y considerar CA que apliquen validaciones más estrictas.
- Automatizar la gestión y revisión de certificados para detectar anomalías antes de que se conviertan en incidentes.
¿Basta con revocar?
Aunque SSL.com actuó con rapidez al revocar el certificado, la revocación en sí misma no es garantía de seguridad inmediata. Muchos navegadores no validan en tiempo real el estado de los certificados, lo que significa que un certificado revocado podría seguir siendo aceptado por semanas. Es por eso que los expertos recomiendan combinar la revocación con detección temprana y políticas preventivas.
En conclusión, esta brecha en SSL.com refuerza la importancia de adoptar una postura activa y vigilante en la gestión de certificados digitales. En un entorno donde la confianza en HTTPS es esencial, depender exclusivamente de los controles de las CA ya no es suficiente. La seguridad del canal cifrado comienza con decisiones informadas desde los equipos técnicos y una defensa en profundidad que no deje cabos sueltos.
Fuente: Noticias de seguridad
