Malentendido SSL y man-in-the-middle

He leído toneladas de documentación relacionada con este problema, pero todavía no puedo unir todas las piezas, así que me gustaría hacer un par de preguntas.

1. 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 un servidor responde 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, cifra alguna clave de sesión aleatoria con la clave pública y la envía de vuelta. Esta clave de sesión solo se puede descifrar con la clave privada almacenada en el servidor. El servidor hace esto y luego comienza la sesión HTTPS.

2. Entonces, si estoy en lo correcto arriba, la pregunta es ¿cómo puede ocurrir el ataque de intermediario en tal escenario? Quiero decir, incluso si alguien intercepta la respuesta del servidor (por ejemplo, www.server.com) con una clave pública y tiene algún medio para hacerme pensar que él es www.server.com, todavía no podría descifrar mi clave de sesión. sin la clave privada.

3. 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 se está comunicando con el servidor correcto, pero ahora el servidor quiere saber quién es el cliente, ¿verdad?

4. 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 establece la sesión SSL? Como yo 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 son importantes las cuestiones de seguridad, no la complejidad de la implementación)?

Los ataques man-in-the-middle en SSL solo son posibles si se rompe una de las condiciones previas de SSL, aquí hay algunos ejemplos;

• La clave del servidor ha sido robada, lo que significa que el atacante puede parecer el servidor y no hay forma de que el cliente lo sepa.

• El cliente confía en una CA que no es de confianza (o una a la que le han robado la clave raíz): quien tenga una clave CA confiable puede generar un certificado que pretende ser el servidor y el cliente confiará en él. Con la cantidad de CA existentes en los navegadores en la actualidad, 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 ocultarán.

• El cliente no se molesta en validar el certificado correctamente con su lista de CA confiables; cualquiera puede crear una CA. Sin validación, los "Autos y certificados de Ben" parecerán ser tan válidos como Verisign.

• El cliente ha sido atacado y se ha inyectado una CA falsa en sus autoridades raíz de confianza; 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 n. ° 2 es bastante desagradable, incluso si paga por un certificado de alta confianza, su sitio no estará bloqueado de ninguna manera para ese certificado, debe confiar en todas las CA en el navegador del cliente, ya que cualquiera de ellas puede generar un certificado falso para su sitio que es igualmente válido. Tampoco requiere acceso ni al servidor ni al cliente.

En primer lugar, describiré brevemente el procedimiento de autenticación tal como lo entiendo, tal vez me haya 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 confiable.

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 confía en el servidor.

Correcto.

cifra alguna clave de sesión aleatoria con la clave pública y la devuelve.

No. El cliente y el servidor se involucran en un proceso mutuo de generación de claves de sesión por el cual la clave de sesión en sí nunca se transmite en absoluto.

Esta clave de sesión solo se puede descifrar con la clave privada almacenada en el servidor.

No.

El servidor hace esto

No.

y luego comienza la sesión HTTPS.

La sesión TLS / SSL comienza, pero primero hay más pasos.

Entonces, si estoy en lo correcto arriba, la pregunta es ¿cómo puede ocurrir el ataque man-in-the-middle en tal escenario?

Haciéndose pasar por el servidor y actuando como el punto final SSL. El cliente tendría que omitir cualquier paso de autorización. Lamentablemente, el único paso de autorización en la mayoría de las sesiones HTTPS es una verificación del 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 algún medio, déjeme 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 clave de sesión para descifrar. La conexión SSL en sí es segura, es posible que no sea segura con quién está hablando .

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 establece la sesión SSL? Como veo, esta información no se puede interceptar porque la conexión ya está segura y el servidor puede confiar en ella para mi identificación. ¿Me equivoco?

No.

¿Cuáles son las desventajas de este enfoque en comparación con la autenticación mutua (solo son importantes las cuestiones de seguridad, 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.

Cualquiera que esté en el camino entre el cliente y el servidor puede organizar un ataque intermedio en https. Si cree que esto es poco probable o raro, tenga en cuenta que existen productos comerciales que descifran, escanean y vuelven a cifrar sistemáticamente todo el tráfico ssl a través de una puerta de enlace de Internet.. Trabajan 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 empresas para "asegurar" redes corporativas (policiales) y deben utilizarse con el conocimiento y el consentimiento de los usuarios. Sin embargo, técnicamente no hay nada que impida su uso por parte de 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 confiable ).

Si está publicando una página, puede incluir un encabezado HTTP que indique con qué clave pública se debe firmar 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 aún no tiene un registro del pin de clave pública "real", Mallory simplemente reescribe el encabezado pkp en el documento. La lista de sitios web que utilizan esta tecnología (HPKP) es deprimentemente corta. Incluye google y dropbox, a su favor. Por lo general, una puerta de enlace que intercepta https pasará por las páginas de los pocos grandes sitios de confianza que utilizan HPKP. Si ve un error de HPKP cuando no lo espera, tenga cuidado.

Con respecto a las contraseñas, todo en una conexión https está protegido por https, excepto el nombre de dominio, que debe estar claro para que la solicitud se pueda enrutar. En general, se recomienda no poner contraseñas en la cadena de consulta, donde pueden permanecer en registros, marcadores, etc. Pero la cadena de consulta no es visible a menos que https esté comprometido.

1. Correcto
2. No tan correcto. En ese tipo de ataque, el servidor inmediato recibe su solicitud y la envía a su destino en su nombre. y luego responderte con el resultado. En realidad, es el servidor de intermediario el que hace una conexión segura con usted, no el servidor real que pretende comunicar. es por eso que siempre DEBE verificar que el certificado sea válido y confiable.
3. podría ser correcto
4. Si está seguro de que la conexión segura es confiable, sería seguro enviar un nombre de usuario / contraseña.

Todo lo que ha dicho es correcto excepto la parte sobre la clave de sesión. El objetivo de las CA es derrotar a un ataque man-in-the-middle: todo lo demás lo hace SSL. La autenticación del cliente es una alternativa al esquema de nombre de usuario y contraseña.