Time-out on https (how to redirect https to http)?
-
Hello all :-)
Happen that after "hard timeout" disconnects the clients, when clients try to connect requesting https sites, browser goes to timeout.
Is there a way to force CP to redirect https to CP page?
Many website uses https indeed http
thanks for help
-
No. Do an advanced search for https limited to captive portal. It has been explained many times.
-
thanks for your reply
is there a work around or a way to bypass the problem?
is a pfsense limit?
-
No. It is the nature of HTTPS/SSL/TLS.
-
ok, can you explain me why in other scenario like hotels and pubs I connect to captive portal and I don't have this problem?
thanks for help
-
You either get a certificate error, have trusted their root certificate (technical term for that is bad), or are not connecting to an HTTPS site initially.
Think about it for just one second. If your captive portal could impersonate any HTTPS site, then it could impersonate any HTTPS site.
-
I'm sure: I connected to CP and later I switch my mobile to browser and I try https://www.google.com
works.So, how can I emulate this on pfsense?
no matter man in middle https. I need to do a proof.
thanks
-
The only way to use HTTPS with captive portal is to enable HTTPS logins and don't disable HTTPS forwarding.
Users will get a certificate error.
If you think you are going to an HTTPS site and getting a captive portal page without certificate errors and with no extenuating circumstances such as trusted roots you are mistaken and need to test it again.
-
I think understand. So, CP in hotels has a CA certificate signed so clients does not need to accept the certificate? and the connection to https is transparent?
How works CP in hotels?
I see that zeroshell (a Linux distribution with CP has not this problem).
thanks again for your help!
-
BS. There is no way to get an uncontrolled user browser to just accept some other certificate. Think about it for just one second.
-
How works CP in hotels?
I have pfSense running for a hotel.
"https" login is enabled - and I have a signed certificate for my "pfsense captive portal" (using a cert from startssl.com).Still, users that open a browser and hit https://www.facebook.com will no be redirected to the captive portal page ….
But, there IS a solution ....
and for the last couple of years, I do not see any client anymore who say : "your free wifi access doesn't work !"I see that zeroshell (a Linux distribution with CP has not this problem).
Many OS's (Windows, iOS, MacOS, etc etc) do this right now :
You accept and connect to a "Wifi" network (your pfsense portal).
At that moment, as soon as the IP, DNS, Gateway, etc comes in (using DHCP), the OS launches a simple http (http ! not https) GET to a preprogrammed site.
For example, for iOS (iPad, iPhones, etc) this will be something like http://captive.apple.com/hotspot-detect.html - which exists.
IF this return something short like "Succes" the the OS knows that it has a open connection to the net.
IF it return something else - like our pfsense portal login screen, then the OS will open a default browser so the user sees this page … our pfsense portal login screen.
So, for 99,99 % in all cases, all goes well.Then there are the stupid OS's who still did get it, and let the end user wonder WHY all surfing ends with an error. Up until he/she discovers that http://... does give some back : our pfsense portal login screen.
-
IOS still fails with badly configured wifi all the time.. Just ran into this.. Yes it tries to get you to the login page once you connect.. But gets sent to 1.1.1.1 from default cisco configuration and invalid cert which ios fails at and no way to just accept the bad cert so you can get login in.
You have to tell it not to login, and then connect and open browser to normally a http site, and get redirect - but quite often this sends you to https that again has bad cert and atleast if using a browser that allows you to accept the non trusted cert and then login, etc.
If your going to direct your users to a https portal page, then that cert should be signed by trusted ca for the fqdn you send them too, or they should trust your CA for that site. But as mentioned your going to have problems if you just send them to portal when they try and go to https://www.facebook.com because your cert not going to be valid for that CN, only your CN, etc.
You would hope anyone that has ever used wifi would have the brains to figure out to go to http for portal auth, and or accept any cert errors when they are trying to auth, etc. Your always going to run into that typical users that doesn't get it, never been to a hotel and used their wifi, etc. So you can make it atleast less likely to cause problems.
As posted by Gertjan you would hope the OS is smart enough to try and go somewhere via http, and if they get anything back that is not where they tried to go then sure it should let them open up the http page they get redirect too. Problem is when that page tries and redirects to https, which if that is not a trusted ca and matching cn, san for that cert then users going to get errors or just fail because they can not allow the exception..
Derelict is right on the money here when if you go to a ssl site that cn doesn't match or you don't trust the CA, etc. your browser better being having a hissy fit about it.. And letting you know!!!
-
IOS still fails with badly configured wifi all the time.. Just ran into this.. Yes it tries to get you to the login page once you connect.. But gets sent to 1.1.1.1 from default cisco configuration and invalid cert which ios fails at and no way to just accept the bad cert so you can get login in..
Hummm.
That might be my saver over here : no Cisco devices or what so ever.
Just tried it again (I could post a vidéo !) :
I connected to one of my 4 portal Wifi radio networks.
I accept on my device (iPhone).
A couple of seconds, the (my) pfsense portal page pops up and I can login.You would hope anyone that has ever used wifi would have the brains to figure out to go to http for portal auth, and or accept any cert errors when they are trying to auth, etc. Your always going to run into that typical users that doesn't get it, never been to a hotel and used their wifi, etc. So you can make it atleast less likely to cause problems.
True.
Except for the bad cert - I'm not using autosigned ones, but (free) certs from startssl, recognized by all browser as "ok".People/clients do login by themselves https://www.test-domaine.fr/munin/brit-hotel-fumel.net/pfsense.brit-hotel-fumel.net/portalusers.html (noop, no doc in the building how to do so) and I'm not explaining them how to do so. It just works ….
