HTTPS Forwards doesn't work
-
With captive portal enabled, HTTPS login enabled and "Disable HTTPS Forwards" checked request to https sites hangs, it's not being passed through nor forwarded to the captive portal. I'm trying to prevent certificate error until user hits http site and then forward it to the captive portal for authentication.
-
What you are trying to do is impossible.
That's what the Disable HTTPS forwards checkbox is designed to do: Allow you to have an HTTPS captive portal page without presenting users with an HTTPS certificate error if their initial request is an HTTPS site.
You cannot answer an HTTPS request with a captive portal (really just a man-in-the-middle) without generating a certificate error. That's sort of the whole point of HTTPS/SSL/TLS.
-
…. until user hits http site and then forward it to the captive portal for authentication.
Captive users do not need to know anything about your captive portal. They will just ‘see’ the login page. This magic always work, if everybody respects the rules.
When you use a Wi-Fi network, everybody knows they should enter a Wifi password. Without that password, they cannot use the (neighbors ;) Wi-Fi network.
This, again, is known and most people understand why."Captive portal networks" do (most often) NOT use this of protection to connect to its network.
The Ethernet (by radio or wire) connection is just established as soon as you select it / hook it up.
Remember: "Captive portal networks" are not only Wi-Fi networks, they could be wired also.So, as about everybody (will) see the login page : another type of authentication is needed.
When not authorized yet, ALL initial http (http, not https **) requests are redirect to a web server that present you the …. Captive portal login page.
The 'http' word implies an important detail: only web browser use http - because only web browser can show something that a user will recognize as a page where they have to authenticate themselves.Now, the nasty part: by nature and protocol law: initial httpS request will NOT be redirected - will NOT be intercepted - period.
Even if they are, the browser will refuse at best and show a huge certificate error at least.Even without fully understanding, https requests should not be intercepted.
So, now comes the situation: an initial https request (like the navigator's starting page https://www.google.com) AND a captive portal, who intercept by design, cannot function together.
The user's navigator will refuse.
Ok, now you saw the whole picture, you'll understand that most OS's like Windows (all versions), MAC OS, iOS (Apple), and I guess also al kind of Samsung stuff will detect the portal (they issue a **hidden http:// ** request, initiated by the OS as soon as the Ethernet connection comes up) and opens a default navigator which will allow the user to see and use this login page.The nasty one: user tend to activate (without them actually really knowing what they are doing) all kind of protection schemes like "never connect to a strange network" ....
Or commercial firewall rules that really works great at home - and nowhere else (well, they are served !!)Just member this one :
A NEW device
iPhone / iPad / PC / Whatever, it will connect just fine to a captive portal.
At least, this is what I saw for the last several years, using a pfSense captive portal for a hotel.If it doesn't work, ask the user (device owner) what they did to mess up their device ;)
-
From description "If this option is set, attempts to connect to SSL/HTTPS (Port 443) sites will not be forwarded to the captive portalThis prevents certificate errors from being presented to the user even if HTTPS logins are enabled. Users must attempt a connecton to an HTTP (Port 80) site to get forwarded to the captive portal. If HTTPS logins are enabled, the user will be redirected to the HTTPS login page." My understanding is that if browser requests https pfsense will just pass it through. Is that correct? If it is then it doesn't work as expected. Or I don't understand how this option works. BTW, I do understand the whole thing about captive portal and certificates, I do not question that.
-
No. The connections just appear to hang. They're not through the portal yet.
-
Basically still doesn't work as intended. Correct? I can just forget I guess.
-
Basically still doesn't work as intended. Correct? I can just forget I guess.
Define your 'intended'.
According to RFC and family, all is ok.
But, breaking https (SSL) connections isn't easy - but it can be done.
Like : a visitor is hitting the (your) portal with https://www.google.com - You generate a certificate (on the fly) that says your portal IS "google.com", and you better assure that a major certificate broker says that google.com is YOU (your portal). Then, the visitor's browser will be happy …. and your visitor can log in (would he really think he IS visiting google.com at that moment ? ;)). When done, you portal will redirect the visitor the other, real google.com https site.
Can you pull this one off ?
