Weak ciphers are an early indicator of an organization’s vulnerability management program maturity. If your services are exposed to the Internet, anyone can easily assess the encryption and cipher strength of that exposed service.
Often, I am asked to evaluate cyber risk associated with cloud services. As part of that evaluation, I typically look at the company and product website security posture. I review the SSL certificate, SSL protocols and cipher suites. While not always the case, very often, the presence of externally visible weak and deprecated ciphers and protocols are the result of a very immature vulnerability management program or worse, an ineffective information security program.
While this post won’t fix your vulnerability management program deficiencies, it will give you the skills to shore up and harden your external facing services. If you need help getting started or maturing your vulnerability management program, CastleLock has decades of experience, building vulnerability management programs, addressing vulnerabilities and accelerating remediation.
Now let’s get to hardening our SSL ciphers and protocols. For this post, I will focus on secure websites running Openssl and Apache2 as the underlying software. While we’re focused on a website, the techniques and tools you learn to use in this post can be applied to most encryption services.
In order to get to this point, your organization has recognized the need to encrypt their internal or externally exposed service. The SSL certificate has been purchased, validated, signed, and installed. The site renders properly, users get the picture of a lock in their URL.
Well, not quite. Congrats on getting the SSL certificate installed but we still have work to do.
Now that the SSL certificate is installed, we need to check which protocols and which ciphers are listening. There are a couple of great free tools available for this. One very easy to use tool, I personally use a lot, is the SSL Server Test by Qualys at https://SSLLabs.com/ssltest. Qualys has packed quite a few security and vulnerability checks into this analyzer, and when complete the tool renders a letter grade score. Don’t worry, these checks won’t impact your site. Qualys also provides guidance to get your grade up, but sometimes it’s not always clear. If you are worried that your site may have a bad grade be careful to check the “Do not show the results on the boards” checkbox. Qualys displays some of the most recent scans on the home page and that may be embarrassing if you don’t get a good score!
An example of the scoring below:
Because the Qualys SSL site analyzer is a free tool, you don’t own your results and they could be displayed for the world to see. If using the Qualys SSL site analyzer is too much of an invasion of privacy for you, or your service is not exposed to the Internet, you may want to take a look at Nmap Security Scanner.
Note: Qualys also offers an Application Programming Interface (API.) If you are a provider or responsible for running multiple websites take a look at using the API to schedule an assessment across all of your sites and continuously monitor them for vulnerabilities. Better that you find vulnerabilities before an attacker or your customers!
Unselfishly written by Gordon Lyon (Fyordor,) the Nmap Security Scanner is a versatile opensource tool I have used for decades. Every time I use it, I get to stand on the shoulders of greatness. Thank you, Fyoder. While, many know of this tool as a port scanner, one of the many capabilities of this tool is the ability to run targeted host checks through the use of scripting language. To check our secure site protocols and ciphers, we will use the script “ssl-enum-ciphers.” That’s right! This bad boy will take a peek at your Internet or internal facing services and let you know which protocols and cipher suites are listening. This tool also gives you a letter grade, but for each cipher rather than the security posture of the whole site. Take a look at the command syntax and the output below. If you are not confident on the command line, Nmap also has a gui, Zenmap.
$ nmap –script ssl-enum-ciphers -p 443 castlelock.com
PORT STATE SERVICE
443/tcp open https
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) – A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) – A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (ecdh_x25519) – A
| TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (ecdh_x25519) – A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) – A
| TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (ecdh_x25519) – A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) – A
| TLS_ECDHE_RSA_WITH_ARIA_256_GCM_SHA384 (ecdh_x25519) – A
| TLS_ECDHE_RSA_WITH_ARIA_128_GCM_SHA256 (ecdh_x25519) – A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) – A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) – A
| cipher preference: server
|_ least strength: A
Now that we’ve gone over my favorite discovery tools and their outputs, let’s take a look at hardening our SSL and TLS protocols. The best way to secure the SSL protocol is to turn the oldest versions off. That’s right! No SSL 2.0 or SSL 3.0 should be turned on any Internet facing server. After SSL 3.0 was released future revisions of the protocol were referred to as TLS. TLS 1.0, TLS 1.1, TLS 1.2 and TLS 1.3. Currently it is recommend to disable TLS 1.0 and TLS 1.1 and only allow connections using TLS 1.2 and TLS 1.3. In an Apache server, this directive looks like this.
“SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1”
Each SSL protocol engages cipher suites to complete the encryption process and send your data securely across the Internet. Some of these suites like the protocols above have vulnerabilities or don’t provide the needed encryption strength. These are known as “weak” ciphers. OpenSSL has some baked in directives to refer to weak ciphers, like LOW, MEDIUM, HIGH. More directives listed here. https://www.openssl.org/docs/man1.0.2/man1/ciphers.html The following syntax enables high encryption cipher suites and disables null, low, weak and vulnerable cipher suites.
SSLCipherSuite “EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !EDH !RC4”
These two configuration lines return the results from Nmap and SSLLabs above. Easy A.
Oh yeah one last note, remember when I said it’s not usually a difficult thing to fix? While focused earlier on OpenSSL and Apache, sometimes the load balancer(s) that are handling SSL termination can be the culprit, the same principles apply to those as well. Remove old protocols and update your ciphers!
If older appliances are holding you back, by not supporting newer protocols or ciphers, this also should be part of your vulnerability management program. Also, consider your partners API’s that may require you to accept older protocols or ciphers for post backs or integrations. Working with them to eliminate vulnerabilities can be an important part of your risk management program! It’s not just the risk of public perception, new and serious vulnerabilities like Heartbleed attacks could you leave your organization stuck without an easy path forward.