Captive Portal ERR_SSL_PROTOCOL_ERROR



  • I'm using the captive portal but now getting errors "ERR_SSL_PROTOCOL_ERROR" on browser. Not using SQUID and using a valid commercial SSL certificate. I think this may be because of a browser update requiring higher versions of SSL? Think I saw something similar in IIS and wequire disableing SSL 2.0 & 3.0.
    Anyone have the same issue of can confirm if I'm on the right track? Also if I am, how to I enforce TLS 1.0 or higher in PFsense for the captive portal response?



  • @rm Maybe I'm not on the right track. So you can navigate to the admin portal without any certificate issues but if you try to navigate to 8002 you get the protocol error. Same certificate on both. Anybody able to tell me what the issue is?


  • Rebel Alliance

    @rm 8002?

    when u are using HTTPS, you are normally redirected to port 8003

    port 8002 is for HTTP requests



  • That's helpful! But I try 8003 and I get a blank page, no error message. The only think that should have changed would be my client devices or a security update. The captive portal renders on old unpatched machines and mobile devices, but current patched devices are not functioning. I'm assuming it's a new security requirement either from a browser or OS patch. The previous behavior would be the user navigates to a page and gets redirected to my https logon page. Just tried a roll back to a previous config when I know it was funtioning with no luck.



  • @rm said in Captive Portal ERR_SSL_PROTOCOL_ERROR:

    using a valid commercial SSL certificate

    Any recent, signed by a known certificate authority will do.
    To make the cert work, you have to import it. For me, it's now some years that I did that, because there is no need to do the annual renewal manually.
    To have a signed certs that works for all and everybody, use acme. The only condition is : you'll be needing a domain name that you / control.

    Let's say my domain name is "localtech.net" - that's the one I rent from some registrar, that also offers complete DNS facilities.
    I'm lazy, so I asked for a wild-card cert from LetEnscrypt using the acme package. So now I can use an URL like pfsense.localtech.net for my https GUI access - and also https://portal.localtech.net for my captive portal access portal.
    As always, the captive portal user has no notion of the fact that he should be using this URL - or https, or some strange port number.
    He is redirected to our captive portal login page, whatever URL or port number it has. The user doesn't need to know and most probably he doesn't care. At best he sees the green pad lock.

    You need to add this host override to the Resolver :

    8733a576-4959-4a44-8e1b-719b39b036a3-image.png

    Note that 192.18.2.1 is my captive's portal network. It's a OPTx or second LAN connection (because portals should not be mounted on LAN).

    Activate the https access on your captive's portal settings page :

    4abaa711-a0df-4588-894e-0c19d471c255-image.png

    Remember to assign the correct certificate - in my case the wild card "localtech.net" cert .

    This setup works with any device, something old as an ancient Windows Vista laptop up until the latest iPhone.
    Maybe very ancient browsers won't support it, I don't know.

    @rm said in Captive Portal ERR_SSL_PROTOCOL_ERROR:

    how to I enforce TLS 1.0 or higher in PFsense for the captive portal response?

    From what I recall, TLS 1.0 is out of business.
    I questioned the oracle and it said :

    			// leave TLSv1.0 for CP for now for compatibility
    			$nginx_config .= "\t\tssl_protocols   TLSv1 TLSv1.1 TLSv1.2;\n";
    

    but understand that this https session is between the user's device and the captive portal's web server running on pfSense. It's a very local connection. It doesn't go out over the Internet.
    And the data being transmitted is the page with the login code and password.
    No phone numbers, no bank info, nothing (you aren't asking these, right ?)
    That's why "compatibility" is more important here as security.
    As soon as the page is submitted, the captive portal user will get redirected to the page he initially wanted to visit, most often some page on the Internet. The TLS being used then is non controlled by pfSense.

    Btw : and now you know how to make the captive portal using "TLS 1.2 only" (and the GUI) ^^


  • Rebel Alliance

    @rm hum...
    i may know the cause :

    the captive portal expects an argument ("cpzone") to be given in the request.

    this argument has to be passed as http get ( https://pfsense:8003/index.php?cpzone=nameOfMyZone )

    when no arguments are given, an error is written in the logs

    no error is printed on the page for security reasons however (because this blank page is likely to be be viewed by visitors trying to do some pentest)

    you should have a look to the captive portal logs In pfsense



  • Thanks!, certificate wise I think I'm good but I'm trying to make the changes for the nginx config. Which file would this be and in what path? Using Diagnostics/Edit File to try to fine the right one. Ignoring the "Advanced Users Only" warning



  • Found a /usr/local/etc/nginx/nginx.conf ,; and I supposed to drop this witthin that file?

    			$nginx_config .= "\t\tssl_protocols   TLSv1 TLSv1.1 TLSv1.2;\n";

  • Rebel Alliance

    @rm this nginx.conf is re-generated every time you update some captive portal settings. you need to edit the file that actually generate the nginx.conf

    the file to edit should be /etc/inc/captiveportal.inc (@Gertjan do you confirm?)



  • Thanks! I don't see any existing reference, just drop it at the end or does it need to be nested anywhere?



  • @rm I do see two"system_generate_nginx_config" nested ifs...


Log in to reply