I always suspicious of these flows for specifically this reason. The flows are secure as long as you know you are talking to the correct identity provider, but I think most laymen would not understand that concept.
A few years ago I read a statistics that most (90%+) computer users just do things based on rote memorization of sequences of actions, not understanding what happens in the background. I wonder how it is nowadays.
Maybe AI that can "smell" if you're on a scammy site (e.g. prompts to enter your Google/FB/Amazon password) would be useful, but then again the implementation might end up being like MS's "let us record your screen, for AI!" horseshit..
I guess it's overcomplicating things, though. Most people will just not notice that whatever domain they use is not legit.
But on the flip-side, if there's an expert on the flight, they'd notice it's a spoof site and chances are higher they'll report it to the crew. I can imagine the trick is to show a page that says "For free WiFi, follow our Instagram account, click here for our account", and the click will fail because there's no connection (if we're on the plane), but the click can trigger some Javascript to say "If you couldn't follow our Instagram, login using your Google/Amazon account: Username: ____ Password: ____". Or a more sophisticated trick would be to show a DIV that looks like Instagram and the "follow" button, which will then show the fake login...
The privacy-wary IT expert will look at the "Follow our Instagram" and think "Fuck off, I'm not doing that!" and might miss the spoofed login prompt...
If you use a random domain sure it works, but it's also fishy. I guess most people won't notice...
I don't think HSTS will help if he is running his own WWW site on his laptop with a proper CA signed cert. If I understand correctly his laptop was presenting a proper WWW login page presumably over HTTPS after victims connected to his WIFI. What he was probably faking was the redirect to the Identity Provider (IDP) by staying on his own properly credentialed HTTPS site which would pass all HSTS checks. He may have also been faking DNS responses to keep users where he wants them.
This experience would just redirect the user to a site they've never been to before, say: wa-man-likes-your-data.com. This could have a legitimate signed cert from anywhere and look legitimate to the device with a lock icon. Put the airline's logo and a form for PII, wait a couple of hours and you've collected a plane load of data.
I used to think about doing something similar but as an education campaign. Similar to Phishing Simulators at large corporates, I had the idea to display a captive page that explained what the user did and how they can learn to avoid it in future.
Apple & Google should really make it clearer on phones that users are joining untrusted networks, especially any network not implementing Wi-Fi Certified Passpoint (Hotspot 2.0).
so that the captive portal can intercept and write their own login.
HSTS will only make a HTTPS connection. Without the valid certificate, they should get a warning.
The only way this "works" is if a captive portal pops up a browser to a site that looks the same like amaz0n.com. Password manager wouldn't popup, but many people don't use them.
Faking DNS also won't help with the TLS warning, they won't have the certificate.
Basically, this shouldn't be possible with HSTS.
No need. People probably don't look closely at the domain name.
And that's just one of the many possible scenarios. When you control someone else's Internet, there is a lot of things you can do. Google's certificate transparency is going to help a lot here, but only as much as what happens in a browser.
Just do a captive portal redirect to "google.johnsmith.example.com" with a properly signed certificate, add google logo and login fields, and after a user enters his credentials, just redirect them to actual google.com.
Most people don't look at domains in the url. You can actually probably register a domain like "freegooglewifi.com" or something.