I need to fix an issue where the initial (or perhaps only) HTTPS call to a website is blocked by a captive portal, not managed by me. The resolution has been to ask the user to navigate to a "http" only site in order to tell the software stack to login via portal.
From an app perspective I see that the expected site is:
- SSL is unavailable (any of the ICMP response codes)
- SSL has an untrusted cert from the portal
- SSL has an untrusted cert and unexpected content (portal login)
Each one of those behaviors results in a different outcome by various software stacks, OS's, and home-brew software.
What is the most compatible way of dealing with captive portals when:
- Accessing a website that offers protected REST services, SPA app, or similar?
- Requesting from an app on iOS, Android that leverages the built in HTTP framework for that platform
- Requesting from an app that doesn't leverage the platform HTTP framework, but instead, uses OpenSSL, BouncyCastle, or Monotouch/MonoDroid
- Requesting from a Desktop PC (OSX or Windows)
w.r.t. #4, I know that OSX will attempt to contact http://captive.apple.com/hotspot-detect.html to determine if a
301/302 redirect is in place... or if the portal simply replaces the content outright via a MITM/Content Injection.