En los sitios web que experimentan grandes cantidades de tráfico (por ejemplo, sitios de consumidores, como bancos), los administradores han decidido utilizar implementaciones mixtas de HTTP y HTTPS de texto plano. Por lo general, HTTP se usa para información pública, y el cambio a HTTPS ocurre cuando se accede a recursos privados como una pantalla de inicio de sesión.
Esta práctica provino en gran parte de los días en que el cifrado / descifrado SSL (ahora TLS) era más costoso (desde la década de 1990 y principios de la década de 2000) desde la perspectiva de la CPU, y podía ralentizar considerablemente los tiempos de carga de la página.
Ahora, con CPU más rápidas, más adeptos al uso de algoritmos hash como SHA256 y cifrados como AES, este problema es menos obvio. Sin embargo, si está ejecutando un servidor web a gran escala que recibe miles de visitas por minuto, el administrador seguramente notará tráfico TLS frente a tráfico no TLS en términos de CPU utilizada. El sitio de texto simple requerirá menos gastos de mantenimiento de CPU y de TI y, a su vez, supondrá un ahorro para la organización en términos de gastos de alojamiento.
Además, como se señaló en un comentario de @mgjk, los costos de la gestión de certificados entre los departamentos de TI del banco (negocios frente a personal, comercio frente a otro comercio, WAF y DDoS que necesitan poder realizar descifrado SSL, etc.) también son significativos y engorroso en una organización grande, y puede llevar a una renuencia por parte de la administración a implementar un sitio solo para TLS.
Por lo tanto, muchos bancos continúan aprovechando los sitios web mixtos HTTP y HTTPS. Se están desarrollando nuevas mejores prácticas para controlar los problemas y los vectores de ataque presentes en esta configuración, especialmente los ataques MiTM del estilo "SSLStrip". Las medidas de control incluyen el uso de encabezados HSTS, y están avanzando hacia los bancos, pero aún tienen que lograr una implementación comercial a gran escala de estas grandes entidades, generalmente adversas al riesgo y al cambio.
En lo que respecta a la situación específica que describe con WiFi Pineapple como Evil AP, esto sería posible si organiza un ataque "SSLStrip" u otro ataque de hombre en el medio.
Sin embargo, muchos bancos toman medidas para protegerse contra los ataques de secuestro de sesión, especialmente la expiración de la sesión rápidamente. Si el dispositivo visitó el sitio antes y envió encabezados HSTS, seguramente se produciría un error (tal vez suficiente para asustar al usuario promedio). Por lo tanto, el escenario de ataque que describe es un poco simplista y requeriría un poco más de sofisticación antes de ser viable frente a las implementaciones modernas de sitios web bancarios.
Sin embargo, sí, cuando los bancos no fuerzan el uso de TLS con HSTS y la fijación de certificados, se abre un gran vector de ataque similar a lo que usted describe, ¡y esta práctica debería eliminarse gradualmente!