Malentendido SSL y man-in-the-middle

91

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)?

Vadim Chekry
fuente

Respuestas:

106

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.

Joachim Isaksson
fuente
4
También existen herramientas como sslstrip , que intentarán reescribir de forma transparente enlaces https en enlaces http.
mpontillo
3
Otro punto sobre la verificación del certificado es que el cliente debe verificar el nombre de host. No es suficiente verificar que el certificado sea genuino, tiene que ser emitido a la entidad con la que desea hablar (consulte aquí y aquí ). En cuanto a sslstrip, en última instancia, depende del usuario comprobar que, lamentablemente , quiere utilizar SSL / TLS (aunque HSTS puede ayudar).
Bruno
¿Podría escribir un complemento de Chrome (o cualquier otro navegador para el caso) que intercepte los datos ANTES de que el navegador los cifre?
Rosdi Kasim
Otro motivo es el "uso indebido de la confianza", como en el caso de TürkTrust.
Ceremcem
1
@Remover No realmente ... # 1 es la clave privada en el servidor, emparejada con la clave pública genuina. En este escenario, hablaría con el servidor real, pero alguien más podría descifrar el tráfico estando en el medio. No pueden modificar el certificado. El número 2 implica el envío de un certificado completamente diferente, emitido por una CA "confiable" que le parecerá legítima al cliente. El atacante puede enviar solicitudes en su nombre y ver los mensajes de esa manera. Ambos resultan en un compromiso, pero el # 1 está bajo su control. # 2, desafortunadamente, no lo es.
Básico
17

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.

Marqués de Lorne
fuente
Gracias por su explicación. Lo único que no entendí es por qué dijiste que un cliente no envía una clave de sesión a un servidor. Bueno, tal vez he usado una terminología incorrecta, aquí este dato se llama "secreto previo al maestro", pero de todos modos, ¿no es enviado por el cliente y está descifrado con la clave privada del servidor?
Vadim Chekry
1
@VadimChekry El secreto anterior al maestro no es la clave de sesión. Es uno de los varios datos que se utilizan para generar la clave de sesión, independientemente en ambos extremos. El proceso se describe en RFC 2246.
Marqués de Lorne
1
@Chris Eres mucho menos vulnerable, sin embargo, la suplantación de direcciones IP es posible. No hay sustituto para verificar la identidad de los pares en el certificado usted mismo.
Marqués de Lorne
1
+1 Esta es una respuesta bastante buena, en su mayor parte. Sin embargo, algunos puntos carecen de explicación con respuestas de una palabra. Podría convertirla en una respuesta definitiva si ampliara y / o desarrollara dichos puntos (es decir, en lugar de "no", podría mencionar brevemente lo que realmente sucede) en el cuerpo principal. Eso realmente aclararía algunas cosas. Gracias.
voces
1
@ tjt263 El primer 'no' proporciona una explicación de lo que realmente sucede. Los siguientes dos "no" se refieren al mismo concepto erróneo que produjo el primer "no" y tienen la misma explicación. El siguiente y final "no" se refiere a "estoy equivocado" y se refiere a la información que se acaba de citar del OP. Por lo tanto, es difícil entender lo que cree que realmente falta aquí.
Marqués de Lorne
17

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.

bbsimonbb
fuente
Pero esto significa que este equipo MITM (el que descifra / escanea y vuelve a cifrar el tráfico) necesita tener acceso a una de las CA de confianza, ¿verdad? (para "falsificar" el certificado del servidor). Digamos que esto sucede. Entonces alguien rompe esto, la información se hace pública, y habrá un escándalo en la prensa y el certificado de CA será eliminado de todos los navegadores, ¿verdad? Quiero decir, idealmente ...
jazzcat
2
No no. La "Inspección SSL" en la puerta de enlace necesita crear y firmar certificados sobre la marcha, pero no necesita un certificado raíz para hacer esto. Tiene algún certificado intermedio, que tiene cadena. Si su navegador confía o no en la raíz de la cadena determina si verá un error de certificado. En el trabajo, se nos pidió que instaláramos el certificado raíz de fortinet para que nuestros navegadores no dieran errores de certificado. Pero si la cadena terminó con un certificado ya confiable, es transparente.
bbsimonbb
Un colega en el trabajo estaba usando una comprensión limitada de por qué estas técnicas MITM de redes corporativas son una mala idea para que Google fuerce SSL. ¿Podría realmente tener un poco de corrección?
EmSixTeen
1
¡Lo siento, no entiendo la pregunta!
bbsimonbb
2
  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.
Boynux
fuente
Aproximadamente 2: supongo que el cliente está verificando minuciosamente los metadatos enviados por el servidor durante el procedimiento de establecimiento de la conexión y que el cliente no confía en TODOS los certificados. Entonces, ¿no sería posible tal escenario si: a) un cliente no está haciendo lo que dije anteriormente, ob) un intermediario tiene en algún lugar un certificado firmado por una CA confiable?
Vadim Chekry
1
Es muy raro que el servidor intermedio envíe un certificado válido, el año pasado pasó con Comodo CA si no recuerdo mal. Pero normalmente si se trata de una conexión de confianza, entonces es completamente segura.
Boynux
1

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.

David Schwartz
fuente