Captive portal / HTTPS / redirect / 8000

Derelict

Hmm. Developer friends…

There is some logic in the redirection code in the stock index.php that determines whether or not to redirect to https. Maybe they broke it.

rovshango

Hi,

Mostly you are right, here is output of netstat:

Before HTTPS enabled
[2.1-RELEASE][root@wifi.company.com]/root(4): netstat -an | grep LISTEN | grep 800
tcp6       0      0 *.8000                 *.*                    LISTEN
tcp4       0      0 *.8000                 *.*                    LISTEN

After HTTPS enabled
[2.1-RELEASE][root@wifi.company.com]/root(5): netstat -an | grep LISTEN | grep 800
tcp6       0      0 *.8001                 *.*                    LISTEN
tcp4       0      0 *.8001                 *.*                    LISTEN
tcp6       0      0 *.8000                 *.*                    LISTEN
tcp4       0      0 *.8000                 *.*                    LISTEN

I will compate index.php before and after, and even with fresh pfSense index.php
Cause I install pfSense in VirtualBox and HTTPS worked

Thanks for reply… I will inform results...

Derelict

Are you really not running 2.1.5? Why?

rovshango

I am running 2.1-RELEASE (amd64)
Do you recommend update?

Derelict

Of course. to 2.1.5-RELEASE or 2.2-RC1. Not that it will fix your problem but there was a pretty good flurry of captive portal fixes after 2.1 if I am remembering right.

If I were you I would upgrade to 2.1.5, replace your index.php with the default, and test again. It works.

rovshango

I will do same as you said
Let's see what will happen
I will keep you informed

Thanks

rovshango

Well seems upgrade failed somehow
Have you ever seen this?

Capture.JPG_thumb

Derelict

Let it run I guess.

rovshango

I rebooted system now it is OK
Well upgrade changed index.php to default one and everything was OK CP

But replaced it with which I took backup before… and now I can see CP page as we designed
Also I found difference between index.php's, so will try to fix it... :) with developers :)

They just made change it to get faster result, like work around, not know full CP options

rovshango

Hi again,

Anyway is it possible configure CP with HTTPS and do not get HTTPS CERT ERROR (RED PAGE) while first browsing?

Thanks

Derelict

Nope. Not a pfSense limitation. Think about it. CP is a man-in-the-middle. Exactly the type of thing HTTPS is designed to prevent.

In 2.2 there is a checkbox to disable redirects on port 443 if you have HTTPS logins enabled. This lets you enable the HTTPS login page and your users get automatically forwarded to it (without a cert error of you do it right) when they connect to a REGULAR port 80 HTTP site. But they don't get a cert error if they try to go to a secure site. It just hangs like when the HTTPS login page is completely disabled.

As more and more sites go https this will become more and more of a problem. Your instructions should probably include something like "open your web browser and go to http://mylogin.yourlocaldomain.com/" If you to that right (proper DNS Servers and domain search values), they should just have to type "mylogin" in the location bar.

rovshango

Thanks for great reply
But for 100% confirmation I meant that, when user try to open any URL my pfSense redirects to CP, so if I enable HTTPS on CP, it directs to HTTPS CP page and user gets RED PAGE, confirmation etc.

So I was thinking avoid it

Derelict

If you turn on HTTPS logins in the captive portal and the user attempts to connect to a secure site and you forward them to the portal instead, there is nothing you can to do prevent the certificate error. Think about it. They tell their browser to connect to https://www.google.com/ and they get some certificate from your pfSense instead that has a completely different CN. Certificate error - always.

If you have HTTPS logins enabled and the user attempts to connect to an HTTP site on port 80, the CP will redirect them to the proper HTTPS port on the server name defined in HTTPS Server Name in the portal. It is up to you to obtain a certificate signed by something in the client's root certificate store and get it installed in the portal. If everything doesn't exactly match, certificate error generated by the browser.

HTTPS Server Name
This name will be used in the form action for the HTTPS POST and should match the Common Name (CN) in your certificate (otherwise, the client browser will most likely display a security warning). Make sure captive portal clients can resolve this name in DNS and verify on the client that the IP resolves to the correct interface IP on pfSense.

The only way to guarantee certificate errors will not be generated by your portal is to enable HTTPS logins with all the proper certificates and hostnames and to be running 2.2-RC with the "Disable HTTPS forwards" option checked. You won't get cert errors any more but initial attempts to HTTPS sites will still hang.

There is nothing, NOTHING that can be changed in pfSense or any other captive portal to "fix" this. Captive portals break the internet by design.

ETA: https://www.startssl.com/ for free (really) certificates. And you'll get an S/MIME cert for email (also free) in the process. You, naturally, have to have control of the domain(s) under which you obtain certs.