Se qualcuno ha accesso alla chiave privata del certificato, può usarlo per gli attacchi dell'uomo nel mezzo. Tale attacco può essere utilizzato per reindirizzare l'utente su un'altra macchina se la ricerca DNS per l'host indicato nel reindirizzamento risulta nell'indirizzo IP dell'altro computer. Questo può essere un diverso hostname nello stesso dominio della richiesta originale e quindi può essere coperto dallo stesso certificato jolly. Ma può anche essere un dominio diverso, ad esempio un dominio controllato dall'attaccante dove ha anche un certificato per eseguire MITM dove controlla il server completo (non è necessario il MITM).
In realtà, in questo caso non vedo il problema con un certificato con caratteri jolly. È sufficiente che l'autore dell'attacco abbia accesso a qualsiasi certificato accettato (jolly o non) e alla sua chiave privata per sniffare e modificare il traffico. L'attacco non è limitato al reindirizzamento a un altro sistema.
Can attacker redirect to: bad.s3.amazon.com/important.data (but actually corrupted data) with DNS/network rogue trick?
Un modo è ingannare l'utente a utilizzare l'URL sbagliato in primo luogo (attacchi sociali). Quindi un utente malintenzionato vicino all'utente (ad es. Rete locale, ISP, ...) potrebbe provare a eseguire spoofing DNS, spoofing ARP o simile per consentire all'utente di accedere all'URL desiderato ma sull'host sbagliato. Solo in questo caso l'intestazione host HTTP della richiesta mostrerà il dominio desiderato e l'instradamento basato su HTTP all'interno di AWS farà sì che la richiesta finisca nel bucket buono o venga respinta poiché il bucket buono non è accessibile utilizzando lo specifico Indirizzo IP.
