¿Se puede comprometer una conexión HTTPS debido a un servidor DNS no autorizado?

Para conectarse a cualquier sitio web, a través de https o no, necesita la dirección IP del sitio y le solicita a su servidor DNS que use el nombre de dominio de su sitio. Si su servidor DNS no ha guardado la respuesta, intentará resolver su solicitud preguntando a toda una serie de servidores DNS (el servidor dns raíz, el controlador de dominio de nivel superior ... hasta el servidor dns que es autoritario para el dominio) .

Un atacante que controla cualquiera de esos servidores puede responderle con una dirección IP falsa para ese sitio web, y esto es lo que su navegador intentará visitar. Esta dirección IP en el caso general tendrá una réplica del sitio web alojado, para que tenga el mismo aspecto que la original, o simplemente actuará como un reenviador silencioso de su conexión al sitio correcto después de capturar lo que necesita.

Ahora a más detalles: si el sitio web está protegido por HTTPS, habrá muchos escollos. El sitio web normal tendrá un certificado emitido que vincula los detalles del nombre de dominio con el sitio web, pero esto se realiza mediante cifrado asimétrico.

Lo que esto significa es que a través del proceso de protocolo de enlace SSL, el sitio web debe demostrar que tiene conocimiento de la clave privada asociada con la clave pública en el certificado. Ahora, la parte maliciosa puede proporcionarle el certificado original del sitio web cuando intente acceder a la IP incorrecta con el nombre de host correcto, pero no tendrá conocimiento de la clave privada, por lo que el protocolo de enlace de SSL nunca se completará.

Pero hay formas en que el interceptor puede hacer que todo funcione, puedo pensar en cuatro:

1) La solución más sencilla es entregarle un certificado autofirmado en lugar de uno normal. Esto será emitido por el propio atacante. Normalmente, tu navegador te lo advertirá, y si ejecutas una versión reciente del navegador, las advertencias estarán por todos lados, pero los usuarios tienden a hacer clic en ese tipo de cosas ...

2) Otro enfoque, utilizado en los ataques de Stuxnet, es robar las claves privadas utilizadas para un certificado válido de la organización que desea suplantar.

3) Otra solución, que ha ocurrido en un par de casos (no estamos hablando del atacante promedio aquí) es que explota alguna falla en el procedimiento de registro que usan las autoridades de certificación (o autoridades de registro), y se las arregla para emitir un certificado para un sitio web que no le pertenece. Ha habido casos en que las RA simplemente no hicieron suficientes controles y emitieron certificados para google.com ..

4) Similar a lo anterior: un atacante competente 'piratea' un certificado o autoridad de registro y logra emitir algunos certificados con el nombre que quiera. Ocurrió en mayo de 2011 (el famoso comodo-hack) y en julio de 2011 (el hack de DigiNotar). Ver más detalles en ¿Qué tan factible es que una CA sea hackeada? ¿Qué certificados raíz de confianza predeterminados debo eliminar? - Seguridad de TI .

5) Finalmente, la técnica más aterradora es la que pueden usar agencias de tres letras y partes similares: si un gobierno controla una Autoridad de Certificación, en teoría puede forzarla a emitir certificados a voluntad, para cualquier sitio. Ahora piense que las Autoridades de Certificación se extienden por todo el mundo, algunas de ellas en países donde esto puede parecer muy posible. Un ejemplo que se puede ver aquí es la CA operada por la Corporación de Telecomunicaciones de Emiratos (Etisalat), que pertenece en un 60% al gobierno de los Emiratos Árabes Unidos (EAU). Etisalat una vez lanzó un parche de BlackBerry de aspecto inocuo que insertó spyware en los dispositivos RIM, lo que permite el monitoreo del correo electrónico.

Además, si el cliente aún admite el antiguo protocolo SSL 2.0, un MITM puede degradar la conexión SSL y usar un algoritmo de cifrado simétrico más débil o un intercambio de claves más débil.

Para resumir, si el atacante controla el servidor DNS, puede hacer cosas muy maliciosas, pero para interceptar el tráfico cifrado SSL necesita algo más que eso.

Y para responder a su última pregunta: el sitio de la CA no necesita resolverse cada vez que visita un sitio: el sitio web generalmente le entrega el certificado público que usa, pero es posible que lo obtenga de la CA . Esto no cambia ninguna de las cosas mencionadas anteriormente, sin embargo.

No debería ser posible. Si el atacante puede controlar su DNS, puede redirigirlo a un servidor comprometido. Pero su navegador (si está configurado correctamente) le advertirá sobre un certificado roto.

Pero, de hecho, es posible ! En el caso de que el servidor no tenga un certificado válido, su navegador le avisará cuando se conecte al servidor real y cuando se conecte a la máquina de los atacantes. No puede decidir si esta advertencia es crítica.
En otro escenario, el atacante pudo obtener el certificado válido del servidor (ver, por ejemplo, here ). Entonces, él puede redirigirlo a un servidor comprometido y su navegador no dirá nada ...

Además de la excelente respuesta de @ John, un servidor DNS falso puede causar otros daños, además de cualquier efecto en la conexión HTTPS actual (aunque esto está estrictamente fuera del alcance de su pregunta, creo que sigue siendo relevante). Hay varios tipos de daños que puede hacer, además de intentar escuchar a escondidas su conexión actual.

Si le está pidiendo a un servidor DNS malicioso que le resuelva las direcciones, puede darle respuestas que no solicitó, lo que afectará a cualquier otra conexión que cree, incluso después de que deje de usar el DNS deshonesto .
P.ej. utilizando técnicas de envenenamiento de DNS . (Consulte también mi respuesta a esta pregunta .)

Además, el DNS malintencionado puede redirigirlo a otro servidor, por ejemplo. un servidor víctima que ahora será inundado por solicitudes falsas.

Además de todo eso, ¿quién te garantiza que realmente haces la conexión SSL? La mayoría de los usuarios no se molestan en escribir "aich tee tee pee ESS(!) colon whack whack... " ... Simplemente escribirán el nombre de dominio (por ejemplo, "mybank") y presionarán ctrl + enter, o harán que el motor de búsqueda aparezca, o ... y en En todos esos casos, es probable que la solicitud inicial del usuario ni siquiera sea HTTPS. (Por supuesto, si do lo escribe específicamente, es diferente, así que YMMV en ese punto).

También sugiero echar un vistazo a algunas de las respuestas en "¿Qué implica tomar el nombre de dominio de otra persona?"

Algunos proxies corporativos (que operan a través de la redirección de DNS o una variedad de otros medios) pueden inspeccionar el contenido de una conexión SSL. Además, los usuarios de un escritorio administrado no recibirán una advertencia del navegador si el certificado MITM se ha instalado en el almacén local.

Dependiendo de quién administre el proxy y de cómo se utilicen sus registros, esto puede ser aceptable o malo desde su perspectiva.

Para obtener más información sobre cómo se realiza la intercepción de SSL, consulte enlace :

  

Cuando el proxy SSL intercepta un SSL   Conexión, presenta un emulado.   certificado de servidor al cliente   navegador. El navegador del cliente emite un   ventana emergente de seguridad para el usuario final   porque el navegador no confía en el   Emisor utilizado por el ProxySG. Esta   ventana emergente no se produce si el emisor   certificado utilizado por SSL Proxy es   importado como una raíz de confianza en el   almacén de certificados del navegador del cliente.

     

El ProxySG hace todo configurado   certificados disponibles para descargar   A través de su consola de gestión. Usted puede   Pedir a los usuarios finales que descarguen el emisor.   Certificado a través de Internet Explorer   o Firefox e instalarlo como un confiable   CA en su navegador de elección. Esta   elimina el certificado emergente para   certificados emulados ...

Más información ...

Otro punto: un atacante que posee su sistema de resolución de DNS puede desviar las solicitudes de OCSP o CRL a un agujero negro, y virtualmente todos los navegadores lo considerarán como evidencia de que el certificado no ha sido revocado. Por lo tanto, si sucede que un chico malo roba un certificado válido pero el hombre bueno lo revoca, el chico malo puede evitar que los clientes vean esa revocación haciendo un hueco en la solicitud de OCSP / CRL.

Porque es difícil diferenciar los sitios de phishing. Aquí está el observatorio de EFFs SSL.

enlace

La idea general es sólida, las suplantaciones se deben a la emisión incorrecta de certificados. Si pudiera estar seguro de que todos los demás, al enfrentarse a un certificado, tenían exactamente el mismo certificado, entonces la probabilidad de que sea un sitio de phishing sería casi cero. La parte asombrosa de la investigación es el número de nodos de hoja y entidades emisoras de certificados que son de confianza para el navegador.

En su caso, la pregunta es NO, la conexión HTTPS NO SE PUEDE comprometer.

Ahora, averigüemos por qué.

1. Su navegador tiene claves públicas de la CA. Claves públicas de confianza.

2. Suponiendo que el atacante no solo puede controlar el DNS, sino también los propios servidores, en este caso, tanto la CA como los servidores HTTP de destino.

3. El atacante NO PUEDE falsificar la CA porque no tiene claves privadas coincidentes como su navegador.

4. El atacante NO PUEDE falsificar el servidor HTTP, ya que su certificado no tendrá el sello de una CA de confianza.

En el caso extremo de que el atacante pueda obtener un certificado para el dominio que no controla / posee, entonces el punto anterior no es válido. Y el atacante puede hacer lo que su imaginación pueda conjurar. La cuestión es que esto viola nuestra suposición de que la CA es confiable. Es culpa de la CA que otorga al atacante dicho certificado. Y cuando CA ya no es confiable, SSL es solo un tigre de papel.

Hay un ataque combinado que engañaría a la mayoría de la gente enlace

El atacante actúa como un hombre en el medio y configura un enlace no cifrado al victum que muestra http: // ... en el navegador, pero el candado está activado y verde para que la gente se pierda la falta de https: // ...