¿Puede un MITM de HTTPS descifrar paquetes de respuesta del servidor?

3

Estoy tratando de llenar los vacíos de mi comprensión de HTTPS.

Entiendo que el servidor envía al cliente una clave pública para cifrar la información y que solo el servidor tiene la clave privada que impide la intercepción de los paquetes de solicitud.

¿Qué sucede en el lado de la respuesta de las cosas? P.ej. el servidor de aplicaciones web responde con un token de sesión o responde con información confidencial. ¿Podría un atacante MITM detectar la respuesta de la clave pública inicial del servidor y pretender ser el cliente deseado? ¿O el cliente también tiene una clave privada / pública que utiliza para manejar las respuestas y pasa la clave pública dentro de la solicitud?

Básicamente, me pregunto si puedes pretender ser el cliente, en lugar de la mayoría de MITM donde el atacante pretende ser el servidor.

    
pregunta Cyassin 03.08.2016 - 03:50
fuente

3 respuestas

2

Hay dos problemas separados mencionados en esta pregunta: autenticación y encriptación de sesión.

En cuanto a las escuchas ilegales en la respuesta inicial, es un problema de cifrado de la sesión. Cada sesión entre el cliente y el servidor está protegida mediante una clave diferente. El algoritmo de intercambio de claves (el que se use) garantiza que solo una parte reciba las claves utilizadas para asegurar la transmisión.

Los detalles técnicos ya se explicaron en las respuestas a ¿Cómo funciona SSL / TLS? , pero en breve un Se utilizan pares de claves efímeros. Son independientes de la clave pública enviada por el servidor en el certificado.

Por otra parte, la clave pública del servidor (incluida en el certificado) se usa para la autenticación (en la criptografía de clave pública, cuando usted cifra los datos con una clave privada, la está firmando sin cifrar, cualquiera puede descifrarla con la clave). clave pública conocida públicamente).

Para la autenticación del cliente, también puede usar una autenticación basada en clave, pero este escenario es mucho menos común. Por lo general, se autentica utilizando una contraseña o algún otro método a través de un canal seguro ya establecido. En este escenario, no hay necesidad ni manera de "simular que usted es el cliente previsto " porque en el momento de iniciar la conexión todavía no hay noción de que el cliente previsto .

    
respondido por el techraf 03.08.2016 - 04:28
fuente
2

Como escribió @techraf, TLS proporciona dos cosas: la autenticación y el cifrado.

  

Básicamente, me pregunto si puedes pretender ser el cliente, en lugar de la mayoría de MITM donde el atacante pretende ser el servidor.

Teniéndolo en cuenta, concentrémonos en la autenticación.

La comunicación HTTPS típica a través de Internet se usa para asegurar a los clientes que el servidor es lo que dice ser, por ejemplo. banco electrónico Sin embargo, en el escenario típico de Internet, un servidor no autentica clientes a través de HTTPS. En este ejemplo de banco electrónico, debe proporcionar credenciales para que el banco sepa quién es usted (no su propio certificado).

En el nivel de encriptación: después del protocolo inicial TLS, se negocia una clave simétrica específica de la sesión entre el cliente y el servidor, y es la clave simétrica que se usa para cifrar todo el tráfico en la conexión HTTP en ambos direcciones .

EDITAR: cuando está en el medio del canal de comunicación y rompe la conexión TLS, puede hacerse pasar por ambos lados de la comunicación: un cliente y un servidor. Lo que es un escenario típico de MItM, pero tal como escribió: generalmente queremos engañar a los clientes, no a los servidores.

    
respondido por el boleslaw.smialy 03.08.2016 - 10:02
fuente
2

Un recurso útil sobre esto es Los primeros milisegundos de una conexión HTTPS .

La criptografía de clave pública se utiliza para autenticar el servidor al cliente. Es decir, no se puede engañar al cliente para que se conecte a un MITM que simula ser bank.example.com porque solo el bank.example.com real tendrá la clave privada.

Una vez que se establece esto, se establecen un par de claves simétricas. Una para el tráfico de cliente a servidor y otra para el tráfico de servidor a cliente.

Un MITM no puede descifrar el tráfico del servidor al cliente porque no tiene conocimiento de la clave privada acordada.

Una descripción muy simplista es:

  • El cliente genera un ClientHello.random y lo envía al servidor durante el reconocimiento inicial.
  • El servidor genera un ServerHello.random y lo envía al cliente durante el saludo inicial.
  • El cliente genera un "secreto pre-maestro" de 48 bytes y lo envía al servidor encriptado por la clave pública del servidor.
  • Un secreto maestro se calcula utilizando la fórmula master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)
  • PRF es una mezcla de MD5 y SHA-1.
  • Un bloque de clave se calcula utilizando key_block = PRF(SecurityParameters.master_secret, "key expansion", SecurityParameters.server_random + SecurityParameters.client_random);
  • El bloque de teclas se divide para proporcionar claves asimétricas separadas para el tráfico en cada dirección (junto con algunos IV y MAC que puede ignorar a los efectos de responder a su pregunta).
respondido por el SilverlightFox 03.08.2016 - 10:43
fuente

Lea otras preguntas en las etiquetas