Sui siti web che registrano grandi quantità di traffico (ad es. siti di consumatori, come banche) gli amministratori hanno deciso di utilizzare implementazioni HTTP e HTTPS miste in testo normale. In genere, HTTP viene utilizzato per le informazioni pubbliche e il passaggio a HTTPS si verifica quando si accede a risorse private come una schermata di accesso.
Questa pratica proveniva in gran parte dai tempi in cui la crittografia / decrittografia SSL (ora TLS) era più costosa (anni '90 e primi anni 2000) dal punto di vista della CPU e poteva rallentare gravemente i tempi di caricamento della pagina.
Ora, con CPU più veloci più abili nell'usare algoritmi di hash come SHA256 e crittografie come AES, questo problema è meno ovvio. Tuttavia, se si esegue un server Web su larga scala che riceve migliaia di accessi al minuto, l'amministratore noterà sicuramente il traffico TLS rispetto al traffico non TLS in termini di CPU utilizzata. Il sito in testo in chiaro richiede meno costi di manutenzione della CPU e IT e, a sua volta, comporta un risparmio per l'organizzazione in termini di spese di hosting.
Inoltre, come sottolineato in un commento di @mgjk, anche i costi della gestione dei certificati tra reparti IT delle banche (business contro personale, trading vs altro commercio, livelli di attenuazione WAF e DDoS che devono essere in grado di eseguire la decrittografia SSL, ecc.) Sono significativi e ingombrante in una grande organizzazione e può portare a una riluttanza da parte del management a implementare un sito solo TLS.
Così molte banche continuano a sfruttare i siti Web misti HTTP e HTTPS. Nuove best practice sono state sviluppate per controllare i problemi e attaccare i vettori presenti in questo setup, in particolare gli attacchi MiTM in stile "SSLStrip". Le misure di controllo includono l'uso di intestazioni HSTS e stanno facendo progressi nelle banche, ma devono ancora realizzare un'implementazione commerciale su larga scala da queste entità ampie, generalmente a rischio e avverse al cambiamento.
Per quanto riguarda la situazione specifica che descrivi con un Pineapple WiFi come un Evil AP, questo sarebbe possibile se metti in scena un attacco "SSLStrip" o un altro attacco man-in-the-middle.
Tuttavia, molte banche adottano misure per proteggersi dagli attacchi di hijack di sessione, in particolare scadendo rapidamente la sessione. Se il dispositivo avesse visitato il sito in precedenza e avesse inviato intestazioni HSTS, si sarebbe sicuramente verificato un errore (forse sufficiente a spaventare l'utente medio). Quindi, lo scenario di attacco che descrivi è un po 'semplicistico e richiederebbe un po' più di sofisticazione prima di essere attuabile contro le moderne implementazioni di siti Web bancari.
Tuttavia, sì, quando le banche non impongono l'uso di TLS con HSTS e pinning del certificato, viene aperto un grande vettore di attacco simile a quello che descrivi - e questa pratica dovrebbe essere eliminata gradualmente!