The dreaded HTTPS pre authentication
-
Not without throwing certificate errors at the clients. Personally, I feel any solution that requires users to click through cert errors is no solution at all.
-
oh dear
I have just ordered a shed load of access points that allow multi ssid for this project.
Can I have no authentication on captive portal and still send my clients to transparent squid. I don't want to have to put proxy settings in users devices.
I have some access rules on my Cisco switch that only allows traffic from the pfsense box so I can limit the wifi traffic. I will settle for containing the wifi subnet
-
You cannot redirect https to a portal site (whether or not it asks for authentication or just says "click here") without certificate errors on the client unless you can pre-install a trusted root certificate on every client and dynamically build certificates so you can proxy, say, https://www.google.com/ with your own, trusted (by every client on your network) certificate.
Nothing to do with pfSense or its captive portal. This is the nature of SSL/TLS connections.
Some gateways redirect 443 to the portal, client certificate errors be damned. I happen to agree with the pfSense guys that it's in bad form. Though a checkbox to install the ipfw rule to do so might be welcome by some. Sort of like continuing to support PPTP.
-
What are these rules that I can bang into the firewall on pfsesne then. I am only using CP for my students so I am not fussed about them getting cert errors. I am still curious to see what the outcome is with this modified rule.
cheers
-
What are these rules that I can bang into the firewall on pfsesne then.
Never tried this myself. There might be more involved, but…
You'll need to enable the httpslogin stuff then:
In /etc/inc/captiveportal.inc
try changing this:
redirect non-authenticated clients to captive portal
add 65532 fwd 127.0.0.1,{$listenporthttp} tcp from any to any dst-port 80 in
let the responses from the captive portal web server back out
add 65533 pass tcp from any to any out
block everything else
add 65534 deny all from any to any
To this:
redirect non-authenticated clients to captive portal
add 65531 fwd 127.0.0.1,{$listenporthttp} tcp from any to any dst-port 80 in
redirect non-authenticated clients to captive portal
add 65532 fwd 127.0.0.1,{$listenporthttps} tcp from any to any dst-port 443 in
let the responses from the captive portal web server back out
add 65533 pass tcp from any to any out
block everything else
add 65534 deny all from any to any
I am only using CP for my students so I am not fussed about them getting cert errors.
You should be.
-
Thanks for that Derelict
You have talked me out of it. I am just going to settle for users having to come and see tech support if they cannot get on the wireless and then i'll explain about https homepages to them. The whole captive portal thing is too good just to discard because of https home pages.
I am going to start another thread about another issue if you would care to take a look.
-
I want to correct something:
If you enable and configure https logins in the captive portal, the https forward rule is automatically added at rule number 65531.
-
I have just come across what many other users have experienced. That is, if a users homepage is set to a https address then they are not redirected to the captive portal, http is fine although Chrome will get you there eventually.
Just check enable HTTPS login in captive portal. You have to make your own Certificate. So that your client will be redirected to the portal when trying to access https pages.
-
I have just come across what many other users have experienced. That is, if a users homepage is set to a https address then they are not redirected to the captive portal, http is fine although Chrome will get you there eventually.
Just check enable HTTPS login in captive portal. You have to make your own Certificate. So that your client will be redirected to the portal when trying to access https pages.
Doesn't make any difference - a user that's not logged in, who attempts to access https://wherever, does not get redirected to the login page.
-
Doesn't make any difference - a user that's not logged in, who attempts to access https://wherever, does not get redirected to the login page.
Yes, they do. With a cert error. Just tested on 2.1-RELEASE.
-
works fine for me aswell (some browsers just take long to get redirected)… oh btw, you can get free certs here and there and add them to the CP to get around the 'cert error'
-
No, there is nothing you can do to avoid the initial cert error when the user is redirected. The browser is expecting a certificate for, say, www.google.com, and it gets the CP's cert instead.
And when the user says "yes accept permanently" his browser will now trust your cert when going to www.google.com. Enabling you to, henceforth, be able to MITM that site. No bueno.
-
a redirect is not a MITM. it's exactly what it means… the client does not expect a cert from google , it expects a valid cert of the CP.
self-signed certs will allways give a security warning ; that's why you should get a cert from a valid Authority if you use CP for anything other then lab environments.i run multiple systems this way: no errors/warnings ever show up on any client devices.
-
The initial connection is not a redirect. It is an ipfw forward. The browser has no idea what is happening. A cert error is presented to the user because the certificate presented by the CP does not match the site the user is trying to reach. The initial https session must be established for the redirect to be sent to the browser.
-
I think I have added a "nohttpsforwards" checkbox to my test system. At least it seems to work here. Here is my description:
Disable HTTPS forwards
If this option is set, attempts to connect to SSL/HTTPS (Port 443) sites will not be forwarded to the captive portal. This 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.
