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.
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
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.
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.
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.