Sign up to the Arctiq Newsletter to stay up to date on the latest blogs, events and news
Subscribe to Newsletter
An outlined icon of an X
left arrow icon
Back to Blogs
September 29, 2020
Marek Anderson

SSL and TLS Certificates, Cipher Suites, and Security

Protecting web sites is one of the major applications for digital (SSL/TLS) certificates. Webmasters want the visitors to feel and be secure. They also want to protect their infrastructure from malicious activity. Certificates can protect the client-server communication over an insecure network, and also protect other applications that are not necessarily websites on different TCP ports.

This blog is intended as a brief overview of different standards, attacks, and recommendations where sensible.

Let us start by reviewing some of the well-known attacks:

Attacks on SSL and TLS in the past

A fair assumption from a security stance could be that the more recent the security standard, the higher the protection. Conversely, the older the standard, the more it should be avoided due to (now) well-known exploits or cryptographical/mathematical weaknesses.

Here are some known exploits in no particular order:

  • Heartbleed 2014. A critical vulnerability in the heartbeat extension of the popular OpenSSL library. This one was arguably particularly bad because it was a bug in the OpenSSL implementation of the TLS heartbeat extension RFC6520. Due to the library's predominant use at the time, the bug affected nearly every organization worldwide.
  • BREACH 2013. BREACH is short for Browser Reconnaissance & Exfiltration via Adaptive Compression of Hypertext.
  • CRIME 2012.
    "The TLS protocol 1.2 and earlier, as used in Mozilla Firefox, Google Chrome, Qt, and other products, can encrypt compressed data without properly obfuscating the length of the unencrypted data, which allows man-in-the-middle attackers to obtain plaintext HTTP headers by observing length differences during a series of guesses in which a string in an HTTP request potentially matches an unknown string in an HTTP header, aka a "CRIME" attack." - NIST, 2012.
  • DROWN 2016. DROWN stands for Decrypting RSA with Obsolete and Weakened eNcryption.
    "DROWN is a serious vulnerability that affects HTTPS and other services that rely on SSL and TLS, some of the essential cryptographic protocols for Internet security. These protocols allow everyone on the Internet to browse the web, use email, shop online, and send instant messages without third-parties being able to read the communication."
  • POODLE 2014. POODLE is short for Padding Oracle On Downgraded Legacy Encryption.
  • FREAK 2015. FREAK is short for Factoring RSA Export Keys.
  • BEAST 2011. BEAST stands for Browser Exploit Against SSL/TLS.

While together they may sound like a roster of punk rock songs, or code names for military operations, most of them are a clever abbreviation for the underlying exploit.

If you are interested in reading more about each exploit listed above, and its prevention, read through the additional reading material (see page bottom).

What's that? I know, right? The list above is rather long and depressing. If that list makes you feel queasy and you desperately need a good laugh right now, {% include image name="muttley.jpg" position="center" size="S" alt="kafka" %}

then I highly recommend reading Marco Peereboom's OpenSSL is written by monkeys. Granted, that article's author reflected on an older version of OpenSSL, and since then, many developers put in a tremendous effort to improve the codebase by leaps and bounds.

What now?

Okay, so what now with all those attacks? Let's imagine an eager DevSecOps team wants to enforce TLS 1.3 and forbid anything that is older / more vulnerable.

Let's do a reality check first:

  • Working in a large environment?
  • Working in a complex environment?

It turns out the DevSecOps team works in a large and complex environment with many different application stacks, including legacy ones. Sound familiar? {% capture string_with_newlines %} You guessed it, at best, the older application stacks support TLS 1.2 at maximum. sigh By the way, TLS 1.2 was defined in 2008! Yep, you read that right. That is 12 years ago. {% endcapture %} {{ string_with_newlines | newline_to_br }}

Find out in the next section on how to improve security with TLS 1.2.

Reduce Your Allowed Cipher Suites with TLS 1.2

When it is possible to enforce TLS >= 1.2, it is recommended to define and limit the allowed Cipher Suites explicitly. Without trimming down the permitted Cipher Suites list, you would end up with around 37 allowed ones!

Here is your Reader's Digest version of what Cipher Suites entail:

It is a combination of algorithms that help negotiate security settings in the SSL/TLS handshake steps.

Each Cipher suite is a named combination of:

  • Key Exchange Algorithms (RSA, DH, ECDH, DHE, ECDHE, PSK)
  • Authentication/Digital Signature Algorithm (RSA, ECDSA, DSA)
  • Bulk Encryption Algorithms (AES, CHACHA20, Camellia, ARIA)
  • Message Authentication Code Algorithms (SHA-256, POLY1305)

* Plain Diffie-Hellman (DH) is deprecated in TLS 1.3, so is Elliptic Curve Diffie-Hellman (ECDH). Also, the Digital Signature Algorithm (DSA) was removed entirely.

Below is an example of a complete Cipher Suite notation.

By default, the list of allowed Cipher Suites with TLS 1.2 features around 37 different Cipher Suites, including ones that are not considered secure anymore. Side note: Time flies! TLS 1.2 has been around for about 12 years. In those 12 years, the cryptography and software development community has learned a lot about improving security moving forward.

Here is a reduced list of recommended Cipher Suites. Please note that better, more secure recommendations may be available by the time you read this article. Notice that the Cipher Suites below all use ECDHE as the Key Exchange Algorithm. This feature is called Perfect Forward Secrecy (PFS). It is a concept in TLS that ensures that even when attackers manage to gain access to the private key of a certificate, they cannot decrypt previous communication, or communication in the future, without using active man-in-the-middle attacks.


Another consideration when choosing your defined list of Cipher Suites is the compatibility with operating systems and older versions of web browsers. Still have to support Windows XP? If so, your selection will have to consider that. For more information, see the references at the bottom—especially the two hyperlinks to Mozilla's wiki and the Mozilla SSL Configuration Generator.

And what about TLS 1.3 and Cipher Suites? Continue reading the next section.

Security in TLS 1.3

The most recent TLS 1.3 standard has increased the security posture by a lot. It was proposed in August 2018. Here are some of the benefits of this standard.

TLS 1.3 eliminates:

  • SSL Compression
  • Static key exchange functions
  • Block ciphers (CBC)
  • Non-AEAD ciphers (MAC-then-Encrypt)
  • Renegotiation of encryption parameters

TLS 1.3 dropped support for older, vulnerable ciphers:

  • RC4 (Ron's Code 4 or Rivest Cipher 4, invented by RSA's Ron Rivest)
  • DSA (Digital Signature Algorithm)
  • MD5 (Message-Digest)
  • SHA1 (Secure Hash Algorithm 1)
  • Weak Elliptic Curves
  • RSA Key Exchange
  • Static Diffie-Hellman (DH, ECDH)

These lists give you an idea by how much the standard was tightened and, therefore, stricter by allowing fewer parameters and cryptographic concepts. Similarly, the Cipher Suites were revised. The RFC8446 has a dedicated section named Mandatory-to-Implement Cipher Suites. Here is an excerpt:

A TLS-compliant application MUST implement the TLS_AES_128_GCM_SHA256 [GCM] cipher suite and SHOULD implement the TLS_AES_256_GCM_SHA384 [GCM] and TLS_CHACHA20_POLY1305_SHA256 [RFC8439] cipher suites (see Appendix B.4).

Another great improvement over the older standards!

Conclusion (tl;dr)

Whenever possible, enforce TLS 1.3 and deny anything older. If that is not possible, improve your security posture with TLS 1.2 and a reduced Cipher Suite list.

//take the first step

Further Reading Material

Related Posts