Captive Portal https login : How please ?
-
Like I said, the only ways to avoid certificate errors on initial connection - even with a purchased, valid certificate, is for your users to connect to an http (port 80) site initially and get redirected to the https portal page.
OR they need to initially connect to, say "https://portal.example.com/" so there is no redirection (other than the port to 8001 and I'm not sure if that will trigger a certificate error) and the browser gets a certificate for the server it's expecting.
Think about it. You're concerned about protecting the contents of the portal login page. A user connects to http://somesite.com/ SOMETHING in the route intercepts that and forwards the user to https://portal.example.com:8001/. There is nothing stopping that from being a bad guy and forwarding the user to any site they desire.
OR, the user connects to https://somesite.com/ The captive portal intercepts the 443 connection and instead presents a different certificate and page. The browser necessarily throws a certificate error because the server name in the certificate does not match the server name the browser is trying to connect to. This certificate error could be from your portal or a bad actor's interception.
Captive portals break the internet. Period. Especially true when https is involved. You are playing man-in-the-middle games and that's exactly what https is designed to combat.
There is a patch in 2.2 that allows you to enable the https login page but turn off the forward of https attempts to the captive portal. This should stop all certificate errors in exchange for connections to https sites hanging like they do if you don't enable the https login page at all.
-
Like I said, the only ways to avoid certificate errors on initial connection - even with a purchased, valid certificate, is for your use
This should not a big deal. I can write on the instructions, please connect first to a http site etc…
Think about it. You're concerned about protecting the contents of the portal login page. A user connects to http://somesite.com/ SOMETHING in the route intercepts that and forwards the user to https://portal.example.com:8001/. There is nothing stopping that from being a bad guy and forwarding the user to any site they desire.
I understand that SOMETHING can forward the user somewhere else
BUT if not the case, as soon as the user will reach the RIGHT https login page without being intercepted, the authentification will be secure, and that's what I want to achieve. We know all that 100% security does not exist, but at least we must try to secure what we can secure (that's my opinion :) )
And M-I-T-M Attack is not something that everybody can do ;)There is a patch in 2.2 that allows you to enable the https login page but turn off the forward of https attempts to the captive portal. This should stop all certificate errors in exchange for connections to https sites hanging like they do if you don't enable the https login page at all.
In 2.2 ? You mean Pfsense 2.2 as we have now 2.1.5 ? Oh for when is it then ? :))
But anyway, I don't still have an answer to my question : How to configure properly https login ? What should be enter as Https Server when everything is saved on the Pfsense box and when I don't have a domain name like portal.abc.com ?
Thanks !
-
You do have an answer to your question here:
https://forum.pfsense.org/index.php?topic=81276.msg443884#msg443884
-
My question is about –-->>>>> "https host name"
Can I enter there the IP of my Pfsense box ? I Guess no, how to manage it please ? -
neobauer,
It is possible www.abc.com has valid DNS entry. So you get redirected to the global routable IP instead of your CP interface. Since foreign IP is blocked by default, your browser eventually return a timeout error.
See if the following resolved the issue,
1. Go to services->DNS forwarder
2. Under Host overrides, add a new entry
host: www
domain: abc.com
IP: <your pfsense="" cp="" interface="" ip="" address="">3. Save and apply setting. Clear your computer DNS cache just in case.You should get redirected to your CP page or getting certifcate warning / error. Instead of timeout.</your>
-
`YESS 8) This is the answer I'm looking for ! :)
I will test today and see.About the error message : I guess it's because of the self signed certificate right ? Meaning with a buyed and registered certificate, I will not have the error right
-
No, you will STILL HAVE THE CERTIFICATE ERROR - EVEN IF YOU BUY A CERTIFICATE - unless you can convince all your users to enter your captive portal URL as their initial connection.
-
okayy so for now it doesn't make sense to use it really.
You wrote :
There is a patch in 2.2 that allows you to enable the https login page but turn off the forward of https attempts to the captive portal. This should stop all certificate errors in exchange for connections to https sites hanging like they do if you don't enable the https login page at all.
Can you please tell more about this patch ?
-
It adds this option:
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."
-
Sounds good :)#
Where can we get the 2.2 Alpha ?
Possible to use it already in Production environment or just released for lab now ? -
https://snapshots.pfsense.org/
As to its suitability in your environment, your call.
