¿Cómo se evita la falsificación de certificados con CA baratas?

8

Para realizar un ataque exitoso en el ataque central a HTTPS, uno necesita eliminar la capa SSL y convertirla a HTTP completamente o debe tener un certificado válido de una CA para el mismo dominio para volver a cifrar el contenido , por lo tanto tienen una barra verde.

Muchos proveedores de SSL baratos le permiten obtener certificados SSL para nombres de dominio sin poner mucho esfuerzo en la verificación. La situación podría ser mejor para las empresas nacionales, pero las empresas extranjeras solo necesitan enviar por fax algunos documentos "atractivos", eso es todo.

¿Cuál es el mecanismo que nos impide obtener un certificado SSL válido para, por ejemplo, google.com?

La CRL es solo una medida posterior al desastre y podría ser demasiado tarde antes de que se emita una CRL. ¿Qué me falta en la imagen aquí?

EDIT: Interesante, un mes después de hacer esta pregunta, una autoridad de certificación turca emitida un certificado para una solicitud falsa de dominio google.com , el ejemplo que utilicé :)

    
pregunta Sedat Kapanoglu 23.11.2012 - 13:08
fuente

2 respuestas

10

Para un ataque exitoso, el atacante debe obtener un certificado SSL de una de las CA en la que confía la víctima , o debe inducir a la víctima a ignorar la advertencia aterradora de que su navegador mostrar.

Los navegadores y sistemas operativos existentes se envían con un centenar de "CA confiables" y es cierto que si se engaña o soborna a uno para emitir un certificado falso, entonces el certificado falso se puede usar para construir un servidor HTTPS falso . El atacante todavía tendría que hacer que las conexiones vayan a su servidor, ya sea con enlaces de correos electrónicos no deseados o ataques de intermediarios.

Ha ocurrido . El artículo de noticias ha utilizado tales eventos como base para profecizar el Fin de Internet, el Ragnarok digital que nos sumirá al caos; así es como funcionan los medios de comunicación (las malas noticias son buenas noticias y el Apocalipsis es difícil de superar). Sin embargo, lo que es interesante notar es que:

  • No sucedió a menudo . Un par de veces (muy publicitadas).
  • El agujero se llenó rápidamente de nuevo (en particular, Microsoft presionó un parche explícito para "deshabilitar" los certificados ofensivos, como una CRL que no puedes evadir).

El punto aquí es que obtener un certificado falso es solo un paso en todo el asunto, e incluso si se puede hacer, es mucho más difícil hacerlo de manera discreta. Cuando el atacante ha obtenido el certificado falso, no tiene mucho tiempo antes de que se descubra la emisión falsa. Por otro lado, una estafa exitosa (ya sea con un intermediario o una gran cantidad de spam) necesita preparación, atención y algo de tiempo. En cierto modo, la corrupción de una CA de confianza pone en peligro toda la operación, ya que otorga exposición al atacante.

Por otro lado, la credibilidad del usuario es una constante probada; No hay falta de ello. Es mucho más fácil, y mucho menos riesgoso (para el atacante), usarlo y hacer que el usuario ignore las advertencias del navegador. Por lo tanto, en la práctica , las CA existentes rara vez se corrompen.

Para resumir: sí, con el sistema CA actual, la certificación es tan sólida como la CA más confiable, y eso no es muy seguro, pero, en este mundo y día, esto es suficientemente seguro . El sistema web SSL funciona . El día en que el sistema SSL se desmorone será el día en que más fácilmente se hayan cerrado las rutas de ataque, y los usuarios se hayan vuelto prudentes y sensatos, y los atacantes no tendrán más remedio que obtener certificados falsos. Esto será causa para regocijarse , no llorar.

(Pero recuerde que el Web + SSL actual funciona debido a economía : los atacantes no merecen el esfuerzo de atacar CA. Tenga cuidado si intenta aplicar el mismo modelo en otro lugar, donde el dinero y el comercio funciona de manera diferente, por ejemplo, para asegurar el sistema de lanzamiento de misiles nucleares. Un análisis de seguridad siempre depende del modelo de amenaza .)

    
respondido por el Thomas Pornin 23.11.2012 - 13:42
fuente
3

Creo que no hay una solución real para este problema. Los siguientes intentos me son conocidos para este problema:

  1. CRL (pero esto es solo una medida posterior al desastre mientras escribe)
  2. Eliminar CA de la lista de CA confiables, pero esto también es solo una medida posterior al desastre.
  3. No agregue dichas CA a la lista de CA confiables. Aquí el problema es dónde dibujar la línea.
  4. Corrija los certificados / hosts a una determinada CA, ya que Google está haciendo esto para Chrome.

Creo que la estructura de CA completa está rota, ya que se implementa en este momento. No conozco ninguna solución a esto en este momento, pero creo que algo tiene que cambiar para el futuro.

Una solución probable podría ser tener solo una CA central (¿es esto realmente una solución? ¿Quién debería ejecutar esta CA?).

Otra solución podría ser una red de confianza en la que tendríamos que descartar todas las soluciones existentes como lo son ahora ...

También una solución podría ser que cada usuario importe sus propias CA, pero para muchos usuarios esta no sería la solución final ...

Como resultado, creo que no habrá una solución viable en un futuro próximo para esto.

    
respondido por el Uwe Plonus 23.11.2012 - 13:22
fuente

Lea otras preguntas en las etiquetas