El descubrimiento el miércoles de tres certificados TLS emitidos incorrectamente para el servicio de búsqueda DNS encriptado 1.1.1.1 de Cloudflare generó un gran interés y preocupación entre los profesionales de la seguridad en Internet. La revelación planteó la posibilidad de que una entidad desconocida hubiera obtenido una clave criptográfica que podría ser utilizada para desencriptar de manera encubierta millones de consultas DNS de usuarios protegidas a través de DNS sobre TLS o DNS sobre HTTPS. Desde allí, los estafadores podrían haber leído las consultas o incluso manipulado los resultados para enviar a los usuarios de 1.1.1.1 a sitios maliciosos.
Desde entonces, se ha disponible nueva información y análisis, incluyendo la emisión de nueve certificados adicionales desde febrero de 2024. Esta lista de preguntas frecuentes está diseñada para responder a las inquietudes planteadas en los comentarios sobre la historia y proporcionar lo último sobre lo que se sabe del incidente, que Cloudflare dijo el jueves que constituyó una “lapse in security inaceptable por parte de Fina CA”, la autoridad de certificación (CA) confiable por Microsoft responsable de los 12 certificados emitidos incorrectamente.
Preguntas y respuestas
¿Ha surgido nueva información desde el miércoles por la mañana?
Sí, se han revelado múltiples detalles. Primero, Cloudflare indicó que una auditoría realizada tras el descubrimiento encontró que Fina CA emitió un total de 12 certificados, nueve más de los que se conocían anteriormente. Todos los certificados han sido revocados.
Cloudflare afirmó que aún no ha encontrado evidencia de que alguno de ellos se haya utilizado de manera maliciosa, es decir, para suplantar criptográficamente los servicios ofrecidos por su resolvedor DNS 1.1.1.1. La compañía admitió que “debió haber detectado y respondido a [las emisiones incorrectas] antes”, a través de Certificate Transparency, un programa que ayuda a administrar (más sobre esto más adelante).
Fina CA, por su parte, comentó en un breve correo electrónico que los certificados fueron “emitidos para pruebas internas del proceso de emisión de certificados en el entorno de producción. Ocurrió un error durante la emisión de los certificados de prueba debido a la entrada incorrecta de direcciones IP. Como parte del procedimiento estándar, los certificados fueron publicados en los servidores de registro de Certificate Transparency.”
La CA agregó que las claves privadas permanecieron dentro de un entorno controlado por Fina y fueron “destruidas de inmediato, incluso antes de que los certificados fueran revocados.” La empresa aseguró que los certificados emitidos incorrectamente “no comprometieron a los usuarios ni a ningún otro sistema de ninguna manera.”
¿Esto significa que Fina no hizo nada malo?
No. Fina nunca tuvo el permiso de Cloudflare para emitir certificados para una IP que controla. El consentimiento de la parte propietaria es una regla cardinal que Fina no siguió.
¿Qué son los certificados TLS? ¿Cómo funcionan?
En resumen, estos certificados son lo único que garantiza que gmail.com, bankofamerica.com, o cualquier otro sitio web esté controlado por la entidad que afirma ser su propietaria. Muchos usuarios de Internet saben que solo deben confiar en un sitio web cuando su verdadero nombre de dominio aparece correctamente en la barra de direcciones y está acompañado de la etiqueta HTTPS. Esto previene muchos ataques que utilizan nombres de dominio similares o hackeos como el envenenamiento de caché DNS para crear sitios falsos que se hacen pasar por los reales y confiables. No es exagerado decir que TLS es la raíz de la confianza en la World Wide Web.
Más técnicamente, el protocolo TLS proporciona un marco integral para asegurar esta confianza. Los certificados son una parte fundamental de Transport Layer Security, un protocolo que utiliza un par de claves criptográficas para probar que un sitio que aparece en una ventana de navegador es, de hecho, el auténtico operado por el verdadero propietario del dominio, no un estafador que ejecuta un sitio similar.
Este sistema complejo funciona de la siguiente manera:
Un propietario de un nombre de dominio como example.com crea un par de claves pública y privada, los bloques básicos de la criptografía asimétrica. El propietario del dominio luego crea una solicitud de certificado que incluye su clave pública y la información identificativa que se incluirá en el certificado. Luego, el propietario firma digitalmente la solicitud con la clave privada para probar a la CA que el solicitante tiene, de hecho, control sobre la clave privada. Con eso, la solicitud se envía a la CA.
La CA es una entidad que recibe solicitudes de certificados, verifica que el solicitante tenga control sobre el dominio y emite el certificado final, todo bajo un régimen estricto establecido en los requisitos básicos dictados por un organismo conocido como CA/Browser Forum. A cambio, los proveedores de navegadores y sistemas operativos añaden las credenciales criptográficas de la CA a su almacén de certificados raíz.
Una vez que la CA recibe la solicitud, debe llevar a cabo varios pasos para validarla. Primero, la CA verifica la firma digital en la solicitud, confirmando que la clave privada que firmó la solicitud corresponde a la clave pública incluida en el cuerpo de la solicitud. A continuación, la CA requiere prueba de que el solicitante es el legítimo propietario del dominio o dirección IP solicitada para ser vinculada a la clave pública dentro del certificado. Diferentes CAs manejan este proceso de validación de manera diferente. Muchas requieren que el solicitante publique un token en un registro DNS para el nombre de dominio o accesible desde la dirección IP cubierta en la solicitud de certificado.
Una vez que la CA valida la solicitud, emite el certificado. Este contiene la clave pública, la información identificativa del solicitante y está firmado con la clave privada de la CA. Luego, la CA devuelve el certificado completado al solicitante. El solicitante es ahora el titular del certificado.
El titular del certificado instala la credencial en su servidor web, junto con el par de claves pública y privada. Desde entonces, cuando alguien visita el sitio, el servidor utiliza su par de claves y su certificado digital con el protocolo TLS para autenticarse y establecer un canal de comunicación seguro con la otra parte conectada. Como parte del protocolo, el certificado se envía a la otra parte conectada como evidencia de que la clave pública del servidor realmente pertenece al operador del servidor/sitio web.
Una vez que el navegador conectado recibe el certificado, verifica si fue emitido (firmado) por una CA en la que confía (técnicamente, si la clave de la CA o la de un padre de la CA está almacenada en el almacén raíz del navegador). Esto complica un poco las cosas, ya que a menudo puede haber una o más CAs intermedias cuyas claves no están en el almacén raíz, sino que forman parte de una cadena de certificados que están criptográficamente vinculados a una CA “raíz” que es explícitamente confiable por el navegador.
¿Qué tan grave es realmente este incidente?
Hay un par de maneras de responder a eso. Si Fina tiene razón y las claves privadas nunca salieron de su control y fueron eliminadas de manera segura, no hay peligro. Y, en última instancia, todo esto fue una falsa alarma.
Dicho esto, Cloudflare ha afirmado que está tomando el incidente “extremadamente en serio.” La compañía también declaró que “debe asumir que existe una clave privada correspondiente [y] no está bajo el control de Cloudflare,” ya que no tiene forma de verificar las afirmaciones de Fina.
La razón de la precaución es el papel fundamental que TLS desempeña en la seguridad de la web y la fragilidad de la infraestructura de clave pública de la que depende todo el sistema. Esta raíz de confianza puede colapsar con la falla de una sola CA. Una vez que se emite un certificado válido a una parte no autorizada, es trivial para esa parte suplantar criptográficamente el sitio que figura en el certificado emitido incorrectamente.
¿El artículo del miércoles decía que Cloudflare era parcialmente responsable del incidente porque no detectó los certificados emitidos incorrectamente hasta que salieron a la luz en un grupo de discusión cuatro meses después del hecho. ¿No es eso culpar a la víctima?
No. Cloudflare no es la víctima aquí. Los millones de usuarios de Windows que dependen de 1.1.1.1 fueron las víctimas, porque eran sus consultas las que estaban en riesgo de ser interceptadas. Cloudflare, al igual que los custodios de todas las propiedades web, tiene el deber afirmativo de asegurar el servicio. Parte de esa obligación es revisar los registros de transparencia de certificados, que indexan la emisión de cada certificado TLS emitido por una CA confiable por los navegadores. Es una tarea trivial de programación automatizar las comprobaciones históricas de transparencia de certificados a gran escala.
Cloudflare reconoció este fallo el jueves, escribiendo:
Fallamos tres veces. La primera porque 1.1.1.1 es un certificado IP y nuestro sistema no alertó sobre estos. La segunda porque, incluso si hubiéramos recibido alertas de emisión de certificados, como cualquiera de nuestros clientes puede, no implementamos un filtrado suficiente. Con la gran cantidad de nombres y emisiones que gestionamos, no ha sido posible para nosotros mantener revisiones manuales. Finalmente, debido a esta supervisión ruidosa, no habilitamos alertas para todos nuestros dominios. Estamos abordando estas tres deficiencias.
En última instancia, la culpa recae en Fina; sin embargo, dada la fragilidad de la PKI TLS, es responsabilidad de todas las partes interesadas garantizar que se cumplan los requisitos del sistema.
¿Y qué pasa con Microsoft? ¿También tiene culpa?
Hay cierta controversia sobre este punto, como rápidamente aprendí el miércoles a partir de las redes sociales y los comentarios de los lectores de Ars. Los críticos del manejo de este caso por parte de Microsoft dicen que, entre otras cosas, su responsabilidad de garantizar la seguridad de su Programa de Certificados Raíz incluye la verificación de los registros de transparencia. Si lo hubiera hecho, los críticos dijeron, la compañía habría descubierto que Fina nunca había emitido certificados para 1.1.1.1 y habría investigado más sobre el asunto.
Además, al menos algunos de los certificados tenían codificación no conforme y enumeraban nombres de dominio con dominios de nivel superior inexistentes. Este certificado, por ejemplo, lista ssltest5 como su nombre común.
En lugar de eso, al igual que el resto del mundo, Microsoft se enteró de los certificados a través de un foro de discusión en línea.
Algunos expertos en TLS con los que hablé dijeron que no está dentro del alcance de un programa raíz hacer un monitoreo continuo de este tipo de problemas.
En cualquier caso, Microsoft dijo que está en proceso de hacer que todos los certificados sean parte de una lista de desautorización.
Microsoft también ha enfrentado críticas de larga data por ser demasiado indulgente en los requisitos que impone a las CAs incluidas en su Programa de Certificados Raíz. De hecho, Microsoft y otra entidad, el Servicio de Confianza de la UE, son los únicos que, por defecto, confían en Fina. Google, Apple y Mozilla no lo hacen.
“La historia aquí es menos sobre el certificado 1.1.1.1 y más sobre por qué Microsoft confía en esta CA operada de manera descuidada,” dijo Filippo Valsorda, un experto en Web/PKI, en una entrevista.
Le pregunté a Microsoft sobre todo esto y aún no he recibido respuesta.
Fuente original: ver aquí
