Este documento dice que una autenticación de respuesta de desafío prueba la identidad de los servidores. Pero, ¿es posible un hombre en el ataque central si el cliente no verifica el nombre de dominio? Por favor, ayúdame a entender esto.
Este documento dice que una autenticación de respuesta de desafío prueba la identidad de los servidores. Pero, ¿es posible un hombre en el ataque central si el cliente no verifica el nombre de dominio? Por favor, ayúdame a entender esto.
El protocolo de enlace SSL implica el uso de certificados; el servidor tiene un certificado que el cliente debe validar (con respecto a sus anclajes de confianza conocidos, también conocido como "CA raíz"). El certificado contiene una clave pública y los algoritmos criptográficos utilizados en SSL aseguran que la conexión es segura de la siguiente manera:
El cliente sabe que cualquier información que envíe y reciba solo podrá ser utilizada por el servidor que posee la clave privada asociada con la clave pública que recibió (dentro de un certificado).
El certificado demuestra al cliente que dicha clave privada es propiedad (controlada) por alguna entidad cuyo nombre está escrito en el certificado; para SSL, el nombre es un nombre DNS como "www.example.com".
Aún depende del cliente verificar que el nombre en el certificado sea el nombre del servidor con el que el cliente intentó comunicarse en primer lugar.
Analogía: te encuentras con alguien que te dice que su nombre es Bob. Le pides que te muestre una tarjeta de identificación. Verificar que la tarjeta de identificación es una tarjeta de identificación genuina no es suficiente; Usted también tiene que verificar que el nombre en la tarjeta de identificación sea "Bob". De lo contrario, Charlie podría decirte "Soy Bob" y mostrarte su tarjeta de identificación con el nombre "Charlie".
La respuesta de Thomas es genial en lo que va. Solo señalaré que todavía hay agujeros en el sistema, y tiene derecho a prestar mucha atención.
El agujero más grande es que, de manera predeterminada, es probable que tenga una gran cantidad de certificados raíz "de confianza", cualquiera de los cuales puede certificar cualquier nombre de DNS. Creo que hay razones para no confiar realmente en todos ellos.
Por ejemplo, en 2009, Etisalat (60% de propiedad del gobierno de los Emiratos Árabes Unidos), lanzó un parche de BlackBerry de apariencia inocua que insertó el software espía en los dispositivos RIM, permitiendo el monitoreo del correo electrónico, por lo que difícilmente puede considerarse confiable. . Pero está en muchas listas de CA confiables: enlace
Los mecanismos utilizados por muchas entidades emisoras de certificados para validar que posee un nombre de dominio son vulnerables a diversos ataques, por lo que la gente puede obtener credenciales que no deberían.
Además, las personas pueden robar certificados, como hicieron dos veces los desarrolladores de stuxnet.
Las partes relacionadas con las políticas del rompecabezas de la clave pública / privada son realmente mucho más difíciles que el criptografía en sí.
Actualización: Consulte también una excelente publicación sobre cómo arreglar nuestra peligrosa infraestructura de CA en Freedom to Tinker: Construyendo una mejor infraestructura de CA
Un servidor comprueba su identidad al estar firmado por una autoridad de certificación raíz (o intermediaria) en la que confía su navegador.
La CA raíz (por ejemplo, Verisign) firmará digitalmente la solicitud de certificado del sitio. La firma digital es la forma en que Verisign certifica la identidad del sitio web original. Verisign tiene métodos para evitar que alguien como yo genere un certificado para eBay, generalmente a través del registro en persona o mediante una combinación de pruebas de identidad.
La lista de entidades emisoras de certificados raíz se actualiza y revoca a medida que transcurre el tiempo; es posible que lo note en su actualización de Windows.
Dicho esto, si alguien tiene acceso físico a una máquina, siempre puede instalar certificados de raíz falsos ... lo que hace que el hombre en el medio sea posible de nuevo, sin advertencias.
Lea otras preguntas en las etiquetas authentication public-key-infrastructure cryptography tls certificates