5

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:

  1. Accessing a website that offers protected REST services, SPA app, or similar?
  2. Requesting from an app on iOS, Android that leverages the built in HTTP framework for that platform
  3. Requesting from an app that doesn't leverage the platform HTTP framework, but instead, uses OpenSSL, BouncyCastle, or Monotouch/MonoDroid
  4. 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.

4

Not just OSX but most platforms now will request a known URL and see whether the content is replaced or tampered with to detect hotspots.

Windows 7+ :

NCSI performs a DNS lookup on www.msftncsi.com, then requests http://www.msftncsi.com/ncsi.txt. This file is a plain-text file and contains only the text Microsoft NCSI.

NCSI sends a DNS lookup request for dns.msftncsi.com. This DNS address should resolve to 131.107.255.255. If the address does not match, then it is assumed that the internet connection is not functioning correctly.

Source: http://blog.superuser.com/2011/05/16/windows-7-network-awareness/

Android 4.2.2+:

http://clients3.google.com/generate_204

Source: #1 & #2

Most of these URLs can be changed if privacy is a concern.

The solution for your application would be to make a HTTP GET request and see if that gets tampered with.

On most of the hotspots I use, I see either a failing SSL/TLS session due to the site being signed by the hotspot provider rather than the one I was attempting to visit (they don't have the certs for the site I'm attempting to visit) which your TLS/SSL hostname checking will flag up... or they just block the connection until they see a HTTP GET to a site they can MITM... which would look like a timeout.

An advantage to having a http://yourapp.com/status style URL rather than re-using either Microsoft's or Google's is you can attempt to provide more helpful information on the health of your application if your status URL reports that the service is healthy but the user's network isn't letting them connect to your TLS/SSL endpoint over if the http://yourapp.com/status page is down then perhaps your application is down too.

-1

It's certain : use Tor and/or I2P, they're exact tools you need : tamper-resistant transport layers.

UPDATE: The problem of "pre-defined URL's" is that they're... pre-defined. Easy to make a trap on a path of a network packet from app to server. The root of the problem is that the traditional routing protocols are very "straightforward", too easy to be tampered with. The very meaning of "Darknet" term is that it's untemperable in the meaning of routing tampering.

  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review – Mark Buffalo Mar 6 '16 at 14:35
  • @MarkBuffalo take a look at my update, feel free to request more info – Alexey Vesnin Mar 6 '16 at 15:36
  • Networks employing captive portals generally block all traffic until you use the portal successfully. There isn't much difference for the application between blocked Tor/I2P and blocked TLS (or tampered with TLS that results in a certificate failure). – CodesInChaos Mar 6 '16 at 18:03
  • @CodesInChaos not agree : russian Beeline free WiFi, you're loggin in on a portal in a web browser and using pre-seeded Tor instance for further work. And it defeats the attacker(goverment agency). Checked it myself – Alexey Vesnin Mar 6 '16 at 20:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.