An Introduction To Cipher Suites

The security of any SSL/TLS-protected connection largely depends on the client and server’s choice of cipher suites. But what are cipher suites? If you use file transfer protocols like HTTPS, FTPS, and AS2 but don’t know what cipher suites are, you will want to read this post and learn how to use a cipher.

Basic Elements of a SSL/TSL Cipher Suite

The definition of a cipher suite is basically a complete set of methods (technically known as algorithms) needed to secure a network connection through SSL (Secure Sockets Layer) / TLS (Transport Layer Security). The name of each set is representative of the specific algorithms comprising it.

We’ll show you how these names look like in a short while. In the meantime, let’s talk about the algorithms that make up a SSL/TSL cipher suite. The algorithms that make up a typical cipher suite are the following:

• key exchange algorithm – dictates the manner by which symmetric keys will be exchanged;
• authentication algorithm – dictates how server authentication and (if needed) client authentication will be carried out.
• bulk encryption algorithm – dictates which symmetric key algorithm will be used to encrypt the actual data; and
• Message Authentication Code (MAC) algorithm – dictates the method the connection will use to carry out data integrity checks.

To be clear, one cipher suite typically consists of one (1) key exchange, 1 authentication, 1 bulk encryption, and 1 MAC algorithm. If you’re not familiar with what these algorithms do, I suggest you open those links above in a new browser tabs and read them later.

Some key exchange algorithms: RSA, DH, ECDH, ECDHE;

Some authentication algorithms: RSA, DSA, ECDSA;

Some bulk encryption algorithms: AES, 3DES, CAMELLIA;

Some MAC algorithms: SHA, MD5

Here’s an example of a typical cipher suite:

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

Let’s break that down.

• TLS simply indicates the protocol;
• ECDHE signifies the key exchange algorithm;
• ECDSA signifies the authentication algorithm;
• AES_256_CBC indicates the bulk encryption algorithm; and
• SHA384 indicates the MAC algorithm.

AES_256_CBC means that this cipher suite specifically uses 256-bit AES operating in CBC (cipher block chaining) mode.

Similarly, SHA384 means the cipher suite is employing a specific version of the Secure Hash Algorithm (SHA).

Sometimes, the protocol is simply omitted. Here’s an example:

DHE_RSA_AES256_SHA

Again, breaking that down, we have:

• DHE – the key exchange algorithm;
• RSA – the authentication algorithm;
• AES256 – the bulk encryption algorithm; and
• SHA – the MAC algorithm

Sometimes, algorithms are implied. For example, in the cipher suite RSA_AES256_SHA, the authorization algorithm (RSA) is implied.

Would you like to know what ciphers suites are supported by your browser? Head on to

BrowserLeaks SSL Test

or

Qualys SSL Client Test

for a quick practicum of what you’ve learned so far. The second site will even highlight which cipher suites are considered weak, i.e., have known vulnerabilities that can be exploited using existing tools and computing power.

As you can see, your browser supports a rather large selection of cipher suites. The server it’s connecting to would normally have it’s own selection as well.

Here’s a screenshot showing some of the cipher suites supported by JSCAPE MFT Server, a managed file transfer server that supports FTPS, HTTPS, WebDAVS, and other secure file transfer protocols:

Where SSL/TSL cipher suites are used

Cipher suites are used in network connections secured by SSL/TLS. That means, network protocols like HTTPS, FTPS, WebDAVS, AS2, POP3, IMAP, and SMTP, all use cipher suites.

Before a client application and a server can exchange data over a SSL/TLS connection, these two parties need to agree first on a common set of algorithms to secure the connection. Yes, they’re the algorithms we were talking about earlier. If the two parties fail to reach an agreement, then a connection won’t be established.

The negotiation process takes place during what is commonly known as the SSL handshake. In the SSL handshake, the client begins by informing the server what cipher suites it supports. The cipher suites are usually arranged in order of security. The most secure cipher suite naturally becomes the first choice.

The server then compares those cipher suites with the cipher suites that are enabled on its side. As soon as it finds a match, it then informs the client, and the chosen cipher suite’s algorithms are called into play.

Choosing cipher suites

Your choice of cipher suites can spell the difference between having a secure connection and one that can be exploited. In order to avoid certain attacks, you will have to disable some cipher suites.

For example, in order to avoid the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack, you will want to disable all cipher suites that use SSLv3. Or, if you want to prevent attackers from compromising your connection through the Logjam vulnerability, you will want to disable cipher suites that employ the Diffie-Hellman key exchange.

Recommended read: SSL vs TLS – Know The Difference

The downside of disabling cipher suites is that it can cause compatibility issues. More specifically, it can prevent certain clients and servers from having matching cipher suites and establishing a connection. Since popular browsers like Chrome, Firefox, Safari, and Internet Explorer usually update their list of cipher suites after a vulnerability is discovered, it’s always best to advise users to install the latest browser patches.

That way, you’ll be able to reduce your users’ likelihood of encountering compatibility issues when, say, you disable weak cipher suites on the server side.

Get Started

Looking for a file transfer server that will allow you to transfer files via HTTPS, FTPS, and other secure file transfer protocols? Try the free, fully-functional Starter Edition of JSCAPE MFT Server now.

Frequently Asked Questions