Situation: Hotel guests attempting internet access via our captive portal. Problem: Google, Yahoo and now more and more sites redirecting all home pages to HTTPS so guest gets a Certificate error when we redirect them to our log on page. Appreciate purpose of SSL is to do exactly this but wonder if there is another way to manage a guest log on confirmation process to confirm their identity, before enabling access through firewall. It's freaking guests out who do not understand. Basically need a different architecture for a captive portal/authentication process and wonder what thoughts any one has. Thanks.
-
Possible solution: WPA2-Enterprise with a Radius authentication server.– Ajedi32Feb 17, 2015 at 14:49
-
This is not a solution, but for the moment servers as a workaround. Allow users to access https freely, and on the first http hit, they will be redirected as Industry moves more and more to https this will be obsolete.– cuscoDec 22, 2016 at 20:02
4 Answers
The Chromium Project has a good page describing how their logic works for detecting captive portals:
- Attempt to connect (plain HTTP) to a well-known host + URI
- Expect
HTTP 204 No Content
- If a different response is received, assume it's a captive portal.
There are other details in the provided link regarding how they handle DNS failures when trying to resolve the well-known host, etc. This is just one example, but (in my personal experience) modern OS designs are using processes similar to this to detect and prompt the user even, in some cases, before the user opens a browser. (Consider: someone who only wants to use an IMAP client or other non-HTTP service.) In that case, the detection occurs not over SSL/TLS so your concern is avoided.
RFC 6585 Section 6 proposes a new HTTP status code 511 Network Authentication Required
that doesn't help your SSL/TLS case but is another standard you might consider if you don't already use it.
-
1Android also has support for detecting captive portals. When it detects a captive portal it displays a message on the status bar. The wording is something like "Sign in to wireless network". That happens even if no application has tried to use the connection yet. At some point I also noticed a captive portal sending a 30x redirect with an extra HTTP header, indicating that this was a captive portal, and the body contained some XML data. I don't know if that is some standard behavior.– kasperdMay 18, 2014 at 22:13
The whole definition of "captive portal" revolves around "redirecting the user without his/her knowledge", which is exactly one of the things SSL was created to avoid.
If the first URL the browser tries to open is a HTTPS one, there's no way of redirecting the traffic without creating a certificate error.
-
5Yeah, I think the OP understands that. The question was: what's the alternative? (E.g. If every site in existence used HTTPS, how could you "manage a guest log on confirmation process" without a captive portal?)– Ajedi32Feb 17, 2015 at 14:11
temporary solution is guide users to start URL beginning with "http" only after connected wifi signals.
but unfortunately , users doesn't like it. they says "how complicated wifi service did you have"
In any case, if the users receive a certificate error is because the Certificate doesn't match the Site hostname.
In your case, this means that you are redirecting users to your portal without changing the URL. The users see "http://www.google.com" in their address bar but your portal in the screen. These doesn't match, obviously, and the certificate doesn't, either.
You need to redirect them in HTTP (before HTTPS jumping) to your portal address (or server name), have them log in there, and then redirect them again to the intended destination, which will match correctly.
See https://en.wikipedia.org/wiki/URL_redirection#HTTP_status_codes_3xx for how to perform it with HTTP 3xx codes, specially 303.
-
Most users probably don't type
https://
, but any stored bookmarks or other pinning mechanisms may result in the first request going to an HTTPS-based service and thus failing because TLS handshaking fails before reaching the HTTP protocol layer for a redirect. Other than bookmarks, examples of such "pinning" include a browser's search bar having prior knowledge that the search provider prefers queries via HTTPS; or a mobile app connecting to secure network services. May 13, 2016 at 23:00