SSL_ERROR_NO_CYPHER_OVERLAP when trying to connect to webgui



  • I'm can't connect any more to my pfsense gui with firefox. Get this sorry for french :

    Impossible de communiquer en mode sécurisé avec le pair : aucun algorithme de chiffrement en commun. Code d’erreur : SSL_ERROR_NO_CYPHER_OVERLAP
    

    Thanks for any help



  • Same here, I've had that error message for about 2 months now.
    I've been locked out for too long :'(

    Firefox error message:

    Cannot communicate securely with peer: no common encryption algorithm(s). Error code: SSL_ERROR_NO_CYPHER_OVERLAP 
    

    Chrome error message:

    ERR_SSL_VERSION_OR_CIPHER_MISMATCH
    

  • Rebel Alliance Developer Netgate

    Are you using a current version of Firefox? I could maybe see that happening on an ancient version.

    And are you connecting to the pfSense WebGUI? And not something else like ntopng or a port forwarded server?

    Are you using the default self-signed GUI certificate or did you place a custom certificate/CA on there (maybe a ACME/LE cert using EC?)



  • @jimp I'm on current Firefox version but cannot connect in https with Chrome, Opera and Edge.

    I'm thinking I'm connecting to the Webgui since I can connect in http.

    I'm using the default self signed Cert.


  • Rebel Alliance Developer Netgate

    First, go to the ssh or console shell (option 8) and run this:

    pfSsh.php playback generateguicert
    

    That will make a fresh certificate and activate it. See if that help.

    If it does not, then use option 2 to reset the LAN IP address but enter the current value, after doing that it will prompt if you want to change the GUI to use HTTP. Do that, and then see if you can connect. Then make sure your other GUI settings are correct and you don't have any port forwards or other daemons (e.g. openvpn, haproxy, etc) trying to use port 443 leading to a conflict with the GUI.



  • I have run in console shell :

    pfSsh.php playback generateguicert
    

    With the same result : no https connection to the Webgui (aka SSL_ERROR_NO_CYPHER_OVERLAP), I can connect without problem via http.

    I have revised all my settings and there seem find. I don't saw anything trying to use port 443...



  • @crbon Do you have Bitdefender AV on the system you trying to connect with (I have it and asking my self if it's related)



  • @xenicle Yes I do have Bitdefender AV. However I have tried using my phone and I still got the error (not sure if it was exactly the same, but sure was similar, as otherwise I would have looked into that).

    I have tried using multiple browsers on multiple PC's - Firefox, Chrome, Edge, even Internet Explorer 11, Firefox (Android), Chrome (Android) all having the same issue; not being able to get to the login page.

    I would like to note that I am using the default self-signed certificate.
    Also I don't remember making any changes to pfSense when the issue initially came up.

    I was able to resolve my issue by SSH-ing into the pfSense computer and recovering to a version a few versions prior to the current. For me it displayed something to do with the self-signed certificate in the last few entries, e.g. Generating self-signed certificate.

    The following steps depict what I did to fix it:

    • list itemFirst backup your current config (just in case)

    • Try and restore to a backup before the certificate entries.

    • If you do not have any entries with the certificate, still restore to a few versions back

    • Let pfSense reboot and run a bit, then try and access the webGUI again

    • If that doesn't work, try to restore an even earlier backup.

    • Finally, you can try update pfSense to the current version from the SSH console.

    The steps above is what I did over the weekend and somehow got it to work. I no longer get the error, everything works as expected.

    As far as I can tell, one of the steps made pfSense regenerate the default self-signed certificate and this is what has resolved the issue. Unfortunately I'm not 100% what fixed the issue, was it restoring of the backups, the update or maybe even both.

    If you need more info or assistance, I am happy to help out when I get back from work.



  • I too am having issues with this on Edge, FireFox and Chrome.

    I've lost a secure way to manage my Pfsense boxes, as I now had to drop all of them to use HTTP instead of HTTPS because of these issues. None of the solutions here have worked, nor has any of the suggested workarounds on google for Firefox and Chrome.

    I've had to settle with using HTTP for now, just so I can have visibility into my PF boxes.

    Does anyone know if PF/NetGate has plans to support SSL/TLS that is acceptable to these browsers? I can not run on HTTP for long, our vulnerability scans are already lighting up my email box which I am ignoring for now, and I am dreading our next network security audit as they will have a fit with us using HTTP on an unsecured network.

    Regenerating certificates does not work either, nor does using our corporate certificates.

    Really need a working permanent solution, and not a bandaid fix.


  • Rebel Alliance Developer Netgate

    @beb-consulting said in SSL_ERROR_NO_CYPHER_OVERLAP when trying to connect to webgui:

    Does anyone know if PF/NetGate has plans to support SSL/TLS that is acceptable to these browsers?

    We do, and it works fine for most people. There is something specific to your setup causing this, but so far nobody has done the leg work to figure out what exactly triggers it.


  • Rebel Alliance Developer Netgate

    @crbon said in SSL_ERROR_NO_CYPHER_OVERLAP when trying to connect to webgui:

    The steps above is what I did over the weekend and somehow got it to work. I no longer get the error, everything works as expected.

    That doesn't sound like anything that would have actually made a difference, except maybe it caused the GUI to restart and rebind to the port.

    Are you certain you don't have anything else in your config.xml trying to use port 443 on the firewall (like OpenVPN maybe?)


  • Rebel Alliance Developer Netgate

    Anyone that hits this, here are a few commands that you can try to see what is going on. These would be done from a client system off the firewall, like your computer. Though I'm not sure these are as easy to pull off in Windows as they are in FreeBSD/Linux there may be equivalent commands out there (or use the Ubuntu integration in Win10 or a VM)

    • Install sslscan and run it against the firewall web server, for example: sslscan 192.168.1.1:443

    • Use openssl to ...

      • See what software the server is running: echo -e "HEAD / HTTP/1.0\nHost: 192.168.1.1\n\n" | openssl s_client -quiet -crlf -connect 192.168.1.1:443
      • Check the certificate chain and TLS details: echo -e "HEAD / HTTP/1.0\nHost: 192.168.1.1\n\n" | openssl s_client -crlf -connect 192.168.1.1:443
    • On the firewall, run sockstat | grep 443 to see what is bound to port 443

    Post the output of all that, you can remove the hostname but keep the other data. Nothing else should be private.

    What you should see is that it's nginx and supports a current set of secure ciphers (TLS v1.1, v1.2, AES-GCM and AES-256)



  • Ok ran sslscan and it is showing that the PF webgui only supports ssl/tls 1.0.

    Running openssl, it appears that it ONLY runs ssl/tls 1.0.

    There is no SSL/TLS 1.1, 1.2 or 2.0 listed in any of the output. There are MANY AES and RSA versions listed.

    All our PF Appliances and VMs are running into this issue, including our AWS PF Instance, they all run the same version of PF: 2.4.4-RELEASE

    We have nothing else running on port 443 on PFsense, openvpn runs on port 9443 - 9999 which are not standard ports we use for our VPN tunnels other than our IPSEC tunnels to AWS which use the ports for IPSEC and supported by AWS.

    This issue started right after updates to Chrome 70, and FireFox 63 or Edge after the latest Windows Update.

    After doing some heavy digging, it appears that after Chrome 50 and FireFox 52 and Edge Spring Windows Update, support for anything less than ssl/tls 1.2 has been dropped or being phased out due to security issues. Apparently this is industry wide...however I have nothing in any tech notes I get....anyways.... it appears that at Chrome update 70, Firefox Update 63 and Edge October update, SSL/TLS support for 1.0 has finally be completely cut off.

    We have also noticed other SSL/TLS based webguis (Cisco Smart Switches, ESXi, GreyLog Appliances) also had this same issue, however after doing an update/upgrade on these via firmware or OS/Application patch installs, they started to work again, our guess is the update/upgrades removed SSL/TLS 1.0 and either upgraded it to 2.0 or something higher than 1.0.

    It looks like alot of web based GUIs that are HTTPS are moving to SSL/TLS 1.2 or higher. support, however PF/Netgate are still sitting with only SSL/TLS version 1.0 support.

    It looks like PF/NG need to upgrade or patch to remove SSL/TLS 1.0 and only support 1.2 or higher.

    So it looks like until this happens, we will need to stay using HTTP mode on PFSense or move to another product.

    I am sure there are ways to manually force PF Webgui to SSL/TLS 1.2+, but I am not one for going rogue on appliances without direction from the vendor or just waiting until the vendor comes up with their solution.

    I will just need to wait it out, and hope a fix will come before our next security audit OR see if I can get an approved security exceptions or find another product that supports our needs. Otherwise setup a separate dedicated management network with a management workstation/VM that has downgraded browsers installed and no direct internet access, which might raise other security audit concerns.....not sure exactly now what the plan forward will be.



  • @beb-consulting said in SSL_ERROR_NO_CYPHER_OVERLAP when trying to connect to webgui:

    It looks like alot of web based GUIs that are HTTPS are moving to SSL/TLS 1.2 or higher. support, however PF/Netgate are still sitting with only SSL/TLS version 1.0 support.

    Nope, Firefox 63.0.1 is quite happily connecting to pfSense 2.4.4 using TLS 1.2 here. Something is messing with your HTTPS connections there.


  • Rebel Alliance Developer Netgate

    Then you have something wrong on your setup. The pfSense GUI on 2.4.4 only supports TLS 1.1 and 1.2:

    		ssl_protocols   TLSv1.1 TLSv1.2;
    		ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH";
    
    

    The only time 1.0 is turned on is when Captive Portal is enabled, but even then it is in ADDITION to 1.1 and 1.2 and only for the captive portal web server NOT the GUI.


  • Rebel Alliance Developer Netgate

    Either your connection is being redirected to some other web server (NAT rules/reflection, perhaps) or something else is taking over the GUI port.

    What you are seeing is not coming from pfSense.



  • Well our PF running version 2.4.4-RELEASE only appears to have SSL/TLS 1.0. I do not see any other version as an option.

    I thought it was our BitDefender Total Security on our laptops, but I also tried via our Windows 2012 and Windows 2008 management VMs, and they both have this issue, so also IE on Windows 2008 is impacted by this issue.


  • Rebel Alliance Developer Netgate

    Then check closer, because it isn't coming from pfSense.

    Look in /var/etc/nginx-webConfigurator.conf if you don't believe me.



  • @jimp said in SSL_ERROR_NO_CYPHER_OVERLAP when trying to connect to webgui:

    Either your connection is being redirected to some other web server (NAT rules/reflection, perhaps) or something else is taking over the GUI port.

    Could also be AV software on the client device or a proxy doing a bad job at MITM.



  • @jimp said in SSL_ERROR_NO_CYPHER_OVERLAP when trying to connect to webgui:

    /var/etc/nginx-webConfigurator.conf

    Just checked /var/etc/nginx-webConfigurator.conf on one of the 4 PF Appliances, it appears that it ONLY set up for HTTP even though we have HTTPS enabled right now, so something is not updating the actual configuration files when changes are made in the GUI. So this might be some other issue, that is adding to this mess.

    server {
    listen 80;
    listen [::]:80;
    However the GUI says HTTPS is enabled on port 443, so I am expecting that it should be listening on port 443, but the file is not reflecting this change, and yes, I did commit the change in the gui, and restart webConfiguratior via SSH.

    Also tried the same process on another Appliance and getting the same thing. So wonder if some update script within the CGI of the gui is broke? maybe?

    We might be in need of a rebuild I am thinking....sigh


  • Rebel Alliance Developer Netgate

    Are you sure there isn't another block in there? It will have port 80 declared if you have the redirect on that sends users from 80->443



  • @grimson

    We are using two management VMs, which have nothing but Windows Defender (and it is turned OFF, and NO Windows Firewall.) to rule out AV on the laptops. We are still seeing HTTPS issues, but as said with @jimp above, we are also seeing that configurations files are differing than what the GUI is reporting.


  • Rebel Alliance Developer Netgate

    Also if you want to bump it, use options 16 then 11 from the ssh/console shell and that will force it to reconfigure the GUI and PHP.



  • Just tried that, and I now can confirm that /var/etc/nginx-webConfigurator.conf is not being updated....the files time stamp has not changed since 10/1/2018, and I JUST made changes today via the GUI so the time stamp should have changed if it was touched by a CGI script or manually....so I think something is broke in our appliances.

    This is the entire file.....nothing with port 443, even though the GUI says port 443 is being used.

    nginx configuration file

    pid /var/run/nginx-webConfigurator.pid;

    user root wheel;
    worker_processes 2;
    error_log syslog:server=unix:/var/run/log,facility=local5;

    events {
    worker_connections 1024;
    }

    http {
    include /usr/local/etc/nginx/mime.types;
    default_type application/octet-stream;
    add_header X-Frame-Options SAMEORIGIN;
    server_tokens off;

        sendfile        on;
    
        access_log      syslog:server=unix:/var/run/log,facility=local5 combined;
        keepalive_timeout 75;
    
        server {
                listen 80;
                listen [::]:80;
    
                client_max_body_size 200m;
    
                gzip on;
                gzip_types text/plain text/css text/javascript application/x-javascript text/xml application/xml application/xml+rss application/json;
    
                root "/usr/local/www/";
                location / {
                        index  index.php index.html index.htm;
                }
                location ~ \.inc$ {
                        deny all;
                        return 403;
                }
                location ~ \.php$ {
                        try_files $uri =404; #  This line closes a potential security hole
                        # ensuring users can't execute uploaded files
                        # see: http://forum.nginx.org/read.php?2,88845,page=3
                        fastcgi_pass   unix:/var/run/php-fpm.socket;
                        fastcgi_index  index.php;
                        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
                        # Fix httpoxy - https://httpoxy.org/#fix-now
                        fastcgi_param  HTTP_PROXY  "";
                        fastcgi_read_timeout 180;
                        include        /usr/local/etc/nginx/fastcgi_params;
                }
                location ~ (^/status$) {
                        allow 127.0.0.1;
                        deny all;
                        fastcgi_pass   unix:/var/run/php-fpm.socket;
                        fastcgi_index  index.php;
                        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
                        # Fix httpoxy - https://httpoxy.org/#fix-now
                        fastcgi_param  HTTP_PROXY  "";
                        fastcgi_read_timeout 360;
                        include        /usr/local/etc/nginx/fastcgi_params;
                }
        }
    

    }


  • Rebel Alliance Developer Netgate

    The formatting on that got messed up. Maybe try attaching it as a file.

    Also, what do you have in your config.xml for the GUI? It would be under <system> and then <webgui>.

    Would look something like this:

                    <webgui>
                            <protocol>https</protocol>
                            <loginautocomplete></loginautocomplete>
                            <ssl-certref>5b7777344d771</ssl-certref>
                            <dashboardcolumns>2</dashboardcolumns>
                            <port></port>
                            <max_procs>2</max_procs>
                            <nodnsrebindcheck></nodnsrebindcheck>
                            <nohttpreferercheck></nohttpreferercheck>
                            <authmode>Google Cloud Secure LDAP</authmode>
                            <disablehttpredirect></disablehttpredirect>
                    </webgui>
    


  • Thanks all! I think at this point our PF Appliances are so messed up that it is pointless at this point to keep beating a dead horse. I am going to take down our secondary PF Appliances, and rebuild them, see if all works as it should, and if it does swing traffic to the the secondary, then rebuild the primary PF appliances. We only have 4 (2 Primary and 2 Secondary), so it shouldn't take to long, and I have backups of the configurations so that should speed up rebuilding.


  • Rebel Alliance Developer Netgate

    Well if you throw your hands up in the air when we're finally getting closer to finding out what's wrong, it'll never be fixed, if it does turn out to be a bug.

    I did find one issue that wouldn't have triggered a restart when toggling some of the checkboxes that need an nginx restart (like the GUI redirect), but it isn't quite what you are hitting.



  • Can't post our config.xml file as it errors on here as "Detected Spam" and won't post it.


  • Rebel Alliance Developer Netgate

    I can fix that, just need to spam the thumbs up on your posts so Akismet will pass you through.

    Also don't need the whole config.xml just the <webgui></webgui> tags and what's inside.


  • Rebel Alliance Developer Netgate

    Should be good to post now.


  • Rebel Alliance Developer Netgate

    Also, FYI, clicking Save on system_advanced_admin.php will not trigger a rewrite of the nginx configuration unless something changed that requires it. For example, changing the web server port, protocol, etc. So opening the page and clicking save won't help, but if you switch the port to something else (say, 4433) it would restart with the new settings, then you can change it back. But doing option 11 from the console should always rewrite the nginx config from the contents of config.xml and then restart the web server.



  • I have changed the port to 4433, switch from http to https and save : the webgui is accessible via https on port 4433, from there I have explicitly set the port to 443 and again : get error SSL_ERROR_NO_CYPHER_OVERLAP.

    I am staying on 4433 for now...


  • Rebel Alliance Developer Netgate

    @xenicle said in SSL_ERROR_NO_CYPHER_OVERLAP when trying to connect to webgui:

    I have changed the port to 4433, switch from http to https and save : the webgui is accessible via https on port 4433, from there I have explicitly set the port to 443 and again : get error SSL_ERROR_NO_CYPHER_OVERLAP.

    I am staying on 4433 for now...

    You must have port 443 taken over by some other daemon or NAT that isn't the GUI.