Captive portal trouble

  • 1
  • Problem
  • Updated 5 years ago
  • (Edited)
I've been have a ton of trouble with captive portal (CP below) hotspots at local coffee shops.  Literally the only way to connect is to uninstall CE first.

I contacted support and was given this advice:
1. Right click the Covenant Eyes icon, click “preferences” and uncheck the box for automatic sign in. 
2. Sign out of your computer profile, then sign back in. 
3. Open your Internet browser immediately after booting up and go to ford.com. Do not attempt to sign in to Covenant Eyes.
4. When your browser opens you should be directed to a hotspot sign in page. Once you are signed into the hotspot or have agreed to terms and conditions, Covenant Eyes should be able to sign in normally.
I asked support a few questions (just to understand how CE works / what's possibly breaking).  This is what I think I'm gleaning:
  • When logged out of CE, CE will block "all" websites.
  • Clearly this is not really all websites since otherwise it'd be impossible to log into any CP (and the above instructions would never work)
  • There must be some heuristic for determining which pages are likely to be CP pages (i.e. let's not block them)
  • The first logical place to start with that heuristic (to me) would be to allow anything in the local IP space (i.e. if I got 192.168.1.100/24 over DHCP, allow sites from any 192.168.1.0/24.  Or even any rfc1918 address.)  This would capture a lot of cases where the CP is served from the router.
  • Clearly rfc1918 addresses aren't sufficient since some CP pages are centrally deployed (probably (?) a lot-- McDonalds, Boingo, xfinitywifi, etc).
  • Its probably hard to get that heuristic right, resulting in a long tail of captive portals which fail.
I'm pretty sure the last point might be where I'm having trouble.

Here's a rundown of the exact login process, without CE installed:

I'm at a coffee shop connected via a WebBeams hotspot. DHCP assigned my laptop both a IPv4 and IPv6 address:
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	ether b8:e8:34:56:78:9A
	inet6 fe80::bae8:56ff:fe39:54f2%en0 prefixlen 64 scopeid 0x4
	inet 10.5.50.158 netmask 0xffffff00 broadcast 10.5.50.255
	nd6 options=1<PERFORMNUD>
	media: autoselect
	status: active
CE is currently uninstalled.

It looks like there's a Mikrotik router/CP redirecting people to http://10.5.50.1 (on the same subnet).  Here's what that responds with:
➜  ~  curl -i ford.com
HTTP/1.1 302 Hotspot login required Cache-Control: no-cache Content-Length: 135 Content-Type: text/html Date: Tue, 30 Jun 2015 22:58:04 GMT Expires: 0 Location: http://10.5.50.1/login?dst=http%3A%2F%2Fford.com%2F <html> <head><title>Error 302: Hotspot login required</title></head> <body> <h1>Error 302: Hotspot login required</h1> </body> </html>

Then http://10.5.50.1/login redirects to https://wifi.webbeams.com with some params (mac address, etc):
➜  ~  curl -i http://10.5.50.1/login\?dst\=http%3A%2F%2Fford.com%2F
HTTP/1.1 200 OK
Cache-Control: no-cache
Connection: Keep-Alive
Content-Length: 921
Content-Type: text/html
Date: Tue, 30 Jun 2015 22:58:39 GMT
Expires: 0

<html><head>
<title>Welcome to WEBbeams WiFi Login</title>
</head>
<body>
<form name="redirect" action="https://wifi.webbeams.com/customer/hotspotlogin.php" method="GET">

<input type="hidden" name="res" value="notyet" />
<input type="hidden" name="mac" value="B8:E8:34:56:78:9a" />
<input type="hidden" name="user" value="" />
<input type="hidden" name="uamport" value="mikrotik" />
<input type="hidden" name="userurl" value="http://ford.com/" />
<input type="hidden" name="nasid" value="WEBbeams_56" />
<input type="hidden" name="uamip" value="10.5.50.1:80" />
<input type="hidden" name="error" value="" />
<input type="hidden" name="chap-id" value="\242" />
<input type="hidden" name="chap-challenge" value="\251\034\006\315\311\330\247\253\250\263\172\257\261\270\166\027" />

</form>

<script language="JavaScript">

<!--

 document.redirect.submit();

 //-->

</script>
</body>
</html>%
https://wifi.webbeams.com is where the actual user-visible authentication happens.  

My hunch is this site was blocked so I'd never get a login page. (and gee, how could you heuristically decide it shouldn't be blocked?  Aside from having a large list of sites that shouldn't get blocked, which'll never be fully accurate.)

Ideas / helpful (?) questions:
  • Is there a reason CE must re-login when the connection changes? 
    Edit: (Support also mentioned: "The problems you are describing occur when Covenant Eyes tries to authenticate before you’ve clicked through the network’s user agreement page. If Covenant Eyes tries to login too early, you’ll get stuck in the loop.")

    Why not simply cache logins and continue filtering things after a connection change?  In this way you wouldn't have to block by default (catching some CP logins in the process) but could still provide safety from dangerous sites (because filtering is enabled).

    I haven't fully thought through that, but it seems worth asking.  It'd allow for removing the heuristics which might be hard to get right. (maybe I'm way off with my assessment of what's probably going on under the hood...)

    If its some technical reason on your backend (i.e. associating logins with specific networks), it seems likely that could be re-engineered.  Even if its painful to do.)
  • I'll keep thinking and post updates to this thread...
Thanks,
Pete
Photo of petedoyle

petedoyle

  • 4 Posts
  • 0 Reply Likes
  • like I'd really like to help fix this

Posted 5 years ago

  • 1
Photo of petedoyle

petedoyle

  • 4 Posts
  • 0 Reply Likes
Sorry, I'm not sure the exact version I was using, probably 2.8.0.  In case you need to know, it was one of these:

➜  Downloads  shasum -a 256 CovenantEyesMac*
61e17e4b10bf4409bdbeb7fd951efb4e9cb0adde45b56f986e5545497e02dd40  CovenantEyesMac (1).dmg
fd134eff792c0c25182b22d409d4e40475e0b9974948d20c3e78d24525989932  CovenantEyesMac (2).dmg
61e17e4b10bf4409bdbeb7fd951efb4e9cb0adde45b56f986e5545497e02dd40  CovenantEyesMac.dmg

Just noticed 2.8.2 was released which has some hotspot fixes.
Photo of Patrick Smith

Patrick Smith, Alum

  • 147 Posts
  • 21 Reply Likes
Pete, 2.8.2 was the culmination of a LONG effort to overcome the issue you articulate here. I think you'll find it useful to that end. 
Photo of petedoyle

petedoyle

  • 4 Posts
  • 0 Reply Likes
Awesome, thank you Patrick.  I have it installed now and we'll see how things work. :)  

Just curious, was I anywhere close with that?  My brain kinda got stuck on it this afternoon and would be fun to know.
Photo of Patrick Smith

Patrick Smith, Alum

  • 147 Posts
  • 21 Reply Likes
Mornin' Pete,
Mac isn't among the projects I manage, so I'll ping someone here with better Mac chops. If their approach until 2.8.2 was similar to our old Windows clients (& I think it was), you're in the ballpark. I'll see if I can get someone here to respond yet today. Thanks.
Photo of Andrew

Andrew, macOS Software Engineer

  • 3 Posts
  • 0 Reply Likes
Hi Pete,

Patrick said you were curious about how we handle captive portals.

Short answer: You're pretty close.

Long answer:

You're correct that the heuristic we use is difficult to get right.  Over time, we make tweaks to improve compatibility with more captive portals.  Version 2.8.2, for example, is actually a pretty small change over 2.8.1, but it was the result of months of research and testing.  By making a small adjustment to the workload on some of the threads, we were able to introduce support for an entire class of captive portals.

Part of the problem is that captive portals exhibit a fairly wide range of behaviors, and it is difficult to achieve a good taxonomy for categorizing them.  When we get reports that "Restaurant X didn't work", it's often tricky to figure out exactly what behavior the portal is using.  We often will visit a local establishment with similar behavior in order to test new solutions (the lovely people at our local Bob Evans now recognize our QA department on sight).

In the past, people like yourself have been very helpful in adding support for additional captive portals.  In particular, the tests you have already done are quite helpful towards identifying how the portal behaves, which allows us to develop a solution without physically visiting the establishment.

I hope version 2.8.2 of the Mac Client helps you as much as it has helped many people in similar situations.

Cheers!
(Edited)
Photo of petedoyle

petedoyle

  • 4 Posts
  • 0 Reply Likes
Hi Andrew,
Just wanted to say thanks for the reply.  Thankful for the work y'all have done to make captive portals work well.  Really wish captive portals would die in a fire (even without regard to CE :)).

Best,
Pete