How Ciphersuites Work: TLS in Pieces

By Kellen 

The TLS handshake begins each HTTPS connection. The back-and-forth of the handshake is a negotiation between the client and the server. The negotiation is defined by different protocols that together make-up a ciphersuite. Knowing how to decipher what is within a ciphersuite is an essential part of understanding how TLS works behind the curtains.

Our goal is to make the inner-workings of TLS accessible to developers of all skill levels. This is part three of an ongoing series on Cryptography and how Fly serves Let's Encrypt TLS around the globe. This article stands well on its own, but for maximum joy we recommend rolling through the series from the beginning!

Part one: How We Delivery Global SSL with Let's Encrypt.

Part two: How RSA Works: TLS Foundations.

TLS: Transport Layer Security

The TLS handshake begins with asymmetric encryption, or public key encryption. Establishing TLS requires two keys, one public and one private. It would be tough on your servers to exchange keys over and over volley just to maintain a connection with a client. To remedy this, key exchange occurs only once, during the handshake. The handshake, then, forms a bond between client and server. The tangible representation of this bond is a shared key.


Once both the client and the server possess the shared key, then symmetrical encryption takes place; this is much less taxing on your servers than a constant cycle of key exchange after key exchange. In this way, an asymmetrical beginning leads to a symmetrical flow of encrypted information.

TLS is not one thing; it's a protocol that governs its own assembly and application. It's made up of many things and can be many different things. The client and server need to agree upon which ciphersuite to use; given that the TLS protocol, the key exchange method, the signing and verifying mechanism, and whatever is doing the hashing, is interchangleable, TLS can look many different ways.

The TLS protocol supports various methods for key exchange, signing and verifying keys, encrypting data, and confirming integrity. That's why when we look at an HTTPS connection within our browser we see differences in the ciphersuites...

A secure Fly connection looks like this:


We see a valid, trusted server certificate issued by Let's Encrypt Authority X3. We're adhering to TLS 1.2; ECDHE is our key exchange algorithm, ECDSA is signing and verifying our keys, and AES is providing encryption.

Comparison helps build context; the website of a most excellent hockey team reports the following:


Their certificate is a rather official sounding Symantec Class 3 Secure Server CA - G4. They adhere to TLS 1.2, use ECDHE for key exchange, RSA for signature and verification, and AES for encryption.

It's similar to Fly, but their servers are working harder to sign less efficient certificates. Fly applies ECDSA while the Edmonton Oilers apply RSA; in any event, the over-arching TLS protocol ensures that whatever pieces the client and server agree upon will result in a secure HTTPS connection.

Suite Life

Within our previous entry, part two, of our Cryptography/TLS series, we dove deep into RSA to better understand TLS and to compare it to ECDSA. We revealed that RSA and ECDSA are both used as digital signature algorithms. They are responsible for signing and verifying encryption and decryption keys.

RSA and ECDSA are part of a greater whole; the whole being a ciphersuite. When we consider the entire ciphersuite, we consider TLS. Not only do we need something to sign and verify the keys, we need protocols to exchange keys and facilitate encryption. To catalyze their encryption processes, servers look towards the client to inform them of which suite to use.

The client can pass in preferences regarding what sort of cryptographic ciphers it wants to apply. Within Fly, we issue one certificate that is signed using RSA and one signed using ECDSA. When we request the two certificates from Let's Encrypt, we generate both the private key and Certificate Signing Request locally. For this, we use the ACME client for Ruby. Our next step is sending the CSR in a call to Let's Encrypt, who then issues the certificate.

Do note that the communication with Let's Encrypt does not occur during the TLS handshake; the certificates are created, then later used within the handshake.

With both RSA and ECDSA certificates ready to respond to the client, if the client supports ECDSA then we'll try from our list of supported and known secure ciphersuites. If not, we'll fall back to RSA:

    for _, cipher := range helloInfo.CipherSuites {
        if cipher == tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ||
            cipher == tls.TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 ||
            cipher == tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 ||
            cipher == tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 ||
            cipher == tls.TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ||
            cipher == tls.TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA {
            cipherSupport = true

Within your terminal, you can query openssl to receive a list of ciphers:

$ openssl ciphers -v: ECDHE-ECDSA-AES256-SHA384 

TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256)  Mac=SHA384

To help us isolate and explore the various pieces, we'll dissect one of these ciphersuites: ECDHE-ECDSA-AES256-SHA384. We see that there are 4 different parts within TLS: ECDH, ECDSA, AES_256_GCM, and SHA384.

ECDHE/ECDSA - Signature, Verification, and Key Exchange

ECDHE stands for Elliptic Curve Diffie-Hellman Ephemeral. We recall that the purpose of Diffie-Hellman is to exchange a secret over an insecure channel; both sides build their own secret key from a value they received from the other participant: this is key exchange. It's the asymmetrical formula that establishes the symmetrical connection; keys into a shared key, becoming an encrypted stream. ECDHE does not sign or verify the keys, ECDSA or RSA does that.

Like ECDSA over RSA, instead of a discrete logarithm problem, ECDHE applies the elliptic curve algebraic structure over finite fields of integers to create difficulty. When compared to regular DHE, ECDHE is faster and provides more efficient performance, with a 224-bit elliptic curve providing about the same security as a logarithmic 2048-bit DHE key; the trade-offs are similar to those between ECDSA and RSA. ECDHE pairs with ECDSA during key exchange to cover signing and verifying, and key exchange.

There's another excellent feature that they unlock: Perfect Forward Secrecy.

Perfect Forward Secrecy

When something is described as ephemeral, it refers to its life-span. Today is a lovely day, but it's ephemeral. For optimal security, your keys are also ephemeral. We can imagine a case where the server were to apply the same public and private keys each time it wanted to generate a shared secret.

If an evil doer were to start recording all of your encrypted traffic, they would have all of your communications. Encrypted, yes, but they'd have them! In the event that they were to acquire the private key, they could decrypt the entire cache of data. Given that cracking the private key is possible - it just takes a really long time - one could keep hording transmissions until they were able to pick the lock!


ECDHE enables ephemeral keys during key exchange, activating Perfect Forward Security, or PFS. PFS uses a unique secret each time a secret key is generated; one secret per session. The only time the private key is available is the instant that it lives within memory -- if an evil doer were able to peak into your memory, well, you'd be hooped anyway!

If someone were to acquire the ephemeral private key, all it provides is access to one transmission, one flow based on one pre-shared key, instead of the whole flow of historical encrypted data. In this way, PFS is an essential part of ensuring that your communications are safe; the thief would have many, very hard locks to pick in order to access all of your secrets.

There is a case where you can have imperfect Forward Secrecy, known solely as Perfect Secrecy; this uses Elliptic Curve Diffie-Hellman or regular Diffie-Hellman. The private key is not ephemeral.

AES_256_GCM - Cipher

AES stands for Advanced Encryption Standard. AES is based upon a block cipher known as Rijndeal. It's secure and contains a low memory requirement; AES is effecient and faster than the HMAC-SHA-1 method it proceeded.

256 denotes the bit block strength of the cipher and GCM refers to its mode of operation. GCM, or Galois Counter Mode, is a mode which enables encryption, authentication, and confirmation of integrity, while Cipher Block Chaining, the alternative, only handles encryption. Within TLS, we want AES to inform the integrity of the cipher, therefore GCM is what you'll see in every ciphersuite containing AES. GCM is used only for verifying the integrity of the TLS handshake message.

We'd be well into the weeds if we dove into the guts of how AES works; our take away will be that AES is the most common method for the actual encryption taking place within a TLS connection. If you'd like to explore AES in-depth, then this article will be an interesting read for you!

SHA384: Integrity Check

At the tail end of the ciphersuite we have a Secure Hash Algorithm -- SHA. When you examine the TLS handshake, there are messages exchanged between the client and server to signify different things have happened: ClientHello, ServerHello, Finished.

So that you don't ever have data traveling in its expected form, the data is hashed. That way, you have an encrypted message and hashed transmission messages. The function that does the hashing is mentioned at the end of the suite, in this case it's SHA384.

In previous iterations of TLS, 1.0 and 1.1, even back to SSL 3.0, a Pseudorandom Function (PRF) was used to take the shared secret from key exchange and extend it into symmetric keys. Now that TLS has evolved in 1.2 and onwards, these functions are handled by different parts of the ciphersuite. In practical terms, this means AES-256-GCM uses SHA-384 to create hashes.

All of these parts together assemble into one mighty defender of the galaxy, or, well, a formidable defender of encrypted information, anyway. But just how formidable?


Are They Secret?!

Ciphersuites appear to be reliable, secure, and robust. If the most recent cyber security intelligence leak taught us something positive, it's that hyper-intelligent operators are by-passing well refined cryptographic ciphersuites like those within TLS. Instead, they swindle clients and steal private keys, exploiting zero days in things like keyboards, browsers, operating systems, utilities, or firmware.

It's good to remember that if an entity wants to infiltrate a system and they're of reasonable sophistication, then they will infiltrate the system. However, the door into your secret communications will likely not appear due to someone cracking an algorithm inside a well established ciphersuite; unless, of course, it's been poorly implemented.



Our TLS series started by showing you how we use Redis to apply Let's Encrypt TLS certificates across our global network. In part two, we went deep into RSA to lay a strong foundation for TLS, then compared RSA's signing and verifying abilities to that of the more modern ECDSA. Within this article we broke down a ciphersuite, examining each part. Putting them all together we now have a pretty good understanding of what everything within a TLS ciphersuite is up to.

What we're still missing is the full practical application. Within the next entry, we'll unearth another mysterious facet of TLS: the handshake.