security - SSL y malentendido en el hombre en el medio
man-in-the-middle (5)
He leído toneladas de documentación relacionada con este problema, pero todavía no puedo reunir todas las piezas, por lo que me gustaría hacer un par de preguntas.
En primer lugar, describiré brevemente el procedimiento de autenticación tal como lo entiendo, ya que puedo estar equivocado al respecto: un cliente inicia una conexión a la que responde un servidor con una combinación de clave pública, algunos metadatos y firma digital de un autoridad de confianza Luego, el cliente toma la decisión si confía en el servidor, encripta una clave de sesión aleatoria con la clave pública y la envía de vuelta. Esta clave de sesión se puede descifrar solo con una clave privada almacenada en el servidor. El servidor hace esto y luego comienza la sesión HTTPS.
Entonces, si estoy en lo correcto, la pregunta es ¿cómo puede ocurrir el ataque de hombre en el medio en tal escenario? Quiero decir, incluso si alguien intercepta la respuesta del servidor (por ejemplo, www.server.com) con la clave pública y tiene algunos medios para hacerme pensar que es www.server.com, todavía no podría descifrar mi clave de sesión sin la clave privada.
Hablando de la autenticación mutua, ¿se trata de la confianza del servidor sobre la identidad del cliente? Quiero decir, el cliente ya puede estar seguro de que ella se está comunicando con el servidor correcto, pero ahora el servidor quiere saber quién es el cliente, ¿verdad?
Y la última pregunta es sobre la alternativa a la autenticación mutua. Si actúo como cliente en la situación descrita, ¿qué sucede si envío un nombre de usuario / contraseña en el encabezado HTTP después de que se establezca la sesión SSL? Tal como lo veo, esta información no puede ser interceptada porque la conexión ya está asegurada y el servidor puede confiar en ella para mi identificación. ¿Me equivoco? ¿Cuáles son las desventajas de este enfoque en comparación con la autenticación mutua (solo los problemas de seguridad son importantes, no la complejidad de la implementación)?
Antes que nada describiré brevemente el procedimiento de autenticación tal como lo entiendo, tal vez estoy equivocado en ese paso. Entonces, un cliente inicia una conexión y un servidor responde con una combinación de clave pública, algunos metadatos y firma digital de una autoridad de confianza.
El servidor responde con una cadena de certificados X.509 y una firma digital firmada con su propia clave privada.
Entonces el cliente toma la decisión si ella confía en el servidor
Correcto.
encripta una clave de sesión aleatoria con la clave pública y la envía de vuelta.
No. El cliente y el servidor participan en un proceso de generación de claves de sesiones mutuas mediante el cual la clave de sesión nunca se transmite en absoluto.
Esta clave de sesión se puede descifrar solo con una clave privada almacenada en el servidor.
No.
Servidor hace esto
No.
y luego comienza la sesión HTTPS.
Comienza la sesión de TLS / SSL , pero primero hay más pasos.
Entonces, si estoy en lo correcto, la pregunta es ¿cómo puede ocurrir el ataque de hombre en el medio en tal escenario?
Enmascarando como el servidor y actuando como el punto final SSL. El cliente debería omitir cualquier paso de autorización. Lamentablemente, el único paso de autorización en la mayoría de las sesiones HTTPS es una comprobación de nombre de host.
Quiero decir que incluso si alguien intercepta la respuesta del servidor (por ejemplo, www.server.com) con la clave pública y luego, con algunos medios, déjame pensar que es www.server.com, todavía no podría descifrar mi clave de sesión sin la clave privada.
Véase más arriba. No hay una clave de sesión para descifrar. La conexión SSL en sí misma es segura, es con quién está hablando que puede no ser segura.
Hablando de la autenticación mutua, ¿se trata de la confianza del servidor sobre la identidad del cliente? Quiero decir, que el cliente ya puede estar seguro de que se está comunicando con el servidor correcto, pero ahora el servidor quiere saber quién es el cliente, ¿verdad?
Correcto.
Y la última pregunta es sobre la alternativa a la autenticación mutua. Si actúo como cliente en la situación descrita, ¿qué sucede si envío un nombre de usuario / contraseña en el encabezado HTTP después de que se establezca la sesión SSL? Como veo, esta información no puede ser interceptada porque la conexión ya está asegurada y el servidor puede confiar en ella para mi identificación. ¿Me equivoco?
No.
¿Cuáles son las desventajas de dicho enfoque en comparación con la autenticación mutua (solo los problemas de seguridad son importantes, no la complejidad de la implementación)?
Es tan seguro como el nombre de usuario / contraseña, que son mucho más fáciles de filtrar que una clave privada.
- Correcto
- No tan correcto En ese tipo de ataque, el servidor intermedio recibe su solicitud y la envía a su destino en nombre suyo. y luego responderte con el resultado. En realidad, es el servidor man-in-the-middle el que establece una conexión segura con usted, no con el servidor real al que tiene la intención de comunicarse. es por eso que siempre DEBE verificar que el certificado sea válido y de confianza.
- podría ser correcto
- Si está seguro de que la conexión segura es confiable, entonces sería seguro enviar el nombre de usuario / contraseña.
Cualquier persona en el camino entre el cliente y el servidor puede organizar a un hombre en el ataque medio en https. Si cree que esto es poco probable o raro, considere que hay productos comerciales que descifran, escanean y vuelven a encriptar sistemáticamente todo el tráfico ssl a través de una puerta de enlace de Internet . Funcionan enviando al cliente un certificado ssl creado sobre la marcha con los detalles copiados del certificado SSL "real", pero firmado con una cadena de certificados diferente. Si esta cadena termina con cualquiera de las CA de confianza del navegador, este MITM será invisible para el usuario. Estos productos se venden principalmente a las empresas para redes corporativas "seguras" (policiales), y deben utilizarse con el conocimiento y consentimiento de los usuarios. Sin embargo, técnicamente, no hay nada que detenga su uso por los ISP o cualquier otro proveedor de red. (Sería seguro asumir que la NSA tiene al menos una clave de firma de CA raíz de confianza )
Si está publicando una página, puede incluir un encabezado HTTP que indique con qué clave pública debe firmarse la página. Esto puede ayudar a alertar a los usuarios sobre el MITM de su conexión "segura", pero es una técnica de confianza en el primer uso. Si Bob todavía no tiene un registro del pin de clave pública "real", Mallory simplemente reescribe el encabezado de pkp en el documento. La lista de sitios web que usan esta tecnología es deprimentemente corta. Incluye google y dropbox, para su crédito.
En cuanto a las contraseñas, todo en una conexión https está protegido por https, excepto el nombre de dominio, que debe estar en claro para que la solicitud pueda enrutarse. En general, se recomienda no colocar contraseñas en la cadena de consulta, donde pueden colgar en registros, marcadores, etc. Pero la cadena de consulta no está visible a menos que https esté en peligro.
Los ataques Man-in-the-middle en SSL solo son posibles si una de las condiciones previas de SSL está rota, aquí hay algunos ejemplos;
La clave del servidor ha sido robada: significa que el atacante puede parecer ser el servidor, y no hay forma de que el cliente lo sepa.
El cliente confía en una entidad emisora de certificados no confiable (o en la que se ha robado su clave raíz): quien posee una clave CA confiable puede generar un certificado que pretende ser el servidor y el cliente confiará en él. Con el número de CA preexistentes en los navegadores de hoy, esto puede ser un problema real. Esto significa que el certificado del servidor parecería cambiar a otro válido, que es algo que la mayoría de los clientes le ocultan.
El cliente no se molesta en validar el certificado correctamente contra su lista de CA confiables; cualquiera puede crear una CA. Sin validación, "Cars and Certificates de Ben" parecerá tan válido como Verisign.
El cliente ha sido atacado y se ha inyectado una entidad emisora de certificados falsa en sus autoridades raíz de confianza: le permite al atacante generar cualquier certificado que desee y el cliente confiará en él. El malware tiende a hacer esto para, por ejemplo, redirigirlo a sitios bancarios falsos.
Especialmente el # 2 es bastante desagradable, incluso si pagas por un certificado altamente confiable, tu sitio no estará de ninguna manera vinculado a ese certificado, tienes que confiar en todas las CA en el navegador del cliente, ya que cualquiera de ellos puede generar un certificado falso para su sitio que es tan válido Tampoco requiere acceso al servidor o al cliente.
Todo lo que ha dicho es correcto, excepto la parte sobre la clave de sesión. El objetivo de las CA es vencer a un ataque de hombre en el medio: todo lo demás lo hace SSL mismo. La autenticación del cliente es una alternativa a un esquema de nombre de usuario y contraseña.