Https problem

[byreco]

Hi,

we are using pfsense 2.3.2-RELEASE-p1. Before Captive portal user authentication "https" problem if the user open the https web page. send the attachment file.

thank you.

[Gertjan]

Hi,

When you connect to a network (cable or Wifi, what ever) that offers a captive portal like pfSense does, the OS, after receiving an IP (and gateway, and DNS) by DHCP, sends out a "hidden" http GET.
Example : an IOS device sends out : http://captive.apple.com/hotspot-detect.html
This NON-HTTPS GET will get redirected to the Captive portal page.
The OS detects this, ans "asks for your attention" (as "Windows" does) or just opens a very basic web browser - and the call get renewed.
This time, the captive login page shows up.

For some reason, on your device (PC ? OS ? Browser ?) this didn't work.
You (?) opened a browser and it tried to go to his default home page : https://google.com - that won't work - will never work - because MITM doesn't work.

First : Do not use this old pfSEnse versions. upgrade to 2.3.4-RELEASE-p1
Remove your own captive portal, if you upload one : use the build in 'html' page.
Then : when connecting to the captive portal network, check that a browser pops up automatically. Microsoft, Androids, Apple devices will do so … and that the login page shows up.
If not, hitting the captive portal with a https request WILL never work (this is not a bug, but a feature).
So : Make your captive portal work first.

edit : btw : the subject is wrong.

If you (your browser) asks for https://google.com and the server "on the other side" (the captive portal web server running on your pfSEnse box) replies, the certificate returned (YOUR certicate that you use for your captive portal) WILL NOT state that it is "google.com" - because he isn't ;) Your browser detects this, and fires a "Man In The Middle" MITM error.
So, all goes well, you are protected ! Be happy ! Their is no problem.

[doktornotor]

You cannot hijack HTTPS without causing certificate errors on clients. Move on.

[jimp]

If you have a current version of Chrome it should see the cert error, try an HTTP portal test, and then automatically open a new tab with the portal login. At least it does for me.

I do have HTTPS portal enabled with a valid cert (LE/ACME) for my hostname set on the portal config, and a host override pointing that hostname to the CP interface address. But last time I tested it, it should work with an invalid/self-signed cert, basically any unexpected HTTPS response, including a timeout, should kick in Chrome's portal detection.

Firefox pops up its little portal detection bar with a button to open the portal either way.

Of course all that assumes you aren't doing something like squid or a host bypass that somehow breaks the portal detection code in the browsers.

[Gertjan]

@jimp:

If you have a current version of Chrome it should see the cert error, try an HTTP portal test, and then automatically open a new tab with the portal login. At least it does for me.

I do have HTTPS portal enabled with a valid cert (LE/ACME) for my hostname set on the portal config, and a host override pointing that hostname to the CP interface address. But last time I tested it, it should work with an invalid/self-signed cert, basically any unexpected HTTPS response, including a timeout, should kick in Chrome's portal detection.

Firefox pops up its little portal detection bar with a button to open the portal either way.

Good to here all this :D I didn"t even know that our browsers are also "captive portal aware" these days.