The dreaded HTTPS pre authentication
-
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.
