Su guía sobre ataques a certificados SSL y TLS

Publicado: febrero de 2025. Actualizado: agosto de 2026. Revisado por el equipo de asesoría de PKI de Encryption Consulting.

La mayoría de los artículos sobre SSL/TLS tratan los "ataques a certificados" como una subcategoría de los ataques de intermediario y ofrecen consejos genéricos: usar HTTPS, mantener los certificados actualizados y habilitar HSTS. Este enfoque omite la causa principal de los costosos incidentes. Una Autoridad de Certificación (CA) es un pilar de confianza. Cuando una CA se ve comprometida, cuando se roba o se predice una clave privada, o cuando se elude el mecanismo de fijación diseñado para detectar certificados fraudulentos, el atacante no necesita romper la criptografía de TLS. Los navegadores y clientes confían en el certificado porque la propia cadena de confianza ha sido vulnerada.

Esta guía cubre específicamente los ataques basados ​​en certificados: emisión errónea de CA, claves privadas débiles o robadas, elusión de fijación de certificados y las defensas operativas (monitoreo de CT, administración automatizada del ciclo de vida, claves respaldadas por HSM, certificados de corta duración) para abordarlos. Para ataques a nivel de protocolo como el desdoblamiento de SSL, ataques de degradación y secuestro de sesión, consulte nuestras guías complementarias sobre ataques de intermediario y HSTS y desdoblamiento de SSL . Si su problema con el certificado es un handshake que no se completa en lugar de una vulneración de la cadena de confianza, nuestra guía de solución de problemas de handshake SSL aborda ese diagnóstico.

¿A qué se dirigen realmente los ataques basados ​​en certificados?

Los ataques basados ​​en certificados se dirigen a uno de tres aspectos: el proceso de emisión de la CA, la clave privada asociada al certificado o la decisión de confianza del cliente que acepta el certificado como válido. Cada técnica que se describe a continuación se reduce a uno de estos tres puntos débiles, razón por la cual las defensas se centran en la detección (identificar un certificado erróneo después de su emisión), la protección de la clave (dificultar el robo o la predicción de la clave privada) y el fortalecimiento de la confianza (dificultar el engaño a la decisión de aceptación del cliente).

• Ataques a la capa de emisión: Una autoridad de certificación (CA) o autoridad de registro (RA) comprometida emite un certificado para un dominio que el solicitante no controla. DigiNotar y Comodo son los dos incidentes públicos mejor documentados.
• Ataques a la capa de clave: La clave privada que respalda un certificado emitido legítimamente es débil (predecible en el momento de su generación) o ha sido robada posteriormente, lo que permite a un atacante suplantar la identidad del titular del certificado sin necesidad de la autoridad de certificación.
• Ataques a la capa de confianza: El atacante consigue que un cliente acepte un certificado fraudulento o sustituido, ya sea eludiendo la fijación de certificados o explotando un cliente que omite la validación.

¿Qué ocurrió en los casos reales de emisión errónea de documentos en California?

Dos incidentes ocurridos en 2011 definen cómo se ve en la práctica una vulneración de la autoridad de certificación (CA), y ambos siguen siendo los casos de referencia que la industria pretendía evitar al crear Certificate Transparency para que no volviera a suceder sin ser detectado.

La violación de Comodo RA, marzo de 2011

El 15 de marzo de 2011, un atacante comprometió la cuenta de un socio de la autoridad de registro (RA) de Comodo y la utilizó para solicitar nueve certificados fraudulentos en siete dominios: login.live.com, mail.google.com, www.google.com, login.yahoo.com (tres certificados distintos), login.skype.com, addons.mozilla.org y uno para "global trustee". Una comprobación interna de Comodo detectó la actividad casi de inmediato y se notificó a Mozilla al día siguiente. Los certificados fueron revocados mediante CRL y OCSP en cuestión de horas, y Mozilla incorporó una lista negra con los diez números de serie fraudulentos directamente en Firefox, publicando versiones parcheadas en el plazo de una semana. Los investigadores rastrearon la dirección IP del atacante hasta Irán, y posteriormente una persona se atribuyó públicamente la responsabilidad del ataque.

Lo que permitió superar este incidente fue la rapidez: la detección y la revocación se produjeron en un solo día, antes de que los certificados pudieran ser explotados de forma generalizada. Esto es la excepción, no la regla, y precisamente por eso la velocidad de detección se convirtió en el siguiente reto del sector.

La filtración de datos de DigiNotar, de julio a agosto de 2011

Meses después, la CA holandesa DigiNotar sufrió una brecha de seguridad mucho más grave. Los atacantes tomaron el control de la infraestructura de emisión de DigiNotar y emitieron al menos 531 certificados fraudulentos, incluido uno para *.google.com, según el informe forense "Black Tulip" de Fox-IT, encargado tras la brecha. A diferencia de Comodo, esta brecha pasó desapercibida durante semanas. Finalmente se detectó porque Google Chrome tenía codificadas ("fijadas") las claves públicas legítimas de los dominios de Google, por lo que Chrome rechazó el certificado fraudulento *.google.com en el momento en que se utilizó contra un usuario de Chrome, a pesar de que el certificado estaba encadenado a una raíz en la que todos los navegadores confiaban.

La investigación de Fox-IT y los informes posteriores documentaron que el certificado fraudulento *.google.com se había utilizado para interceptar el tráfico de aproximadamente 300,000 usuarios, la gran mayoría ubicados en Irán, lo que concuerda con una campaña de interceptación dirigida y no con un fraude oportunista. Una vez que se hizo pública la magnitud de la vulneración, todos los principales proveedores de navegadores revocaron permanentemente la confianza en los certificados raíz de DigiNotar, y la empresa matriz de DigiNotar se declaró en bancarrota en cuestión de semanas. Una CA que pierde la confianza de los navegadores no tiene una segunda oportunidad; el negocio se acaba.

La diferencia entre ambos incidentes es la lección principal: Comodo fue detectado en cuestión de horas gracias a que su sistema de monitoreo interno alertó sobre la anomalía. DigiNotar operó sin ser detectado durante semanas porque ningún sistema externo a DigiNotar supervisaba sus emisiones. La Transparencia de Certificados existe precisamente para subsanar esta segunda deficiencia, convirtiendo la existencia de cada certificado de confianza pública en un hecho público y auditable, independientemente de si la autoridad de certificación emisora ​​detecta alguna irregularidad.

¿Cómo pueden las claves débiles y el robo de claves privadas dar lugar a ataques a certificados?

Un certificado emitido correctamente por una autoridad de certificación totalmente legítima puede ser vulnerable a ataques si la clave privada asociada es débil o está expuesta. Este fallo no requiere comprometer la autoridad de certificación en absoluto.

El error de claves débiles de OpenSSL en Debian, 2008

En mayo de 2008, el proyecto Debian reveló la vulnerabilidad CVE-2008-0166 (Debian Security Advisory DSA-1571-1): un cambio en el paquete OpenSSL de Debian en 2006 eliminó accidentalmente el código que agregaba entropía al generador de números aleatorios utilizado para la generación de claves. Este cambio había estado presente desde septiembre de 2006 y se incluyó en la versión estable Debian 4.0 ("etch"), lo que significa que todas las claves, claves de host y cliente SSH, claves de certificado SSL/TLS, claves DNSSEC y claves OpenVPN generadas en un sistema Debian o Ubuntu afectado entre esa fecha y la divulgación del 13 de mayo de 2008 se extrajeron de un conjunto de valores posibles drásticamente reducido, inicializado en la práctica solo por el ID del proceso, que tenía un límite de 32,768 en los sistemas de esa época.

La consecuencia práctica fue que un atacante podía precalcular todas las claves posibles para un tamaño y arquitectura de clave determinados y simplemente comprobar la clave pública de un certificado objetivo con ese pequeño conjunto precalculado, en lugar de intentar factorizarla o realizar un ataque de fuerza bruta. La solución no consistió únicamente en un parche: cada clave generada en un sistema afectado durante ese período de casi dos años tuvo que ser identificada y regenerada, ya que un OpenSSL parcheado no podía corregir retroactivamente una clave que ya era predecible. Este incidente convirtió la respuesta estándar ante cualquier hallazgo de generación de claves débiles en «regenerar, no solo parchear», y es la razón por la que la generación de claves en módulos de seguridad de hardware (HSM), que proporcionan fuentes de entropía certificadas y auditadas, se considera hoy en día un control básico en lugar de un paso opcional de endurecimiento para las CA y las claves TLS de alto valor.

Robo de clave privada tras su emisión legítima

La versión moderna más común de un ataque a la capa de clave es el robo directo, en lugar de un fallo de generación débil: una clave privada almacenada como un archivo plano en un servidor comprometido, incluida en un repositorio de código o expuesta en una copia de seguridad mal configurada, permite a un atacante suplantar la identidad del titular del certificado indefinidamente, sin la intervención de la CA ni ninguna advertencia del navegador, hasta que el certificado sea revocado o caduque. Dado que el certificado en sí es totalmente legítimo, este tipo de ataque es invisible para la supervisión de la Transparencia de Certificados, que solo ve qué se emitió, no quién posee la clave. Su detección depende del registro de accesos, patrones de uso anómalos (un certificado presentado repentinamente desde un rango de IP o ubicación geográfica inesperados) y, lo más fiable, de que la clave privada nunca exista fuera del hardware protegido.

¿Cómo funciona el método de elusión del anclaje de certificados y por qué el anclaje no constituye una defensa completa?

La elusión del anclaje de certificados funciona atacando el almacén de confianza o la propia aplicación, en lugar de la lógica de anclaje. El anclaje, que consiste en codificar el certificado o la clave pública esperados en un cliente para que rechace cualquier otro, es precisamente lo que detectó el ataque de DigiNotar en Chrome. Sin embargo, el anclaje tiene un modo de fallo bien documentado: solo protege la relación específica para la que fue configurado y puede ser vulnerado desde cualquiera de los extremos.

• Instalación raíz no autorizada: El malware, un perfil malicioso de administración de dispositivos móviles (MDM) o un proxy de inspección TLS corporativo que instala su propia CA raíz en el almacén de confianza de un dispositivo pueden emitir certificados que el dispositivo aceptará, eludiendo los PIN que solo verifican el certificado hoja en lugar de la cadena completa hasta una raíz específica.
• Pines obsoletos: Una aplicación que utiliza un certificado hoja específico, en lugar de una CA o un certificado intermedio, perjudica a sus propios usuarios en el momento en que ese certificado se renueva legítimamente, lo que lleva a muchos equipos a optar por utilizar la CA en su lugar, una decisión que reduce la protección a "confiar en esta CA" en lugar de "confiar en este certificado exacto".
• Herramientas del lado del cliente: Los marcos de trabajo ampliamente disponibles (creados para pruebas de seguridad legítimas y utilizados indebidamente para la interceptación de ataques MITM) pueden conectarse a la pila TLS de una aplicación móvil y eliminar por completo las comprobaciones de fijación de credenciales en un dispositivo rooteado o con jailbreak, lo cual es un problema de integridad del cliente que la fijación de credenciales por sí sola no puede resolver.

La implicación práctica es que el anclaje de certificados pertenece a una estrategia de defensa en profundidad, no como un control independiente. Combínelo con la atestación de dispositivos a nivel del sistema operativo, la monitorización de la Transparencia de Certificados para todo lo emitido bajo sus dominios, independientemente de lo que acepte cualquier cliente, y los registros DNS CAA (Autorización de Autoridad de Certificación) según la RFC 8659 , que indican a cada CA de confianza pública cuáles están autorizadas a emitir certificados para su dominio, evitando así la emisión errónea de certificados por parte de CA que usted nunca tuvo intención de utilizar.

Tipos de ataques a certificados: Mecanismo, defensa principal y método de detección.

Utilice esta tabla para relacionar el ataque que le preocupa con el control que realmente lo aborda, en lugar de aplicar todos los pasos de endurecimiento de certificados de manera uniforme.

Tipo de ataque	Mecanismo	Defensa primaria	Método de detección
Emisión errónea de certificados de autoridad (autoridad de autoridad fraudulenta/comprometida)	Una CA o RA comprometida emite un certificado de confianza para navegadores para un dominio que no controla (DigiNotar, Comodo).	Registros DNS de CAA que restringen a los emisores autorizados; controles contractuales y de auditoría en las relaciones con CA.	Supervisión del registro de Transparencia de Certificados para detectar certificados inesperados en sus dominios.
Generación de clave débil	Un generador de números aleatorios defectuoso o de baja entropía hace que una clave privada sea predecible en el momento de su emisión (Debian OpenSSL, 2008).	Generación de claves respaldada por HSM con fuentes de entropía certificadas; tamaños mínimos de clave según NIST SP 800-57.	Análisis de la fortaleza de las claves contra listas de bloqueo de claves débiles conocidas; auditoría de la CA del entorno de generación de claves.
Robo de clave privada	Un atacante extrae la clave privada de un certificado ya emitido desde un servidor, repositorio o copia de seguridad.	Almacenamiento mediante HSM o bóveda de claves; control de acceso estricto y rotación de claves; nunca almacene las claves como archivos planos.	Uso anómalo de certificados desde direcciones IP o ubicaciones geográficas inesperadas; revisión del registro de acceso; validez corta que limita la exposición.
Suplantación de certificados / Ataque de intermediario (MITM) en ruta	El atacante presenta un certificado fraudulento, autofirmado o emitido incorrectamente para interceptar una conexión.	Validación estricta de la cadena, HSTS, registros CAA y monitoreo CT en conjunto	Fallos en la fijación de claves públicas en clientes de soporte; registro de inspección TLS; alertas de anomalías SIEM.
omisión de fijación de certificados	Se instala una CA raíz maliciosa en el dispositivo, o se explota un PIN obsoleto, lo que anula las comprobaciones de confianza del cliente.	Defensa en profundidad: fijar a CA, no a hoja; combinar con la certificación del dispositivo; no confiar únicamente en la fijación.	Alertas de EDR móvil sobre instalación no autorizada de CA raíz; huellas digitales TLS anómalas.
Detección tardía de errores de emisión	Se emite y utiliza un certificado fraudulento antes de que nadie se dé cuenta (modo de fallo de DigiNotar).	Monitorización automatizada y en tiempo real del registro de tomografía computarizada en lugar de revisión manual periódica.	Herramientas automatizadas de comparación de registros CT que alertan sobre SAN o emisores inesperados a los pocos minutos de su emisión.

¿Cuál es el modelo de amenaza realista para los ataques basados ​​en certificados?

Las medidas de defensa adecuadas dependen del adversario contra el que se esté planificando, y los dos incidentes de 2011 representan extremos opuestos de ese espectro.

1. Intercepción alineada con el Estado-nación. El atacante de DigiNotar contaba con los recursos y la paciencia necesarios para comprometer directamente la infraestructura de la CA y llevar a cabo una campaña de interceptación contra una población objetivo durante semanas. Este modelo de amenaza justifica la monitorización de CT, las restricciones de CAA y la fijación de claves públicas para los dominios de mayor valor, ya que el objetivo del adversario es una interceptación silenciosa y sostenida, no un ataque rápido y repentino.
2. Compromiso criminal oportunista de RA. El atacante de Comodo explotó un punto débil (una cuenta RA de un socio) con un objetivo que parece ser el de un ataque de phishing y fraude más rápido y generalizado, en lugar de una vigilancia continua. La velocidad de detección y la rápida revocación (tanto la CRL como el OCSP funcionaron correctamente) fueron lo que desbarató este modelo de amenaza, no la prevención por sí sola.
3. Explotación oportunista de claves. El fallo de seguridad de claves débiles de Debian no requería atacar a nadie en particular; cualquier clave generada durante el período vulnerable quedaba expuesta por igual a cualquiera que descargara la lista de bloqueo pública. Este modelo de amenazas premia la higiene básica, la generación de claves con soporte de HSM y el uso de tamaños mínimos, aplicados de forma uniforme en lugar de selectiva.
4. Información privilegiada o información clave de la cadena de suministro. El robo de claves privadas desde un servidor o repositorio mal configurado no requiere ningún nivel de sofisticación propio de una autoridad de certificación; solo acceso. Este es el modelo de amenaza que el control de acceso, el análisis de secretos y la prohibición de que las claves salgan del hardware están diseñados para contrarrestar.

La mayoría de las organizaciones necesitan controles para los cuatro aspectos, pero el orden importa: la monitorización de CT y los registros CAA son económicos y protegen contra el escenario de mayor gravedad (compromiso a nivel de CA), por lo que deben incluirse en cualquier implementación, independientemente de la sofisticación del adversario que se espere.

¿Cómo es en la práctica un programa operativo de defensa contra ataques a certificados?

Ejecute estos cinco pasos como un proceso operativo continuo, no como un proyecto de refuerzo puntual. Los ataques a certificados se detectan mediante una monitorización constante, no mediante una configuración que era correcta el día de su implementación.

1. Publicar registros CAA para cada dominio. Un DNS CAA registro que nombra la CA (o CA) específica autorizada para emitir para su dominio, por RFC 8659Es verificado por cada CA compatible con CA/B Forum antes de la emisión. Se trata de un cambio de DNS de cinco minutos que impide la emisión por parte de cualquier CA que no esté en su lista designada.
2. Implemente la monitorización de la transparencia de certificados en tiempo real. Transparencia de certificados, estandarizada en RFC 9162Requiere que cada certificado de confianza pública se registre en registros de solo escritura y auditables públicamente antes de que los navegadores lo acepten. Las herramientas de monitoreo que comparan las nuevas entradas de registro con los dominios conocidos en tiempo casi real reducen la brecha de detección de varias semanas de DigiNotar a solo unos minutos; este es el control de mayor impacto de esta lista.
3. Genera y almacena todas las claves privadas en un HSM. Los módulos de seguridad de hardware proporcionan entropía certificada y auditada para la generación y nunca exponen la clave privada sin procesar al sistema operativo anfitrión, eliminando así, con un solo control, tanto el modo de fallo de clave débil al estilo Debian como la mayoría de los escenarios de robo de claves privadas.
4. Automatice la renovación y avance hacia periodos de validez más cortos. Un certificado que se renueva automáticamente, antes de que un humano tenga que recordar actuar, no puede caducar sin ser detectado, y un certificado de menor duración limita el tiempo durante el cual una clave robada o débil puede ser explotada, incluso si el robo pasa desapercibido durante un tiempo. Consulte la siguiente sección para conocer las ventajas y desventajas que esto conlleva.
5. Registrar y recibir alertas sobre anomalías en el uso de certificados. Introduzca los registros de terminación TLS, los patrones de consulta OCSP y las alertas de monitorización de CT en un SIEM para que un certificado presentado repentinamente desde una ubicación geográfica inesperada, o un aumento repentino en las comprobaciones OCSP contra un número de serie específico, active una investigación en lugar de pasar desapercibido hasta que un cliente informe de algún problema.

¿Cuáles son las ventajas y desventajas en términos de rendimiento e interoperabilidad de los certificados de corta duración y la automatización?

La reducción de la duración de los certificados disminuye el margen de vulnerabilidad para los atacantes, pero solo resulta rentable si la renovación es totalmente automatizada; si se realiza manualmente, multiplica el riesgo operativo en lugar de reducirlo. Según la propuesta SC081v3 del CA/Browser Forum , la validez máxima de los certificados TLS públicos se reduce de 398 días actualmente a 200 días a partir del 15 de marzo de 2026, a 100 días a partir del 15 de marzo de 2027 y a 47 días a partir del 15 de marzo de 2029. Con un límite de 47 días, un certificado se renueva aproximadamente ocho veces al año en lugar de una, lo que supone un impulso directo, exigido por la industria, hacia la automatización en la que se basan las defensas de esta guía.

Las ventajas y desventajas son reales y conviene planificarlas en lugar de descubrirlas durante un incidente:

• La automatización ya no es opcional. El seguimiento manual de certificados, que ya era arriesgado con una validez de 398 días, se vuelve insostenible a los 47 días; los equipos que no cuenten con una renovación basada en ACME o en una plataforma verán aumentar, en lugar de disminuir, las interrupciones por vencimiento a medida que se acerca el plazo.
• El rendimiento de la firma de HSM y CA se convierte en un cuello de botella que hay que tener en cuenta en la planificación. Una frecuencia de renovación ocho veces mayor implica ocho veces más operaciones de firma en su infraestructura de CA o HSM; la capacidad que era suficiente para los ciclos de renovación anuales puede no serlo para los casi mensuales.
• Los sistemas heredados y embebidos se encuentran rezagados. Los dispositivos y aparatos que no son compatibles con la automatización ACME, común en entornos de control industrial, dispositivos médicos y hardware de largo ciclo de vida, necesitan un proceso de excepción aislado y supervisado, en lugar de verse obligados a seguir el mismo ritmo de renovación acelerado que el resto de los componentes.
• El valor de detección aumenta con la automatización. Un proceso de renovación totalmente automatizado también facilita la detección de anomalías: un certificado que no se renueva a tiempo, o que se renueva fuera del plazo previsto, constituye en sí mismo una señal de seguridad una vez que el comportamiento básico es coherente y automatizado.

¿De qué dependencias de gestión de claves depende este programa?

Cada medida de seguridad descrita en esta guía depende, en última instancia, de que la protección de la clave privada funcione correctamente, lo que convierte la gestión de claves en el único punto crítico que debe resolverse primero. En la práctica, tres dependencias son las más importantes:

• Disponibilidad de HSM durante la renovación. Si los certificados se renuevan automáticamente cada 47 días, pero el HSM que realiza la generación de claves o la firma no está disponible, está mal configurado o tiene exceso de capacidad, la renovación falla con la misma certeza que si nadie hubiera automatizado nada, solo que con menos aviso, porque el proceso que antes era manual (y visiblemente bloqueado) ahora es silencioso hasta que falla.
• Procedimientos clave de depósito en garantía y recuperación. Las claves respaldadas por hardware que no se pueden exportar son la opción predeterminada correcta para protegerse contra el robo, pero requieren un procedimiento probado de copia de seguridad y recuperación para el propio HSM; perder el HSM sin una ruta de recuperación constituye una interrupción del servicio y un fallo en la gestión de claves.
• Política coherente de solidez de los requisitos clave en toda la jerarquía de la CA. Una CA raíz o intermedia que imponga claves seguras no impide que se emita un certificado hoja con una clave débil o generada incorrectamente si la política de emisión no se aplica de extremo a extremo; el incidente de Debian demuestra específicamente que un solo eslabón roto en la cadena de generación de claves compromete todo lo que se encuentra después, independientemente de la seguridad de las claves de la propia CA.

¿Qué aspecto tienen estas defensas una vez desplegadas?

Dos ejemplos concretos de implementación ilustran cómo los controles mencionados anteriormente se integran en la práctica, en lugar de existir como una lista de verificación aislada.

Monitorización de registros CT que alimenta un SIEM

Un servicio de monitorización de registros CT supervisa los registros públicos en busca de nuevos certificados que coincidan con sus dominios registrados y patrones comodín. Cada nueva entrada se compara con una lista de permitidos de sus CA y sistemas de emisión conocidos; cualquier elemento fuera de dicha lista, un emisor inesperado, un SAN no reconocido o un certificado para una variante de dominio que nunca registró, genera una alerta que se envía al mismo SIEM que gestiona su otra telemetría de seguridad, correlacionada con los cambios de DNS y WHOIS para el mismo dominio. Esto transforma la detección de un certificado fraudulento en un registro público en cuestión de minutos, lo que precisamente permitió que la vulnerabilidad de DigiNotar pasara desapercibida durante semanas.

Emisión de ACME con claves respaldadas por HSM y rotación automatizada.

Una plataforma de gestión del ciclo de vida de los certificados solicita certificados mediante el protocolo ACME (Automated Certificate Management Environment) según un cronograma vinculado al período de validez cada vez más corto del CA/B Forum, generando y almacenando cada clave privada en un HSM en lugar de en el sistema de archivos del servidor solicitante. La renovación se activa automáticamente mucho antes de la fecha de vencimiento, implementa el certificado renovado y la cadena completa en cada balanceador de carga, servidor y servicio que lo necesite, y registra cada evento de renovación para su auditoría. Un certificado que no se renueva según lo programado, o una solicitud de renovación proveniente de una fuente inesperada, se convierte en una alerta de seguridad en lugar de un fallo silencioso que se descubre cuando comienza a fallar el protocolo de enlace en producción.

Limitaciones

• Esta guía abarca los ataques a certificados CA y TLS de confianza pública; no cubre los ataques contra jerarquías PKI privadas/internas, que comparten algunos modos de fallo pero operan bajo supuestos de confianza diferentes y no están sujetos a los requisitos de registro de CT.
• Los detalles de los incidentes de DigiNotar y Comodo se extraen de informes públicos posteriores a los ataques (el informe Black Tulip de Fox-IT, el blog de seguridad de Mozilla y los informes contemporáneos de la industria); algunos detalles operativos de ambos ataques nunca se divulgaron completamente al público.
• La monitorización de los registros de CT detecta la emisión errónea de certificados registrados públicamente; no detecta el robo de la clave privada de un certificado ya legítimo, lo que requiere una monitorización de acceso y uso por separado.
• El calendario de validez y los requisitos de CT del Foro CA/B pueden cambiar mediante futuras votaciones; verifique los requisitos actuales con los Requisitos Básicos publicados por el Foro CA/Browser antes de considerar cualquier fecha específica de esta guía como definitiva.

¿Qué recomendaría Encryption Consulting?

Consideramos la defensa contra ataques a certificados como un problema de gestión de claves y ciclo de vida, antes que como un problema de monitorización, ya que la monitorización sin remediación automatizada solo genera alertas que nadie puede atender. En nuestros proyectos, las organizaciones que gestionan bien una alerta de emisión errónea son aquellas que ya cuentan con flujos de trabajo automatizados de revocación y reemisión antes de que se active la alerta, no las que se ven obligadas a buscar su propio inventario de certificados en medio de un incidente. CertSecure Manager se basa en este principio: descubre todos los certificados de su entorno, integra la monitorización de Transparencia de Certificados en sus propios dominios y automatiza la renovación y revocación para que se pueda actuar sobre un certificado emitido erróneamente o comprometido en cuestión de minutos, en lugar de descubrirlo semanas después, como ocurría con DigiNotar.

En lo que respecta a la generación y el almacenamiento de claves, nuestro HSM como servicio proporciona a cada clave privada entropía certificada y protección de hardware sin que la organización necesite gestionar su propia infraestructura HSM, solucionando directamente el problema de las claves débiles expuestas por Debian. Además, para las organizaciones que desarrollan o refuerzan la jerarquía de CA que emite estos certificados, nuestro PKI como servicio y nuestros servicios de consultoría de PKI diseñan los controles de emisión, la política de CAA y las prácticas de auditoría necesarias para evitar que una vulneración de la CA se convierta en un caso similar al de DigiNotar.

Conclusión

Preguntas frecuentes

¿Cuál fue la causa real de la brecha de seguridad de DigiNotar? Entre julio y agosto de 2011, unos atacantes comprometieron la infraestructura de emisión de certificados de DigiNotar y emitieron al menos 531 certificados fraudulentos, incluido uno para *.google.com. La brecha se detectó únicamente porque Google Chrome había fijado las claves públicas legítimas de Google, lo que provocó que Chrome rechazara el certificado fraudulento, a pesar de que estaba vinculado a una raíz de confianza. La empresa matriz de DigiNotar se declaró en bancarrota pocas semanas después de la revelación.

¿En qué se diferencia el incidente de Comodo de 2011 de la brecha de seguridad de DigiNotar? El atacante de Comodo comprometió una única cuenta de socio de autoridad de registro (RA) y emitió nueve certificados fraudulentos en siete dominios el 15 de marzo de 2011. Una verificación interna de Comodo lo detectó ese mismo día y los certificados fueron revocados en cuestión de horas. La brecha de seguridad de DigiNotar fue más amplia (más de 531 certificados) y pasó desapercibida durante semanas, lo que la hizo mucho más dañina a pesar de que ambos incidentes compartían una causa raíz similar: un punto de emisión comprometido y de confianza para todos los navegadores.

¿Puede la generación débil de claves seguir provocando ataques a certificados hoy en día? El fallo específico de Debian OpenSSL (CVE-2008-0166) se corrigió en 2008, pero el riesgo subyacente, la generación de números aleatorios con baja entropía o con una semilla incorrecta durante la creación de claves, sigue siendo una preocupación latente en cualquier sistema donde las claves se generen mediante software en sistemas operativos de propósito general, en lugar de hardware certificado. Esta es la razón principal por la que la generación de claves respaldada por HSM se considera un control básico para las CA y las claves TLS de alto valor.

¿La Transparencia de Certificados realmente evita la emisión fraudulenta de certificados? No, y no está diseñada para ello. La Transparencia de Certificados (RFC 9162) permite detectar la emisión fraudulenta al exigir que cada certificado de confianza pública aparezca en un registro público y auditable antes de que los navegadores lo acepten. No impide que un atacante obtenga un certificado fraudulento; los registros CAA y los controles de emisión de la CA se encargan de la prevención, mientras que la monitorización de CT permite la detección rápida a posteriori.

¿Sigue mereciendo la pena implementar el anclaje de certificados, dado que puede eludirse? Sí, como una capa más, no como una defensa completa. El anclaje fue precisamente lo que detectó el ataque de DigiNotar en Chrome, y aún dificulta considerablemente un ataque de sustitución de certificados en ruta. Debería combinarse con la monitorización de CT, los registros CAA y los controles de integridad del dispositivo, en lugar de considerarse suficiente por sí solo.

Referencias

• Análisis posterior al ataque contra el DigiNotar iraníFundación Frontera Electrónica
• La brecha de seguridad en DigiNotar CA resulta en la emisión de certificados falsos., HKCERT
• Emisión del certificado de Comodo, seguimientoBlog de seguridad de Mozilla
• DSA-1571-1 OpenSSL, Generador de números aleatorios predeciblesAvisos de seguridad de Debian
• RFC 9162: Transparencia de certificados, versión 2.0, IETF
• RFC 8659: Registro de recursos de autorización de la autoridad de certificación DNS (CAA), IETF
• Propuesta SC081v3: Introducir un calendario para la reducción de los períodos de validez y reutilización de datos.Foro CA/Navegador
• Requisitos básicos para la emisión y gestión de certificados de servidor TLS de confianza públicaForo CA/Navegador