Si alguien tiene acceso a la clave privada del certificado, puede usarlo para los ataques del hombre en el medio. Dicho ataque se puede usar para redirigir al usuario a otra máquina si la búsqueda de DNS para el host dada en la redirección da como resultado la dirección IP de la otra máquina. Este puede ser un nombre de host diferente en el mismo dominio que en la solicitud original y, por lo tanto, puede estar cubierto por el mismo certificado comodín. Pero también puede ser un dominio diferente, por ejemplo, un dominio controlado por el atacante, donde también tiene un certificado para realizar MITM donde controla el servidor completo (no se necesita MITM).
En realidad, no veo el problema con un certificado comodín en este caso. Es suficiente que el atacante tenga acceso a cualquier certificado aceptado (comodín o no) y su clave privada para rastrear y modificar el tráfico. El ataque tampoco se limita a redirigir a otro sistema.
¿Puede el atacante redirigir a: bad.s3.amazon.com/important.data (pero en realidad datos dañados) con el truco de DNS / red rogue?
Una forma es engañar al usuario para que use la URL incorrecta en primer lugar (ataques sociales). Luego, un atacante cerca del usuario (es decir, la red local, ISP, ...) podría intentar realizar una falsificación de DNS, una falsificación de ARP o similar para permitir que el usuario acceda a la URL deseada pero en el host incorrecto. Solo, en este caso, el encabezado de host HTTP de la solicitud mostrará el dominio deseado y el enrutamiento basado en HTTP dentro de AWS causará que la solicitud termine en el grupo correcto o sea rechazada ya que no se puede acceder al grupo correcto utilizando el Dirección IP.
