Dec 16, 2019

How To Disable Weak CBC SSL Ciphers in Nginx

I'm always looking for ways to improve my encryption settings on my personal email server. I'm constantly checking SSL Labs to see how my configuration stacks up. For a little while now they have been complaining that I use weak CBC ciphers still in TLS 1.2. However, since they have continued to give me an A+ rating I didn't really care until today.

I decided to fix it by disabling those ciphers, and it's actually pretty easy. The answer on how to do it comes from user imgx64 on Stack Exchange in this thread where he says all you have to do is add a couple of extra items near the end of your ssl_ciphers portion of your ssl.tmpl config file in Nginx:
You can use !SHA1:!SHA256:!SHA384 to disable all CBC mode ciphers. There are some non-CBC false positives that will also be disabled (RC4, NULL), but you probably also want to disable them anyway. 
Note that while GCM and CHACHA20 ciphers have SHA* in their name, they're not disabled because they use their own MAC algorithm. The SHA* in their name is for the PRF, not the MAC
I changed my ssl_ciphers string from:

ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:!DSS:!aNULL;


To:

ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:!SHA1:!SHA256:!SHA384:!DSS:!aNULL;

After I made that change and restarted the Nginx service my SSL Labs report went from this:



To:


Simple right? Did this help you out? Let us know in the comments!

Dec 4, 2019

SSL Labs Error: Chain Issues Incorrect order, Contains anchor

An issue came up the other day that frankly really isn't an issue. We had a client at my day job (that shall not be named) that ran an SSL Labs test against one of our sites and it came back with this message regarding the chain certificates:

Chain Issues Incorrect order, Contains anchor
I say this really isn't an issue because according to this forum thread from Qualsis, it really is just informational. Ivan Ristic said:
...It's not an issue in the sense that the anchor is not allowed, but that the extra certificate (which serves no purpose) is increasing the handshake latency. Some people care about that, which is why provide the information in the test.
The solution is relatively easy if you are running an Nginx or Apache server, just don't include the root (aka anchor) certificate in your web configs, and only include the intermediate cert.

My problem was a little more complex because we use Imperva's Incapsula CDN/WAF service, so in order to upload a custom certificate you need to import a PFX file. If you export the PFX file from a Windows server, it typically includes all certificates in the chain.

If you opt to not include all certificates in the chain when exporting, then import that to Incapsula, then SSL Labs will cap your grade to a B because you are missing the chain certs... Kind of no win theater situation.

The solution? First you need to have OpenSSL installed in Windows, or you can do this on a Linux box. Do the following:
  • Export your certificate to PFX format and don't include the chain certificates. 
  • Export your intermediate certificate in x509 format separately. Name the file intermediate.cer
  • Put both files in a folder then run the following from a command prompt or Linux terminal in the directory containing your files:
openssl pkcs12 -in <domainname>.pfx -clcerts -nokeys -out <domainname>.crt
openssl pkcs12 -in <domainname>.pfx -nocerts -nodes -out <domainname>.key
openssl pkcs12 -export -out <domainname>_new.pfx -inkey <domainname>.key -in <domainname>.crt -certfile intermediate.cer

Be sure to replace <domainname> with whatever your original PFX file's name. You will be prompted for your export password after each command.

After this is done, you can import your <domainname>_new.pfx file to Imperva's Incapsula service (Or whatever load balancer/SSL offload device your using) and re-run your SSL Labs scan. Boom! The issue will be gone!


Like I said above, all of this is kind of unnecessary. Your website will work fine and not be any less secure if you have the root/anchor certificate in your chain. Still, if you are a stickler for details, or you have clients that want it done, now you know how to do it.

Did you have to do something different to fix your issue? Did this help? Let us know in the comments!



Twitter Delicious Facebook Digg Stumbleupon Favorites More

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | stopping spam