SSL Certificate errors in Captive Portals
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
- 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.
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.