Comunicación SSL y Proxy

Depende. En general, no. Si el atacante lanza un ataque de hombre en el medio después de que la comunicación HTTPS ya haya comenzado, no puede hacer nada.

Si lanza el ataque de antemano, puede hacer varias cosas. Para mayor comodidad, supongamos que el servidor en cuestión es GMail.

• Finge ser mail.google.com: este es un ataque bastante transparente. El atacante no puede obtener una firma de confianza para su certificado SSL y, por lo tanto, no puede pretender ser Google sin lanzar un error similar a este . Si el cliente hace clic a través de esto; bueno, eso es culpa del cliente.
• Lo atrapa cuando prueba HTTP: Algunas personas ingresan a http://www.gmail.com , lo que significa que su navegador primero intentará HTTP. La mayoría de los sitios que solo utilizan HTTPS emiten un redireccionamiento de 301 Moved Permanently , pero un atacante puede evitar que esto suceda y pretender ser HTTP-GMail (y pretender ser usted en comunicaciones con el verdadero HTTPS GMail: las personas no tienen / necesitan SSL por lo que esta suplantación se realiza fácilmente una vez que su contraseña está con el atacante). Tenga en cuenta que el ícono del navegador ya no tendrá un candado verde en tal caso. Sin embargo, no todos los navegadores móviles distinguen visualmente entre HTTP y HTTPS. En general, es mejor usar marcadores y guardar el historial en el lado del cliente, y usar HSTS en el lado del servidor para protegerse contra esto .

Solía haber muchas otras vulnerabilidades de implementación de HTTPS (prácticamente todas están arregladas). Probablemente todavía hay algunos. Pero la mayoría confía en que el usuario no se dé cuenta (o haga clic ciegamente) en una advertencia.