I have a captive portal setup for my organization that forces users to authentication prior to being allowed access to the network. Challenge is that when a user opens their browser and their homepage is https (e.g. https://google.com/) and I redirect their traffic to http://myportal.company.com the end-user receives an error.
As the web has defaulted more and more to HTTPS (which is good!) it is now causing me a problem.
What options do I have?
A captive portal is essentially doing a man in the middle attack. HTTPS and other protocols using SSL/TLS are explicitly to detect and prevent such man in the middle attacks. This leaves you with two choices: don't do a man in the middle attack or make the client trust the man in the middle. All fully transparent solutions require that you have some control of the client.
Trusting the man in the middle is in many cases possible if you can add the man in the middle CA of the captive portal as trusted to the client. In some systems like windows this can be done in an automated way (group policy). If browsers will see that the certificate is signed by this explicitly added CA they will also disable checking of public key pinning (explicit and builtin HPKP). But note that it will not work in all cases, i.e. there are non-browser applicatons like Dropbox which continue to do certificate pinning and thus will not work any longer.
Non doing a man in the middle attacks works if you configure the captive portal as an explicit proxy in the client. If proxy autoconfiguration is enabled in the client this can be done with a WPAD server, it can be configured with group policy or it have to be manually configured. With a proxy you could request authentication. But you are limited to either basic authentication (username and password) or to transparent authentication using NTLM. There is no way you could first present some information to the client which he has to accept. Proxy authentication also only works if the client knows that it is talking to a proxy. Simply intercepting normal HTTP/HTTPS traffic and sending back a proxy authentication request will not work. This also means that applications which are not aware of the proxy (i.e. don't use system settings) will not work.
And finally you could abandon any attempts to redirect the user and simply post information which describes that the clients should first authorize themselves using some internal URL. Until this is done any access simply fails and once the client has authorized himself the MAC of the specific client is allowed for a while.
If I understand your question, you have a proxy server that blocks internet access until the end user has authenticated. By "blocks" I mean: If your proxy receives a request for https://google.com, it will spoof the requested host (google.com) and return a 302 redirect header to a login page that is hosted on the proxy itself. This a very common scheme that can be found in public wifi in McDondald's, Starbucks, etc. and is also pretty common in corporate settings.
The issue with this is of course the spoofing. Spoofing google.com will cause a cert error, although (until recently) the user could click through this. The introduction of HSTS now makes it impossible to get around the cert error and proceed to the proxy's login page, and there is little an end user can do to override it.
As an end user, I have been encountering this as an issue more and more lately. The way I have been dealing with it as an end user is to navigate to a site that doesn't have HSTS (e.g. CNN.com) or to navigate by IP (e.g. http://192.168.0.1). These will also get intercepted by the proxy but I can get around any cert errors.
I believe the "correct" way for a proxy server to demand authentication is not with a 302 redirect but with a HTTP 407 Status Code which means "proxy authentication required." The proxy should respond with this header instead of the 302 redirect. The browser should know how to interpret HTTP 407 and present an appropriate dialogue for collecting user name and password.
Second option....If this is a corporate network and you have the ability to push group policy, you could use it to set the browser home page to the proxy login page, thereby eliminating any need for redirections.
What we are doing is using DNS Views to redirect clients we have not see on the network before to our captive portal to authenticate and receive unrestricted DNS access. So we are not even doing a 302 redirect. When you ask for google.com, my DNS servers just tell your computer that its 192.168.10.51.
– nitrobass24 Sep 11 '16 at 02:25Chrome detect captive portal:
When a main frame HTTPS load is taking a while, we preemptively open a background request for http://www.gstatic.com/generate_204
https://docs.google.com/document/d/1k-gP2sswzYNvryu9NcgN7q5XrsMlUdlUdoW9WRaEmfM/edit
This determination of being in a captive portal or being online is done by attempting to retrieve the webpage http://clients3.google.com/generate_204.
https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection
