Wi-Fi login problems with iOS 6 devices

Article

What went wrong with iOS 6 Wi-Fi | ZDNet – loop

My Comments

You may have upgraded your iPhone or iPad to iOS 6. But after your Apple device shuts down and restarts as part of applying the update, you find that you are not on your home or business Wi-Fi network even though you downloaded that update through the same network.

The problem is not necessarily a flawed network configuration, but part of the iOS Wi-Fi automatic troubleshooting routine. Here, the software attempts to load a “Success” stub page from the Apple servers. This logic is intended to cause the iOS device to load a login or “assent” page that is part of a public-access or guest-access Wi-Fi network’s user experience. This stub was deleted by a former Apple employee before he left without realising it was part of iOS 6 troubleshooting logic.

The computer press have realised that this logic is flawed because this can place the servers at risk of denial-of-service attacks thus crippling iOS 6 devices. Similarly, someone could use a “man-in-the-middle” or “evil-twin” attack to point the device to a site that is of a malevolent nature. If a “show particular Webpage” logic is to be implemented in a network troubleshooting logic, it could work with a list of commonly-available Websites like Web portals or Web resource pages which the device chooses from at random.

It could be a chance for software developers to create network-test logic that makes less reliance on loading a particular Web site as proof of function. This could be through use of simplified randomised test routines that work with locations that are randomly chosen from a list of commonly-known highly-available Internet locations. This can be augmented by government standards bodies and similar organisations like NIST or BSI adding basic-HTML “Internet Success” pages to their Websites and making the URLs available to the IT industry.

Sometimes an NTP or similar time-fetch routine that obtains the time from one of many atomic-clock time servers to synchronise a device’s internal clock can work as a simplified Internet-functionality-test routine. If the time-server supports HTTP access where the UTC time is obtained via an HTML or text string, this could be achieved using HTTP so as to test Web-access functionality.

By not relying on one particular server as a proof-of-functionality test for Internet access and integrating a “login-page load” failover routine for public-access networks, we can achieve a safe and sure network setup experience.