I have a pretty good gig. I get to see the unique security approaches of dozens of companies every year. Sometimes the things we discuss come up so frequently, they should probably be shared...anonymously, of course.

Frequently, folks are tasked with fixing insecure transport security. This is often due to test results from:

• Introducing new test/scanning scope
• Changes in scanning techniques, tools, or vendors
• Supporting legacy applications or legacy connections
• Acquisition of applications

Unless you only support new applications with the latest, strongest ciphers and protocols, the list above describes almost everyone.

The intention of this blog is NOT to recommend a specific scanner or vendor or detail how to manage such relationships. It is simply to arm you with the basics to analyze your own transport security using an authoritative and objective source.

We will look at the protocols and cipher suites employed in the encryption. It should go without saying that if you have other issues like expired or compromised site certificates, encryption will not make up for that in securing the application.

Is My Web Application Strong?

Let’s say I have a cute little application I support, and let’s call it google.com. No big deal. Is it stronk?

By what authority do we deem it strong? It is always a good idea to use an authoritative, public standard where possible. The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-52 https://csrc.nist.gov/publications/detail/sp/800-52/rev-2/final provides such guidance.

Next, we need to test all transport protocols my application supports and to survey all of its supported cipher suites. Thorough scanning is needed, as inspecting my connection to the site might reveal only the most secure protocol and cipher suite that both my client and the application support. This does not reveal the weakest cases.

There are many free scanners. Scanning my application through ssllabs.com yields the results below. (Note: You can get much more information through the site than will be covered here.) When drilling down into one of the web servers, we get:

Scan Results: Summary

The overall rating is capped to a B due to supporting Transport Layer Security (TLS) versions 1.0 and 1.1, which are not considered strong cryptography by NIST SP 800-52. Does this mean Google is not strong? In this case, Google does some less secure and less sensitive interactions like public search results, which are supported on older devices that do not utilize the latest security protocols. Google does have more secure payment applications, but this application is more interesting to test thanks to the broad range of ciphers supported.

Let’s look at the test results for the cipher suites. Of the strong TLS versions 1.3 and 1.2, we have the following cipher suites:

Scan Results: Cipher Suites

The scanner shows all version 1.3 ciphers as strong, with nine (9) listed as WEAK. Are the WEAK ciphers at elevated risk of being compromised? This tool and many others don’t get into that level of analysis.

NIST SP 800-52 to the Rescue

While there is much that is interesting within NIST-800-52, we are skipping to section 3.3.1.1 Cipher Suites for TLS 1.2 and Earlier Versions.

First, let’s look at the bottom cipher suite identified in the screenshot above, TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa). What does WEAK mean? NIST says, 'Cipher suites that use the Triple Data Encryption Algorithm (TDEA, also written as 3DES) are no longer allowed due to the limited amounts of data that can be processed under a single key.'

The next cipher suite up, TLS_RSA_WITH_AES_256_CBC_SHA (0x35), NIST indicates is in a transition period and is not preferred.

Transition ciphers are older and less secure. For such cipher suites, this may be informative: Transitioning the Use of Cryptographic Algorithms and Key Lengths. (National Institute of Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 800-131A, Rev. 2. https://doi.org/10.6028/NIST.SP.800-131Ar2

Continuing to work our way up, TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) and others are also in transition.

The top-most WEAK one, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009), utilizes strong cryptography, according to NIST 800-52.

The broadest rules applicable for most applications include:

• Eliminate ciphers that support truly weak algorithms, e.g., 3DES.
• Plan to eliminate algorithms and key lengths that are in transition.
• Plan to eliminate weak protocols, e.g., TLS v1.0 and earlier.
• Do not implement new protocols or ciphers that are not strong.

For those who have to comply with PCI, read part 2 of this series for more details on PCI transport cryptography.