Chris F Carroll

But no, the http isn't irrelevant. If the user is on SSL all the way from search engine to login page, that's harder to break. If there's an http homepage though, I can serve the user a modified version of that page and have them login to my server instead of the bank's

Does this mean that the reference to http in my question is a red herring, and that my question is simply, "What's to stop me using an EvilAP to catch bank credentials?"

Yes, I think the wifipineapple is an Evil AP in a box, so I am the access point

(1) Public Wifi enables MITM straightforwardly (2) As MITM, when you browse to your bank I show you a modified homepage (3) You click on the login link (4) The link is a link to my proxy server which asks for your login details (4 1/2) My proxy server is in the cloud and has a real SSL certificate of its own to show the user (5) My proxy server copies the request to the real login page at the bank but recording the traffic (6) etc. I proxy and record the whole conversation

My point is, if I spoof/alter the homepage, then when they click the login link I send them to my server (which will then present itself as the user to the bank) The user I've intercepted never sees the bank's link to the valid https. Just like a phishing attack. So I can't see that I need anything clever at ARP/DNS/SSL level and HSTS is made irrelevant

Okay I added the specific scenario to my question which seems to me mindbogglingly cheap and simple.

Perhaps my question wasn't sharply/explicitly enough stated, sorry. I'll add the scenario that's bugging me