El proxy inverso comparte un certificado para varios servidores utilizando el Nombre alternativo del sujeto

Question

El proxy inverso comparte un certificado para varios servidores utilizando el Nombre alternativo del sujeto

#1 de Nicholas Andre (2 votos)

0

El siguiente es un escenario para un ataque donde un sitio web puede suplantar a otro. Me dicen (incluso por esta respuesta ) que es imposible, pero me gustaría entender exactamente qué lo impide.

Alice usa sitios web que obtienen un recurso JS de confianza del servidor de Bob, usando HTTPS para evitar ataques MITM. El recurso de Bob es popular, y comienza a usar un CDN para distribuirlo. Ahora, el navegador de Alice está haciendo una conexión HTTPS a un servidor que pertenece a la CDN.

El CDN utiliza nombres alternativos del sujeto para compartir un certificado entre varios clientes cuyos sitios comparten una dirección IP en el CDN. Eva tiene un sitio que está en el mismo certificado que el de Bob (1). Eve conoce la cafetería favorita de Alice y puede interceptar las señales en el wifi allí.

Como Eve no tiene la clave privada del certificado, no puede leer el tráfico HTTPS de Alice. En su lugar, espera una solicitud del recurso en el sitio de Bob (2) y la reemplaza por una solicitud a su propio sitio, a través de la misma dirección IP de CDN que apunta a ambos sitios. El servidor CDN descifra la solicitud, obtiene un recurso malicioso del sitio de Eve y lo cifra utilizando el certificado compartido. El navegador de Alice ve una respuesta válida de la IP de CDN a la que envió la solicitud y, aparentemente, no tiene razón para no aceptarla. Tenga en cuenta que Eve no necesita modificar la respuesta mediante MITMing: el servidor CDN envía el contenido malicioso desde un servidor detrás de él.

O es capaz de hackear en uno. Uno de ellos está destinado a ser inseguro.
¿La URL está cifrada en una solicitud HTTPS? Si es así, suponga que Eve reemplaza todas las solicitudes que van a la dirección IP relevante y las apuestas sobre detección son poco probables.

No estoy especialmente familiarizado con SSL, así que estoy dispuesto a creer que algo en eso no se cumple, pero no estoy seguro de qué, exactamente.

tls certificates multi-tenancy

pregunta Thomas K 06.08.2014 - 00:35

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls certificates multi-tenancy

¿Por qué las personas confían en la administración de dependencias de PlayFramework2? Tor, PGP y nodos de entrada de Tor

score 2 · Accepted Answer

En este caso, cuando se sirven varios sitios web desde el mismo servidor en el mismo puerto, ese servidor los diferencia al comparar el encabezado Host: en la solicitud HTTP.

Una vez que se ha producido la negociación TLS, no es posible leer nada dentro de esa solicitud. Además, no puede intercambiar entre dos conexiones SSL simultáneas porque un simple intercambio de claves Diffie-Hellman produce una clave diferente para cada negociación.

Este es el quid del problema: el encabezado Host: está dentro de la transmisión cifrada SSL . Por lo tanto, no es posible manipular ese encabezado y no es posible redirigir esa solicitud incluso a un host virtual diferente en la misma máquina.

Sin la clave privada, no hay mucho que puedas hacer para romper SSL.

EDITAR: Sí. Lo que está sugiriendo requeriría algún tipo de manipulación de la solicitud. Básicamente, SSL consiste en un paquete TCP con un contenido completamente ilegible, y lo que quiere hacer en este caso es alterar el contenido ilegible para hacer ilícita una respuesta diferente del servidor. Eso no es posible sin romper el SSL. La única modificación que podría hacer es en el encabezado de TCP para cambiar la IP o el puerto de destino, pero en su caso eso no logrará nada ya que aún tiene la intención de apuntar al mismo servicio en ese mismo servidor.

Aclaración sobre la negociación SSL

La negociación SSL utiliza una clave diferente cada vez. Básicamente, el cliente genera un número aleatorio y lo cifra utilizando la clave pública. Esto solo puede ser descifrado con la clave privada. En este punto, solo el Cliente (que generó la clave) y el servidor (que pudo descifrarlo con su propia clave privada) conocen este número aleatorio.

No hay forma de que un atacante obtenga ese número. Teóricamente, podría repetir el mismo secreto cifrado en el servidor para abrir una conexión con la misma clave, sin embargo, aún no sabría el secreto ni podría alterar ningún paquete cifrado con él.

Sin embargo, esto le permitiría usar un ataque de repetición (y repetir una solicitud como "eliminar el siguiente elemento" nuevamente), así que supongo que hay otras funciones dentro de SSL para mitigar este riesgo.