¿Cómo se puede usar un certificado HTTPS “alternativo” o duplicado en un ataque?

4

Inspirado por una vieja pregunta de PulpSpy , estoy tratando de piense si esto es una debilidad significativa en el sistema de la Autoridad de Certificación. Estos son los métodos de ataque que creo que funcionarían. Por favor, comente, critique y agregue más de lo que pueda pensar:

  1. Obtenga una CA de menor reputación para emitir un certificado básico HTTPS. Manipule las solicitudes de DNS del destino para dirigir el tráfico a un servidor que usted controla, lo que dará la apariencia de una conexión HTTPS "válida" (en ausencia de precauciones adicionales, por ejemplo, Patrulla de certificados ).

  2. Snipe un dominio activo, obtenga una CA acreditada para emitir un certificado EV. La existencia del certificado EV se puede usar para retrasar / impedir que el propietario "verdadero" recupere el control, porque los francotiradores del dominio ahora tienen una mejor prueba de propiedad.

I think DNSSEC protegerá contra el # 1 en los casos en que los anclajes de confianza se implementen a través de los navegadores (por ejemplo, Firefox), y el instalador del navegador esté firmado. El problema obvio es que no muchos dominios están habilitados para DNSSEC. (Contrapunto: muchos dominios importantes están habilitados para DNSSEC).

¿Hay otros métodos de ataque?

    
pregunta scuzzy-delta 14.01.2013 - 02:00
fuente

2 respuestas

3

Para SSL en sí mismo, un certificado falso puede solo servir como una forma de ejecutar un servidor falso. Esto requiere interceptar las conexiones de algunos clientes al verdadero servidor y redirigirlas a su servidor. Manipular el DNS es solo una forma de hacerlo (es cierto, a menudo la más fácil) y DNSSEC está destinado a protegerse contra eso (ya que DNSSEC trata de "asegurar" con firmas lo que devuelven los servidores DNS). Si el atacante controla un enrutador / servidor de seguridad entre el cliente y el servidor, puede redirigir todo el tráfico que desee sin necesidad de cambiar nada en el DNS.

Su punto # 2 es más una Denegación de Servicio que cualquier otra cosa. Resalta que cuando se implementan procedimientos de autenticación más pesados (por ejemplo, los procedimientos que se realizan antes de emitir un certificado EV), hace que los contratiempos sean menos probables (más difíciles para el atacante) pero también más profundos (la recuperación podría ser más larga). Este es un punto que debe tenerse en cuenta en toda la compensación de seguridad.

    
respondido por el Thomas Pornin 14.01.2013 - 13:38
fuente
0

El propio DNSSEC no protege contra nada de esto. DNSSEC solo protege las respuestas de DNS, por lo que no se pueden falsificar fácilmente. Pero debido a que se puede confiar a DNS con DNSSEC, utilizando DANE se puede almacenar un hash del certificado en el DNS.

Lamentablemente, en este momento casi ningún cliente lo comprueba. Para la mayoría de los navegadores hay un Addon que verifica los registros DNSSEC / DANE.

DANE permite que el propietario del dominio especifique uno (o más) los certificados que se permitirán para el dominio, o que limite la CA de la cual deben aceptarse los certificados para el dominio. Con el soporte completo del navegador, significaría que no se necesita una CA y que DNSSEC / DANE es suficiente para verificar el certificado.

Para tu segunda pregunta: 1. debe hacer cada pregunta por separado en este sitio, 2. hay conjuntos de reglas específicas que tratan con disputas de dominio, según el TLD, el país, etc. No tengo conocimiento de que tener un certificado EV tenga algún significado en ninguno de ellos, pero podría serlo.

    
respondido por el Josef 04.11.2015 - 11:21
fuente

Lea otras preguntas en las etiquetas