Comunicazione e proxy SSL

Dipende. In generale, no. Se l'attaccante lancia un attacco man-in-the-middle dopo la comunicazione HTTPS è già iniziata, non può fare nulla.

Se lancia l'attacco in anticipo, può fare varie cose. Per comodità, supponiamo che il server in questione sia GMail.

• Fai finta di essere mail.google.com: questo è un attacco abbastanza trasparente. L'autore dell'attacco non può ottenere una firma attendibile per il suo certificato SSL e quindi non può fingere di essere Google senza generare un errore simile a questo . Se il cliente fa clic su questo; bene, questa è colpa del cliente.
• Ti catturano quando provi HTTP: alcune persone inseriscono http://www.gmail.com , il che significa che il loro browser prima prova HTTP. La maggior parte dei siti HTTPS emette un reindirizzamento 301 Moved Permanently , ma un utente malintenzionato può impedire che ciò accada e fare finta di essere HTTP-GMail (e fingere di essere tu nelle comunicazioni con il GMail HTTPS reale - gli individui non hanno / hanno bisogno di SSL certifica che questa rappresentazione può essere eseguita facilmente una volta che la password è con l'attaccante). Nota che l'icona del browser non avrà più un lucchetto verde in questo caso. Tuttavia, non tutti i browser mobili distinguono visivamente tra HTTP e HTTPS. In genere è preferibile utilizzare i segnalibri e salvare la cronologia sul lato client e utilizzare HSTS sul lato server per proteggersi da questo .

Prima esistevano molte altre vulnerabilità di implementazione HTTPS (sono praticamente tutte riparate ora). Probabilmente ce ne sono ancora alcuni. Ma la maggior parte si basa sull'avviso che l'utente non si accorge (o cieca clic).