Is it possible to redirect https-Traffic to the Captive-Portal-Login Page?
-
Hi,
in an older thread I read that it is not possible to redirect https Traffic to the Captive-Portal-Login-Page, but in my test-environment ist seems to work with pfsense 2.2 now.
The only problem is that i get a certification warning if I try to open https://www.google.com for example and get redirect to https://wlan.mydomain.com
Is their a workaround for it?Thanks!
-
No, there is no workaround for machines that are not under your control.
-
Thank you for your quick response.
It seems that our users have to handle this problem… :( -
The only problem is that i get a certification warning if I try to open https://www.google.com for example and get redirect to https://wlan.mydomain.com
Is their a workaround for it?Think about it like this:
The user is asking for https://www.google.com - so its browser wants to get a (valid !) certificate that states that the server "google.com" is google.com. This domain name (and also sub domain names) must be in the certificate.
Or, the certificate that he gets says: "Hi, I'm "wlan.mydomain.com" ….." The browser thinks "WTF ...." and it will show big message to the user like "Maybe this isn't the site that you were looking for - bail out, drop dead, or continue at your own risk ?".All this because you are intercepting SSL traffic with your portal - you're playing the "man in the middle" game.
User don't want that (they don't know whats happeing, but believe me, they don't want that).The only solution is : get your self a super certificate that says "Ok for all domains" (don't bother, no one will sell that one to you :))
Some how, a person that uses a portal should know that he ALWAYS should starts is session with a non https 'call' first.
So, he knows already that he should connect to your wifi network.
He should start non-hppts session with a browser (no, that facebook app won't do - neither that mail-client)…. and authenticate.
After that, he can do what he wants as usual. -
Say the user's default browser home page is his bank.
Your portal jumps in the middle and presents its own certificate and the user's browser presents the warning.
User then screws up and saves YOUR certificate and says to trust it when going to https://www.hisbank.com. Users have no clue what they're doing. Consider you might have thousands of different people hitting your portal every week. At least some of them will be completely clueless.
Now you have a permanently-installed certificate on that client with which you can MITM connections to his bank.
Bad. Very bad.
The only winning move is not to play the HTTPS MITM game. Pay for someone to answer the phone and tell the user to open a browser and go to 10.10.10.10. Portal responds, and you're done.
-
Good news : some (if not most) OS's (like Windows or iOS) will pop up a browser if it detects that after a successful wifi-network-connection the "Internet connection" isn't 'open'.
The OS will lauch a browser and make a request to a semi random non-https site.
This will provoke the (your !) Portal Page to be shown.The user rests ignorant about what happens - and all goes well :D
-
Thanks at all, specially for the good news ;)
Is it also possible to open the Browser automatically with a wired-connection? -
Is it also possible to open the Browser automatically with a wired-connection?
The Captive Portal doesn't even know what "Wifi" is The two are not related.
Wifi is just a practical, nearly all devices are equipped.
You could use CPL, Bleutooth, other radio connections, classic RJ45, etc etc - there is not limit. -
But it seems that my Mac is more likely to do all the checks and auto-open the portal page when I connect to a new wifi network instead of a new ethernet network.
It's completely up to the client to make this happen. There's nothing to do on the captive portal server.
-
Just this moment I tried to verify this with windows 8 and it works very well: As soon as i got connected to the pfsense-network, a Browser opens automatically with the Captive Portal site.
