Captive Portal https login : How please ?
-
Hello,
is there somewhere a good tutorial about how to configure the CP for https login to avoid ARP Spoofing ?
I found this but it's not accurate at all :
http://www.rocainet.com/2014/03/securing-captive-portal-login-page-on.html
Also I don't understand the field : HTTPS Server. As everything is running on Pfsense, isnt't then Pfsense the HTTPS server ? Which name to enter there as the CP portal regarding on the interface used, will redirect you to 192.168.2.1:8000 etc… So I really don't understand how to do it.
Also another question, if a certificate is buyed, is it possible to use it for that purpose ? (for now, I just wand to understand how it works, and creating self-certificate).
Thank you very much to guide me through this !
Neo -
There is no way to use an HTTPS captive portal without the user getting a certificate error, so if you're worried about a MITM jumping on the network, arp spoofing your gateway's IP, and being the captive portal instead of you, you're out of luck.
It will work fine for users who initially attempt to go to an http (port 80) site but if they initially try an https site they'll get your portal instead and a certificate name mismatch error.
It can also work if you can force your users' first https attempt to be, for example, https://portal.example.com:8001/ (Might also work if the initial URL is https://portal.example.com/ - haven't tested it). I can't think of a way to have that much control over portal users' browsers.
Anyway, if that's what you want, just upload a certificate (System->Cert Manager->Certificates), check the https enabled box, set the https host name (match what's in the certificate), and select the certificate.
 -
Thanks for those details. But I'm not sure if you got what I want.
It's not about letting user browsing https addresses on the first logging, before being redirected to the portal login page.
But it's just about "protecting" the authentication process, sothat the login information (voucher code etc..) are not sent in clear text to the gateway. So therefore I need to secure it with SSL, right ? (please correct me if not correct, I m just learning :) )I enabled it, created a CA in Pfsense, created an internal certificate and selected if for the https login. As common name, I entered www.abc.com. As I read, the same should be entered in the field HTTPS Server in CP configuration. So I entered www.abc.com also.
Then I tried to connect to the Hotspot, I'm redirected to "www.abc.com:8001….......&dredirurl... etc..:". So that's what I don't understand.
I'm then confused about the configuration. I don't have a domain name abccc.com, so why entering a such address there if anything is working on the box in the internal server ?
in a other manner said, how to configure https login when I don't own any domain name like abcde.com ?And about certificate error, it's normal with self signed certificates. But If I buy a ssl certificate, I can then import it, then normally, there should be no error anymore right ?
What I need to understand first, is how this https configuration really works. Do I need really a subdomain like portal.abcd.com for that ? (then enabling portal.example.com to pass through CP ? )
Thanks for your time guys ! You are so lovely ! :) I hope so to be able to assit others in the future :)
-
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.
