Here's the 1999 part of this equation. For encrypted networks, your device will only connect to a network for which it's stored a password. If another network appears with the same name and a different password (or even login method) or without a password at all, your device won't connect.
However, there's no authentication or any kind for password-free networks used for public space Wi-Fi in cafés, conference centers, airports, and hotels. This is true even when there's a portal at which you're redirected to enter login information, a usage code, or payment details. The network is still open.
This is an obvious problem, and has been for some time. There's no way to prevent a device that has a stored network connection for an open network from connecting to any network with the same name, regardless of which base stations are attached.
Because mobile carriers have built up big Wi-Fi networks of their own and partnered with other networks for use to offload data (and sometimes voice) traffic from cellular networks, a malicious party can pick from among many networks names while also being assured in any dense portion of a city of having a large attack surface — thousands or tens of thousands of people every day.
The particular attack in question
The attack detailed by Skycure is fascinating because it apparently arose from simply plugging in a router that delivered a malformed SSL certificate. This isn't strange. A lot of network gear is cheaply and hastily made, and uses generic and outdated firmware, sometimes lightly or unmodified open-source software builds.
The researchers found that their iOS devices crashed when connected and sorted out the flaw. By using a similarly malformed certificated on an "evil twin" access sharing the name of any of a number of popular carrier-associated networks, an attacker could cause any iOS device that connects to crash and restart.
But the reason this attack is interesting is twofold. First, you don't have to have previously connected to the Wi-Fi network's name in the case of networks carriers bake into a profile. Second, the crash happens at the initial connection, so after reboot (as shown in a video on the firm's site) the Wi-Fi network re-association happens and the crash occurs before you can disable Wi-Fi on the phone.
Your only recourse is perhaps to wrap the phone securely in aluminum foil or leave the vicinity of the attacking network. To a regular user, it would appear as if their phone was simply broken and rebooting over and over again. Even restoring the phone in the vicinity wouldn't work, because once it's activated on the carrier network, it would install or retrieve the connection setting profile.
Sign up for CIO Asia eNewsletters.