it-swarm-es.com

¿Qué tan factible es que una CA sea pirateada? ¿Qué certificados raíz de confianza predeterminados debo eliminar?

Esta pregunta ha sido revisada y aclarada significativamente desde la versión original.

Si miramos cada certificado confiable en mi tienda Trusted Root, ¿cuánto debería confiar en ellos?

¿Qué factores deben tenerse en cuenta cuando evalúo la confianza de cada CA raíz para una posible eliminación de mi tienda local?

Más información:
Si una CA emite un certificado a una parte incorrectamente validada, entonces eso hace que todas las máquinas que confían en esa CA sean vulnerables a los ataques MITM. Como resultado, todas las CA validan estrictamente al solicitante de una solicitud de certificado SSL determinada para garantizar la integridad de su cadena CS.

Sin embargo, una gran parte de este proceso de verificación de CA está sujeto a la intervención humana y brinda oportunidades para emitir un certificado a la parte equivocada. Esto puede hacerse por error del operador de CA, demandas del gobierno o tal vez la coerción (soborno) de un operador de CA.

Me gustaría obtener más información sobre qué CA predeterminadas tienen más probabilidades de emitir certificados a la parte equivocada. Tengo la intención de utilizar esta información para aconsejar a los usuarios que eliminen esa CA de su Trusted Cert Store

Ejemplos:
Suponga que el gobierno que controla una CA en particular quiere asumir la identidad de Microsoft.com y exige una excepción al proceso de verificación de la CA. Ese gobierno también requiere que se mantenga el secreto de esta excepción. El par de claves generado se usaría en un ataque MITM.

Confianza predeterminada de Windows Azure

Windows Azure admite 275 CA como se muestra en el siguiente enlace . Dependiendo del uso de la CA en particular, algunas de esas CA pueden aumentar el área de superficie de un ataque en particular. De hecho, esto puede ser técnicamente necesario para que algunas aplicaciones funcionen correctamente.

Confianza predeterminada de Amazon

(no disponible) Comparta enlaces a Amazon, Google y la lista de CA predeterminada de VMWare si se encuentra con ellos.

Mozilla

A lista de todos los certificados y declaraciones de auditoría está disponible.

Apple iOS

Lista de todos certificados raíz del iPhone como se menciona en este # WWDC2017. Video

84
goodguys_activate

Actualización 5 El problema raíz (heh) con el modelo de CA es que, en la práctica general, cualquier CA puede emitir certificados para cualquier dominio, por lo que eres vulnerable al eslabón más débil. En cuanto a en quién puede confiar, dudo que la lista sea muy larga, ya que hay mucho en juego y la seguridad es difícil. Recomiendo la publicación de Christopher Soghoian sobre el tema, que aclara los diversos enfoques que los gobiernos de todo el mundo han utilizado para acceder a los datos privados de los usuarios, ya sea exigiéndoles directamente a las empresas que operan servicios en la nube, mediante escuchas telefónicas o cada vez más a través de la coerción de CA o hacks: ligera paranoia: ¡Las fuerzas que llevaron al hack de DigiNotar .

Aquí proporciono algunos detalles y termino con enlaces a algunas posibles soluciones.

En 2009, Etisalat (60% propiedad del gobierno de los Emiratos Árabes Unidos) lanzó un parche BlackBerry de aspecto inocuo que insertaba software espía en los dispositivos RIM, lo que permite el monitoreo del correo electrónico, por lo que difícilmente puede considerarse confiable. Pero está en muchas listas de CA confiables: http: //arstechnica.com/business/news/2009/07/mobile-carrier-rolls-out-spyware-as-a-3g-update.ars

Actualización 1 Vea también un ejemplo de un ataque exitoso, supuestamente por un iraní llamado ¡ComodoHacker , contra Comodo: Rogue SSL certificados ("caso comodogate") - F-Secure Weblog . F-Secure señala que Mozilla incluye certificados emitidos por AC en China, Israel, Bermudas, Sudáfrica, Estonia, Rumania, Eslovaquia, España, Noruega, Colombia, Francia, Taiwán, Reino Unido, Países Bajos, Turquía, Estados Unidos, Hong Kong, Japón , Hungría, Alemania y Suiza.

Túnez es otro país que administra una CA de gran confianza, y también hay buena documentación de las acciones de su gobierno para invadir la privacidad: La historia interna de cómo Facebook respondió a los piratas tunecinos - Alexis Madrigal - Tecnología - El Atlántico

Mozilla señala otra práctica cuestionable a tener en cuenta: las CA que permiten a un socio de RA emitir certificados directamente desde la raíz, en lugar de hacerlo a través de un intermediario: Problema de certificado de Comodo - ¡Seguimiento en el blog de seguridad de Mozilla .
Vea también más detalles, incluidas las especulaciones sobre el reclamo de responsabilidad por parte de un pirata informático iraní solitario Los navegadores web y Comodo revelan un ataque exitoso de una autoridad certificadora, quizás desde Irán ¡Libertad para jugar

Actualización 3 : Otro ataque exitoso aparentemente también realizado por ComodoHacker fue contra el ¡DigiNotar CA. Su sitio web se vio comprometido a partir de 2009, pero esto no se notó hasta después de que DigiNotar también fue utilizado en 2011 por los iraníes para firmar certificados falsos para los sitios web de Google, Yahoo !, Mozilla, WordPress y The Tor Project. DigiNotar no reveló su conocimiento de la intrusión en su sitio durante más de un mes. Vea más en DigiNotar Hack destaca las fallas críticas de nuestro modelo de seguridad web SSL | Freedom to Tinker .

Supongo que el rango de vulnerabilidad de varias AC varía ampliamente, al igual que su utilidad. Por lo tanto, sugiero volver a enfocar su estrategia. Cuando pueda reducirlo a activos específicos que está tratando de proteger, simplemente elimine todas las CA excepto las necesarias para usar esos activos. De lo contrario, considere eliminar las AC que considere más vulnerables para aquellos que se preocupan por sus activos, o menos populares, solo para reducir la superficie de ataque. Pero acepte el hecho de que seguirá siendo vulnerable a ataques sofisticados incluso contra las AC más populares y cuidadosas.

Actualización 2 : Hay una excelente publicación sobre cómo arreglar nuestra peligrosa infraestructura de CA en Freedom to Tinker: ¡Construyendo una mejor infraestructura de CA =

Habla de estas innovaciones:

Actualización 4 Una de nuestras publicaciones en el blog de seguridad de TI en agosto de 2011 también cubre el caso para pasar a DNSSEC: Una mirada basada en el riesgo en la fijación el problema de la autoridad de certificación "Stack Exchange Security Blog

Actualización 6 Varias Autoridades de Certificación han sido atrapadas violando las reglas. Eso incluye la agencia francesa de defensa cibernética (ANSSI) y Trustwave, cada una de las cuales estaba ¡vinculada a la falsificación de certificados digitales .

Actualización 7 Otro conjunto de "certificados emitidos incorrectamente", a través del Controlador indio de autoridades de certificación (India CCA) en 2014: Google Online Security Blog: ¡Mantenimiento de la seguridad del certificado digital

Consulte también la pregunta sobre ¡Transparencia de certificado que parece un enfoque útil para descubrir certificados defectuosos y violaciones de políticas anteriormente.

64
nealmcb

Como Matt Blaze escribió una vez, las AC te protegen de cualquier persona de la que no estén dispuestas a tomar dinero. Eso debería decirle algo sobre dónde se encuentran los incentivos de la CA y algunos riesgos potenciales en el acuerdo.

38
D.W.

Me temo que la respuesta corta a esta pregunta es que es imposible saberlo, por lo que puedo ver. Hay una gran cantidad de CA predeterminadas instaladas en los navegadores más comunes y es difícil evaluar la probabilidad de que sean "confiables" en términos de entregar certificados a organizaciones gubernamentales u otras organizaciones.

Si una CA llegara a ser conocida como no confiable, probablemente sería eliminada de las listas de instalación predeterminadas de los navegadores (según @xce a continuación, Diginotar es un buen ejemplo aquí y también Digicert)

Además de que la organización proporciona certificados de forma voluntaria, existe el riesgo de que puedan proporcionar certificados sin realizar las verificaciones de seguridad adecuadas en el solicitante. En Defcon hace un par de años hubo varias presentaciones sobre este tema de poder obtener certificados sin autorización.

Si esto es una preocupación importante, la única forma en que puedo pensar es crear una lista blanca de AC que haya revisado y se sienta cómodo con la seguridad provista. Obviamente, esto no funcionaría para acceder a Internet en general, ya que probablemente terminaría eliminando las CA que tienen problemas con los Certs en los sitios que le gustaría usar.

18
Rory McCune

2 ejemplos que van al corazón de lo que necesita saber, pero no lo que está preguntando explícitamente:

  • Hace varios años (2006, o tal vez a fines de 2005) hubo un incidente bastante publicitado de phishing SSL: un sitio web de un banco falso recibió un certificado SSL legítimo (de GeoTrust, creo), por un error ortográfico del sitio de un banco regional. (Actualización: encontrado este enlace histórico - la dirección era para el nombre completo del banco en lugar del acrónimo abreviado). Desde entonces, ha habido otros casos de phishing SSL ... El punto es que es posible obtener un certificado sin recurrir a la "coerción".
  • La reciente Stuxnet novela se basó, entre otras tácticas, en certificados robados. Estos fueron "tomados prestados" de fabricantes de controladores de terceros y, dado que eran "confiables", se pudieron utilizar de forma incorrecta para plantar el malware.

Luego, por supuesto, están los escenarios de software en los que ni siquiera se utiliza la CA, p. Ej. con clientes gruesos que llaman a servicios web, que no se molestan en validar el certificado del servidor ...

Mi punto es que si te preocupa MITM sobre SSL, la mayoría de las veces no es la coerción gubernamental lo que debería preocuparte. Por lo general, hay formas más fáciles y más accesibles.
Incluso me opongo a que "Trusted Certs" sea llamado "Trusted" ... Solo porque sé quién eres, no significa que deba confiar en ti ... y no significa que deba confiar en que sabes quién es alguien ¡más es.

Sin mencionar que si elimina los certificados raíz estándar de la tienda de confianza, muchos sitios en Internet no funcionarán como se esperaba.

Por otro lado, si se trata de un servidor/dispositivo que no necesita capacidades de navegación generales, pero se está comunicando con un servidor específico (o conjunto de servidores), elimine definitivamente [~ # ~] todos [~ # ~] certificados raíz, excepto una lista blanca de los que necesita.
Y si vas con tu propia CA interna, aún mejor ...

11
AviD

Cada CA publica una Declaración de práctica de certificado que describe cómo protegen sus propias claves y validan las solicitudes de certificados antes de emitirlas. Una URL a la ubicación de este documento generalmente está incrustada en cada certificado emitido por la CA. Suponiendo que la CA en cuestión realmente sigue este documento de política, debería darle una indicación de las longitudes a las que se dirige para determinar la validez de la entidad que solicita los certificados. Busque declaraciones en el sentido de que protegen sus claves de firma de CA utilizando módulos de seguridad de hardware o módulos criptográficos para proteger las claves de firma, autenticación multifactor y autorización basada en quórum para firmar certificados, etc. Estos métodos de protección hacen que sea mucho más difícil y costoso para que un tercero deshonesto robe las claves de firma.

La gran lista de CA de confianza (mi llavero Roots del sistema Mac tiene 175) está ahí para su conveniencia, para que el sistema HTTPS sea utilizable para usted y para todos en el planeta que no hacen estas preguntas. Por supuesto, podría expulsar a todas las AC de esta lista a menos que haya auditado personalmente sus prácticas. Para un sistema cerrado, donde controlas todos los puntos finales y tienes un número limitado de partes confiables, esto es factible. El sistema de control de versiones de Subversion no incluye ningún certificado raíz confiable, pero puede agregar el suyo a cada cliente. Para la web en general, la única forma en que hemos encontrado que es utilizable es tener una parte de confianza fuera de banda (la compañía que suministra su sistema operativo o navegador, lo que sea que piense de ellos) proporcionar una lista de confianza certificados que le permiten conectarse a prácticamente cualquier servidor con SSL en el mundo.

¿Realmente necesita todos esos certificados en su lista de confianza? Probablemente no. Pero su proveedor de SO/navegador no puede anticipar (y no debe controlar) con quién quiere hacer negocios, por lo que los incluye a todos. El problema con la lista grande es que tiene AC de todo plumaje, con todo tipo de métodos de verificación, de todas las jurisdicciones, tratados exactamente de la misma manera. No todas las CA actúan de la misma manera: hemos visto casos de credenciales de inicio de sesión de revendedores comprometidas e incluso claves de CA comprometidas. Algunas AC requieren un certificado de incorporación y la promesa de su primogénito, otras simplemente verifican que puede recibir un correo electrónico en el dominio para el que solicita un certificado. Y sin embargo, cada navegador es tratado exactamente igual por su navegador.

Una línea de defensa contra certificados falsos para el mismo nombre común sería almacenar en caché el certificado original en el cliente: si de repente aparece un certificado diferente de una CA diferente, esto debería ser motivo de preocupación. No sé cómo los navegadores de hoy tratan este caso, y soy demasiado vago para descubrirlo.

9
Sander Temme

Este tipo de discusión siempre me recuerda a este error de Mozilla solicitando la inclusión de una nueva CA. Bastante gracioso, pero bastante perspicaz.

4
Steve Dispensa

Al investigar qué certificado eliminar en una PC con Windows, primero debe asegurarse de no eliminar los certificados requeridos por el sistema. Si intenta hacerlo, recibirá el siguiente mensaje de error

error- you're deleting a system cert!!

Esta es la URL con una lista de certificados que nunca deben eliminarse de un sistema de Windows http://support.Microsoft.com/?id=293781

A continuación, debe considerar eliminar (probar la eliminación de) certificados intermedios, ya que solo existen " solo por motivos heredados ".

Al evaluar la eliminación de todos los certificados restantes, tenga en cuenta que Programa de certificados raíz de Microsoft requiere que la CA apruebe uno de estos estándares de auditoría:

  • ETSI 102 042
  • ETSI 101 456
  • WebTrust para CA
  • Auditorías de preparación de WebTrust EV
  • ISO 21188 (Tenga en cuenta que no aceptan ISO 27001)

Si está eliminando Certs de un navegador que no sea MSFT (IE), puede que desee revise estas pautas de calidad de CA .

Restricciones

El programa también tiene auditorías adicionales que se aplican a lo que es el uso clave. El uso de la clave se limita a lo siguiente:

  • Autenticación del servidor (SSL) = 1.3.6.1.5.5.7.3.1

  • Autenticación del cliente (SSL) = 1.3.6.1.5.5.7.3.2

  • Correo electrónico seguro (SMIME) EKU = 1.3.6.1.5.5.7.3.4

  • Código de firma EKU = 1.3.6.1.5.5.7.3.3

  • Sellado de tiempo EKU = 1.3.6.1.5.5.7.3.8

  • OCSP EKU = 1.3.6.1.5.5.7.3.9

  • Sistema de cifrado de archivos EKU = 1.3.6.1.4.1.311.10.3.4

  • IPSec (Túnel, Usuario) EKU = 1.3.6.1.5.5.7.3.6, 1.3.6.1.5.5.7.3.7

Usos clave prohibidos

El programa prohíbe los siguientes usos clave:

  • Inicio de sesión con tarjeta inteligente Este es un escenario exclusivo de la empresa, porque se requiere la implementación de Active Directory y la raíz debe agregarse al almacén de NTAuth en Active Directory. Consulte el siguiente artículo de KB para obtener más detalles. http://support.Microsoft.com/default.aspx?scid=kb;en-us;Q281245

  • Derechos digitales Este EKU está obsoleto. Windows Media DRM usa su propio formato XML para las licencias y no usa X.509.

  • Subordinación calificada Este EKU está obsoleto y Windows lo ignora.

  • Escenario de CA de Enterprise de recuperación clave.

  • Recuperación de archivos Este EKU está obsoleto y es ignorado por el Sistema de cifrado de archivos de Windows (EFS).

  • Todas las políticas de aplicación No podemos otorgar “todos los usos”, ya que esto necesariamente admite EKU solo para empresas y otros EKU inaceptables.

  • Servicio de directorio replicación de correo electrónico Escenario empresarial

  • Agente de solicitud de certificado

  • Escenario de CA empresarial

  • Escenario de Enterprise CA del agente de recuperación clave

  • Certificado de cifrado de CA

  • Escenario de CA empresarial

Criterios de aceptación

Además, se deben cumplir los siguientes criterios antes de agregar un propósito general o CA gubernamental a la raíz:

  1. La CA debe proporcionar la información solicitada a continuación (consulte Paso 1. Comuníquese con Microsoft ) y reciba la aprobación preliminar para ser miembro del Programa.

  2. La CA debe proporcionar un certificado de prueba emitido desde el certificado raíz de la CA para fines de prueba. Opcionalmente, una CA puede proporcionar a Microsoft una URL de un servidor de acceso público donde se pueden verificar los certificados emitidos desde su certificado raíz. (Ver FAQ para más detalles)

  3. La CA debe completar un Acuerdo de CA de Microsoft. El acuerdo se proporcionará solo después de que haya completado el Paso 1 del proceso de solicitud y haya recibido la aprobación preliminar de su solicitud.

  4. Los certificados raíz deben cumplir con la sección de Requisitos técnicos a continuación. En particular, requerimos un tamaño mínimo de clave criptográfica del módulo RSA de 2048 bits para cualquier raíz y todas las CA emisoras. Microsoft ya no aceptará certificados raíz con un módulo RSA de 1024 bits de caducidad. Preferimos que las nuevas raíces sean válidas durante al menos 8 años a partir de la fecha de presentación, pero que caduquen antes del año 2030, especialmente si tienen un módulo RSA de 2048 bits.

  5. Los certificados emitidos desde un certificado raíz deben admitir la extensión del punto de distribución CRL. El punto de distribución de CRL debe apuntar a una ubicación que sea de acceso público.

  6. La CA debe tener una política de revocación documentada y la CA debe poder revocar cualquier certificado que emita.

  7. La CA debe completar una auditoría y enviar los resultados de la auditoría a Microsoft cada doce (12) meses. La auditoría debe cubrir la jerarquía completa de PKI que Microsoft habilitará mediante la asignación de usos de clave extendida (EKU). Todos los usos de certificados que habilitamos deben ser auditados periódicamente. El informe de auditoría debe documentar el alcance completo de la jerarquía de PKI, incluida cualquier sub-CA que emita un tipo específico de certificado cubierto por una auditoría. Las auditorías elegibles incluyen:

Estas son las auditorías aceptadas en este momento para las AC no gubernamentales. Nos reservamos el derecho de cambiar las auditorías mencionadas anteriormente y/o aceptar otras auditorías comparables en el futuro.

Requisitos técnicos

Los nuevos certificados raíz deben cumplir los siguientes requisitos técnicos:

  • Los certificados raíz deben ser certificados x.509 v3.

  • El nombre del sujeto debe contener un nombre significativo de la CA (por ejemplo, no puede ser "Root" o "CA1")

  • Extensión de restricciones básicas: cA = verdadero

  • Uso de clave (si está presente): keyCertSign y cRLSign solamente

  • Los requisitos de tamaños de clave raíz se basan en NIST SP 800-57:

         RSA greater or equal to 2048-bit modulus
    
         ECC greater or equal to P256 modulus
    
  • El algoritmo hash debe ser al menos SHA1. No se aceptan hashes MD2, MD4 o MD5.

  • Para un tamaño de clave raíz mayor o igual a un módulo RSA de 2048 bits, el certificado raíz no debe caducar hasta al menos 8 años después del envío y no más tarde de 2030. Puede otorgarse una caducidad más larga a tamaños de clave raíz más grandes.

  • Los certificados de CA intermedios están excluidos del programa de CA raíz (consulte las preguntas frecuentes para obtener más información)

  • La CA no emitirá certificados subordinados o de entidad final MD2, MD4 o MD5 de ningún certificado raíz distribuido por el Programa, a partir del 15 de enero de 2009.

  • Los certificados raíz RSA de 1024 bits existentes ("heredados") pueden permanecer en distribución por el Programa hasta la fecha límite de NIST del 31 de diciembre de 2010, excepto según lo dispuesto por Microsoft.

  • La CA puede emitir certificados RSA de 1024 bits de certificados raíz distribuidos por el Programa hasta la fecha límite de NIST del 31 de diciembre de 2010.

3

Creo que el gobierno de los EE. UU. Trató de aprobar una legislación hace unos años, dándoles el derecho de obligar a una AC a generar un certificado válido de un tercero para escuchas telefónicas y demás. No pude encontrar evidencia de esto, así que puedo estar recordando algo en la línea de las conversaciones de DefCon que Rory mencionó.

3
Steve

Supongamos que un mal gobierno quisiera ver el tráfico SSL de las máquinas. ¿Qué tan factible es que las CA predeterminadas sean obligadas a emitir un nuevo certificado?

El predicado y la pregunta no están relacionados. No importa cuán fácil o a menudo se pueda obligar a una CA a emitir un nuevo certificado: el posible espía no podría ver sus datos a menos que tengan la clave privada del certificado que ya tiene instalado. IIRC (pero recomendaría verificar esto) la CSR no incluye la clave privada, por lo que la CA no puede obtenerlo de esa manera. No pueden cambiar las teclas que usan sus máquinas.

Sin embargo, es posible que una CA no autorizada emita un certificado falsificado, y existe la posibilidad de un ataque MITM en su sitio. Problemas recientes con formato MD5 y Etisalat sugieren que no es imposible.

3
symcbean

Tratando de concentrarse en la segunda pregunta.

El problema de "¿Qué certificados raíz de confianza predeterminados debo eliminar?" depende básicamente de con quién tratas.

"Solo" necesitará confiar en todas las CA que firman cualquiera de los sitios web a los que se conecta.

Para un usuario de tipo abuela que siempre visita los mismos pocos sitios, probablemente un puñado de AC será suficiente, mientras que la lista no crecerá tan rápidamente * para un usuario de Internet pesado.

¿Por qué no tan rápido ? Contrariamente a la intuición, algunas AC se usan mucho (incluidas las demasiado grandes para fallar), mientras que otras apenas se usan en Internet, como algunas casi geográficas.

La herramienta SSLCop from securitybydefault puede ayudar a bloquear países que desconfía/es poco probable que necesite (por ejemplo, no espera acceder a un sitio web del gobierno de Brobdingnag, que pasa a ser el usuario principal de esa CA): http://www.security-projects.com/?SSLCop

Sin embargo, si desconfía de demasiadas CA, terminará no siendo capaz de obtener un ancla de confianza para los sitios web que sus usuarios necesitan (y ellos accederán a ellas de todos modos, a pesar de la advertencia de seguridad), que es igualmente malo.

1
Ángel

Demostración de la creación de una entidad no autorizada utilizando debilidades MD5:

1
Bradley Kreider

A partir del 12 de junio de 2012, Microsoft lanzó un nuevo actualizador que deshabilitará los certificados raíz no confiables y cualquier otro certificado que se informe a Microsoft como no confiable.

La actualización está disponible aquí, y no estoy claro si esta actualización ya se ha distribuido a través de las Actualizaciones de Windows, o si es una actualización fuera de banda.

http://support.Microsoft.com/kb/267707

0