cancel
Showing results for 
Search instead for 
Did you mean: 

Captive portal and HTTPS problems

david_henderson
Contributor II
We are setting up the Cloudpath captive portal and ran into one issue. When a user with a personal device wants to get on our network, the steps are straight forward:
  • User joins our wide open guest network
  • They launch a web browser and hit the Cloudpath captive portal
  • They are led through the process of securely on-boarding their device
Two issues, the second one more serious
  1. If the first page a person hits on their web browser is HTTPS, the get a cert error. If they click continue, they are at the captive portal
  2. If the first page a person hits on their web browser is HTTPS and HSTS, they just get an error message, they never get the Cloudpath screen
I never heard of HSTS until today
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security

Every Google site uses HSTS and of course many people have their home page for their web browser set at https://www.google.com. Has anyone else encountered this? I do have a case open with Ruckus support. From what I read HSTS will become much more common over time
7 REPLIES 7

david_henderson
Contributor II
I wrapped up the case I had with Ruckus support and here is the bottom line:
  1. If the user visits an http site, they are immediately redirected to the Cloudpath portal. This works regardless of what browser they are using
  2. If the user visits an HTTPS site that does not use HSTS, they receive a warning. If they click Continue they are redirected to the Cloudpath site. This works regardless of browser
  3. If the user visits an HTTPS site that does use HSTS and they are using the Chrome browser they are dead ended. The only way to get redirected to the Cloudpath portal is to visit a different site. Many people have https://www.google.com or facebook set as their homepage. Both of these sites use HSTS so this might confuse some users. At least with Safari on an iPhone, they get a warning but can continue and they will get redirected. Google Chrome on a laptop they are dead ended just like Google Chrome on an iPhone. My guess is Google Chrome on an Android also dead ends the user
The only hope in the long run is a new standard being developed just for captive portals
http://community.arubanetworks.com/t5/Technology-Blog/RFC-7710-Captive-Portal-Identification-Using-D...
http://www.rfc-editor.org/info/rfc7710

This issue of not being redirected to a captive portal affects every wireless vendor including Ruckus. As more and more sites uses HSTS, getting a proper redirect becomes harder. I am hoping that Ruckus is sitting on the working group for this new standard and is pushing hard to get it ratified. In the long run, if something is not done, products like Cloudpath or Aruba's Clearpass will lose their value if it becomes really tough to get a proper redirect.

dtsblake_588878
Contributor II
Has Ruckus commented on this topic in some public "forum?"

david_henderson
Contributor II
Not that I know of

shaun_van_tonde
New Contributor III
I think I maybe experiencing this issue. If somebody can confirm. Ruckus cant seem to help me.
I have purchased an ssl certificate and installed it on my Zone Director. We use captive portal with AD authentication but some users get cert errors on their mobile devices. I notice the error when the mobile device uses Chrome as the default browser. On a desktop PC i don't get the error initially but if i dont authenticate with the portal and just type in www.google.com I also get a warning error message. Someone may be intercepting traffic etc etc.. So from what I can see some devices try to skip the portal and go straight to their homepage which is https://www.google.com for example.

My thought was to redirect users to an http page but now my ruckus device redirection isnt functioning as per redirect to url after authentication in hotspot settings.. I am not sure where to go from here.. With 200 mobile devices this is a pain..