Captive portal does not work with https!

Corsani
Here to help

Captive portal does not work with https!

I have a cisco meraki AP infrastructure. I defined an SSID with radius authentication and a walled garden. Everything was ok until the web-world migrate to https. That's the problem:

 

- the domani www.bing.com is not in the walled garden;
- http://www.bing.com correctly redirect the user to the login splash page to authenticate the user;
- https://www.bing.com does nothing and the browser got time out;

Asking to meraki they said that can't works because: "Meraki devices are not able to decrypt. This is why it's working fine with http (no encryption) but not with https (encryption)".

 

But...

 

- if I put the domain www.bing.com in the walled garden;

- https://www.bing.com works!

Why? I'm not an expert but seems to me that meraki can detect the url the user ask for, to check the walled garden. Isn't it? Why if the domain is not in walled garden, meraki won't redirect to the login splash page even if it's in https? Let me understand, please, why if a request is out of walled garden, meraki won't redirect to splash login page regardless of http or https.

6 REPLIES 6
Bruce
Kind of a big deal

Hi @Corsani, this is to do with the way the browser handles HTTPS sites. When you put something in the walled garden then Meraki allows access to it before the user has authenticated, so it just passes the traffic straight to the site. This is exactly the same for whether you're accessing an HTTP or HTTPS site. It's just as if the Meraki didn't exist - hence why it works.

 

In the scenario where you are trying to authenticate you need to think about what is happening (this is going to be a pretty high-level explanation, but should help you to understand it). In the case of an HTTPS request you're asking to fetch a page from bing.com using an encrypted connection - that's what starting the URL with HTTPS means. So your browser goes out to get the public certificate from bing.com to encrypt the connection. However, at this point the Meraki device intercepts it and can't do anything. It could pass back the bing.com public certificate, but then it doesn't have the private key so can't encrypt/decrypt the messages. Or it could pass back its own certificate and become a 'man-in-the-middle', but then the browser will generate all sorts of errors because the certificate name won't match the website name (i.e. bing.com). And this is where the problem lies, there is no easy way to do web-based authentication for HTTPS based sites. The user needs to first go to a HTTP (unencrypted) site to authenticate successfully, and then once that's happened all should be good.

RonW
Conversationalist

I have been telling my users to go to neverssl.com to log in. Do you have any HTTP sites that you tell them to hit to see the authentication page? 

 

I know this isn't a Meraki thing but an Internet thing about how https is designed to work. 

 

 

 

 

 

KarstenI
Kind of a big deal

I also use example.com, example.net etc. when I know I have to go to a captive portal.

Luckily, modern operating-systems have captive-portal detection which always uses HTTP. In the future a new DHCP-option will be used to find the captive portal.

Normally I have 500 users a day! Not now under covid situation. But normally I have such numbers, most

of them use their own laptop with wahtever configuration. 

Good day! I am also encountering this issue using Google as authentication. It was working fine recently then our end-user reported that the redirect to google splash page is not working on mobile devices. Is there any solution to this other than instructing their users to go to an HTTP site first since most of their users are not tech-savvy.

My library has some free pc access. We give users: firefox, chrome and edge. Firefox can detect the captive portal and suggest, in a bar, to login - no ones watch it! - the other browser don't.

 

As you can immagine I give to users our web page, that is free. Only when user want to get out the walld garden they should authenticate themselves. Users can't understand such "trick": using http://www.bing.com rather than https://www.bing.com. They normaly use google as internet. That's it! And google gives back only https link. And nothing works. And user call us that nothing works.

 

That is very annoying!

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.