HTTPS Cipher Suites for Beginners

Last updated November, 2016
tags: SSL/TLS, ciphers, introduction, security

Computers have been doing cryptography for a long time—in some form or other, you could argue that that's what they were invented for, and they are very good at it. After half of a century of automation the math required to keep up is understandably a bit dense, so this article is going to be a little light on the equations and focus more on helping you make sense of HTTPS' recommended SSL/TLS configuration settings.

The main recurring theme is that there are some good standards to stick with, and the few trade-offs available focus on security needs, performance, and your target clients. (Skip ahead if you just want the recommendations.)

A note to the reader: We haven't included a great deal of legacy options since they are more historical curiosities than useful modern cipher configurations (eg. MD5).

Finally, TLS1.3 is expect to debut in 2017 and comes with some pretty heavy changes; we'll discuss some of these where appropriate, but for the most part these ciphers are used in TLS1.2 and earlier.



What a cipher looks like

The cipher suites themselves can all be found listed at the IANA's TLS Cipher Suite Registry. When configuring your web server, it is the description value that will be of the most interest to you (eg. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256). The value (eg. 0xC0,0x31) is used during the actual handshake as one of the byte fields and shouldn't really concern you unless you are writing a scanner. (You may also find cipher suites listed in the RFCs for various TLS versions.)

Cipher Suite descriptions in IANA formats can pretty easily be transfered over to OpenSSL-style descriptions by dropping the TLS, the WITH, and swaping the _ for - (eg. ECDH-RSA-AES128-GCM-SHA256). OpenSSL is likely the format you'll need for your web server if you are using Nginx or Apache. Learning how to use the openssl ciphers command will help you find the suites you might be interested in, though note that in OpenSSL, if key exchange or authentication is omitted RSA is typically assumed.

First up in the cipher suite is the key exchange and authentication algorithms. The popular ECDHE-RSA combination is a good examle; it instructs the server to use elliptic-curve Diffie-Hellman with ephemeral keys, and to authenticate using RSA-signed certificates (more on all of that below). This is the part of the suite used to setup the secret key that will be used during the conversation.

Next the middle section of the suite describes the cipher used to encrypt your traffic. AES is a pretty standard choice with no known practical attack as of the time of the Snowden leaks, though CHACHA20 is an important stream cipher that Google has been putting it's weight behind, and which we will also see more on below.

Finally comes the hash algorithm (eg. SHA256), used to validate data integrity. The specific hash will in some part be dependent on the cipher you have chosen, or not be necessary at all if the cipher includes equivalent checks as part of it's algorithm.

The TLS handshake

Dramatis Personae: Client, a humble laptop alone in the world, Server, a slavish sibling from a large family, with a secret to tell, in fair Verona, where we lay our scene.

As a quick reminder and reference point, in a secure connection a client connects to a server via a standard TCP handshake, thusly...

Client: "Hark, can you hear me?", Server: "Ho! Indeed. Canst thou hear us?", Client: "Most clearly!"

After the TCP handshake, the client will initiate a TLS handshake where it will negotiate which cipher suite to use among the many it supports, authenticate the identity of the server, and then establish the cryptographic key to use going forward.

Client: "I desire a private word; speak you Elder, Elvish, or Klingon?", Server: "Our Klingon is fair; here are our credentials.", Client: "Excellent! My secret key information is 'pegh'", Server: "Qapla'"

The TLS handshake must complete before any actual application request can be made (eg. HTTP GET), and adds two additional round trips between the client and server. Extra trips do course slow the time-to-first-byte, but are really a very small price to pay to get secure, private, and authenticated communication.

Client: [Klingon gibberish]

The first round trip consists of the client sending a "client hello" with it's cryptographic information (mostly the suites it supports), and the server responding with a "server hello", which consists of it's preferred suite from among those offered by the client, and also its Public Authentication (RSA or DSA, but probably RSA).

After verifying the certificate the client knows which suite to use and can begin the key exchange, which if successful results in a shared symmetric key. This key will be used by the cipher algorithm for the packets going across the wire with application requests. The client sends the encrypted secret key, and usually also a "client finished" message. The server dutifully replies with a "server finished" message and the session can get underway.

TLS1.3, False Start, and Fast Open

Upcoming improvements in TLS, along with some other clever tricks, can reduce the TLS handshake down from three round trips to one or none. Look for these improvements to ship with TLS1.3, which we expect to roll out closer to summer 2017. (Evergreen browsers may begin supporting it sooner.)

Check out our intro TLS Gets An Upgrade for details.

Key Exchange

Likely the most interesting part of this whole process is the manner in which key exchange and authentication occur. Secure encryption is pretty much a solved problem once both parties share a secret; it's the sharing that makes things interesting. Sadly this isn't an introduction to public-key cryptography, so we'll really only be covering the main algorithms, their salient differences, and our recommendations.

The Key Exchange algorithms are the first unit of the cipher suite, and for web traffic are typically one of RSA, DH, DHE, or ECDHE.

Diffie-Hellman vs RSA


Both of these algorithms have interesting histories and particular uses. The two also have different technical applications but may both be used to exchange keys. RSA (Rivest, Shamir, Adleman) is kept secure by the power of integer factorization (eg. it's very efficient to multiply two prime numbers together, but cosmically slow to find the two primes of such a product, assuming large primes). The Diffie-Hellman (DH) algorithm is based on the power of the difficulty of discrete logarithms (AKA modular logs), and the exchange results in each party arriving at the same key independently without any listening third party being able to replicate it. Once either is complete, the resulting key is used in the message encryption algorithm.

NB. RSA contains two different algorithms based on the same principle; one for key exchange and one for authentication. We cover authentication below.

There are some interesting trade-offs between the two algorithms that are relevant in some edge cases, but to get right to it, DH has a killer feature that most modern implementations of RSA don't support, and for exchanging keys it makes it the preferred choice: Perfect Forward Secrecy (PFS).

TLS1.3 note: DH is used exclusively in TLS1.3, which helps speed up the handshake. Specifically, DHE.

Perfect Forward Secrecy (PFS)


PFS means that even if all of the traffic between you and your users were intercepted, and your servers were later breached and the private keys stolen, the attacker could still not decrypt the session. "Why not?" you surely ask. Because of the workings of the DH algorithm, a unique ephemeral key pair can be used for each session (hint, E at the end of all of the DHE cipher suites stands for ephemeral).

In theory, RSA could be used this way, but isn't in practice on most systems; DH is much faster at generating keys and so is preferred for this technique.

Does this seem paranoid to you? What kind of crazed attacker would store all of your network traffic in the hopes of decrypting it later? Who could possibly store such a volume of data? This particular defense is most squarely aimed at large-scale government surveillance programs, but your reasons for wanting to secure your traffic may vary.

Where Diffie-Hellman can Fail

Some very clever people (who may be found at WeakDH) figured out that DH has a rather interesting flaw: A great number of web servers are using the same popular 1024-bit prime numbers, which meant that an organization with a few million dollars lying around to dedicate to custom hardware could in a year construct the equivalent of the world's greatest rainbow table, allowing them to passively crack 18% of global HTTPS traffic. If they could crack the top 10 primes, that would yield 24% of the top one million sites for a passive listener, and 56% for an active attacker.

To evade this clever trick, it's necessary to generate your dhparam file carefully, like so:

openssl dhparam -out dhparams.pem 2048

Security scanning tools should be able to tell you if you are using DH values below 2048; Basic Tier includes such a scan.

Also, use elliptic curves.

Elliptic Curves


Diffie-Hellman may also be used with Elliptic Curve Cryptography (ECC), which allows the DH algorithm to do it's work with significantly smaller parameter values, meaning we can lower the time and space required to perform our calculations; and not just by a little. An EC-based DH exchange (ECDHE) compared to an RSA exchange with equivalent key length has orders of magnitude more security; inversely an ECDHE key of equivalent security can be computed nearly 10x as quickly, which lightens the CPU cost for your TLS termination.

Further in it's favor, the underlying mathematical problem powering elliptic curves (the Elliptic Curve Discrete Algorithm Problem for those wanting to know), has so far been more resilient to clever mathematicians than the factoring of large numbers, which powers RSA.

There is also the problem that as factoring becomes more efficient at scale, we will have to keep increasing the key sizes used in RSA, which ups the cost of use. In EC schemes, bumps in key length asymmetrically increases the security of the exchange in our favour (ie. it's easier for us to get more secure than for an attacker to get better at cracking our encryption). EC offers us a neat and quick way out of the RSA arms-race, and offers improved performance on lower-end devices (such as mobile and IoT).

For the paranoid and cautious, ECC's discrete logarithm function is admittedly much newer than the factorization problem in RSA, and as such has had a much smaller pool of mathematicians trying to crack it, historically speaking. Also, there is at least one documented attempt by the NSA to insert a cryptographic backdoor into the set of curves available under ECC. In fact the NSA went one step further, advising not to bother with Elliptic Curves and instead suggested that it would be best to stick with large-key RSA until the next generation of quantum-resistant algorithms are ready. Does the NSA know something we don't? Spolier: The linked PDF suggests that ECC is quite safe to use, in spite of the NSA.

If you are running an onion site, or anything involving human rights, you might want to think it over, but for the vast majority of us ECC is likely safer and faster.

If you'd like to dive in a bit on the math behind elliptic curves, Cloudflare has written an excellent intro to the subject.

A quick word on curves

In case you've skipped the above reading, elliptic curves are based on an actual geometric curve, just like the ones from high school math classes. Which curve is used is a parameter of the handshake, and is chosen from a standard set—that set is in turn decided by the National Institute of Standards and Technology, in cooperation with their good friends at the NSA. While the crypto community seems pretty confident that elliptic curves are mathematically sound, in theory a weak curve could contain a backdoor, as was the case with the Dual_EC_DRBG incident. (It should be pointed out that there is a rather good-faithed effort to make it impossible to tamper with the seed values of the curves in the standardization process, but security and paranoia go hand in hand.)

The good news is that you can configure the curves allowed in your web server: In Nginx, it's as simple as ssl_ecdh_curve prime256v1;. The bad news is that it can be tricky to keep up with the recommended curves. (For the record, MDN currently recommends prime256v1, secp384r1, and secp521r1.)


Exchanging keys is well and good, but how can you trust the party with whom you are communicating? What stops a random attacker from intercepting your web traffic and serving content on your domain over TLS? Authentication, of course.

Presumably you have either purchased a certificate from a Certificate Authority (CA) or have set yourself up with something like Let's Encrypt. In the vast majority of cases, you are likely using a 2048-bit RSA certificate.



Including DSS in that list is really SEO bait: Modern implementations use the ECDSA variant (Elliptic Curve Digital Signature Algorithm), but in case you see it, now you know why.

Which of these two authentication techniques you use will depend on the type of certificate you were issued by your CA. Few CAs currently support ECDSA certificates which has certainly been a factor in keeping RSA as king on the web for authentication. Conversely if you are targeting a wider public, RSA is much more likely to be supported by clients as well. If you have to maintain a large pool of legacy customers and user agents, you're likely going to have to continue to use RSA—or get clever with your web server and use ECDSA where supported, falling back to RSA depending on the user agent.

NB. While the web community has been slow on the pickup of ECDSA, Bitcoin has been a notable adopter, as have a slew of secure chat clients. Some of Apple's products also rely on it for authentication.

Message Encryption

AES, AESGCM, DES, 3DES, RC4, ChaCha20, ARIA, and Camellia

After a secret has been shared between the client and server, symmetric encryption takes over, which is much faster, and typically designed for this style of communication.

Of the encryption algorithms listed, don't use RC4, DES or 3DES. They are now considered insecure and we won't really say more than that here. See ChaCha20 for your RC4 needs.

Although ARIA and Camellia are excellent encryption protocols, there is pressure in the web community to standardize around fewer options rather than more, so most clients will not offer, and most servers will not accept either as a valid choice for message encryption. We include them here only for completion.


The Advanced Encryption Standard (AES) also known as Rijndael, is definitely the popular choice for this step. Thanks to Snowden, we know the NSA is still working to develop an attack for AES, which lets us suspect that at least at the time of the leaks it was unbroken.

NB. There actually are proven attacks against AES, but with even a 128-bit key size, these attacks would still take... well a very long time.

AES's popularity is such that most modern processors have dedicated hardware support for it, known as AESNI which makes it an easy pick for a prefered cipher, though there are some variants we have to point out.


Galois/Counter Mode (GCM) is an alternative to the older Cipher Block Chaining (CBC) mode, and describes an alternate way for the block cipher (AES in this case) to have it's output processed. GCM has two major advantages over CBC: First is that there is some extra security provided by GCM, and second is that it is potentially faster. (Also, GCM doubles up the encryption and message authentication duties, see below for more information.)

With regards to security, and for the curious, the xor performed in GCM is between two values unknown to an attacker, whereas in CBC, one of the values is the previous block's cipher text. (In CBC the result is then sent through the block cipher, not to worry.) CBC mode may also be vulnerable to certain timing attacks, whereas GCM, if implemented correctly in hardware, is not.

More interesting to many, GCM plays well with parallelization, whereas CBC inherently does not; of course, you need the hardware to support parallelization (which most modern web devices have); if you work in a more constrained environment GCM might actually slow you down—some mobile devices certainly fit this category. GCM may also be less than ideal if you work in the IoT space, but if you are at least reading about cipher suites we presume you are already ahead of the game and applaud you.


Counter with CBC-MAC (CCM) is an update to earlier CBC encryption, and brings along some of the benefits of GCM, however it cannot be parallelized and is not as widely used.

TLS1.3 note: GCM and CCM are supported by TLS1.3

AES128 and AES256

Another AES variation has to do with key size, and as with most of our discussion, this comes down to a performance versus security question. AES256 is undoubtedly much more secure than AES128 (except in certain special circumstances), however it is also up to 40% slower on hardware without special instruction sets (AESNI). But AES128 is also already really secure. So the question is again whether you are targeting a large mobile/IoT audience, or a modern desktop audience, and whether or not you need to go plaid. (AES192 is the middle child everyone forgets, and likely only exists for reasons of historical and political curiosity; either way, it's not supported in the TLS specifications.)


Given the need for improved performance to make HTTPS everywhere a reality, it should hardly be surprising that the likes of Google and Cloudflare have begun pushing a more efficient and less costly cipher. One important difference between ChaCha20 and AES is that the former is a stream cipher, while AES is a block cipher (ie. AES chunks up the data and encrypts the blocks, while ChaCha20 will take the stream of bytes and encrypts them on the fly; this is significantly faster than block ciphers when implemented in software, which is the common scenario on many phones and devices). TLS has lacked a major stream cipher since RC4 was declared insecure.

ChaCha20 (together with it's friend Poly1305 below) were introduced to fill that gap, and to offer a fast stream cipher for the mobile world (especially older Android devices, which make up the bulk of the global mobile device market). Read the introductory RFC here.

Message Authentication Code (MAC)

AEAD, SHA384, SHA256, SHA1, MD5, and Poly1305

Message authentication validates that our secure transmission has not been tampered with by malicious parties, or cosmic rays; this is typically done with a hash function, like MD5, but not MD5, because MD5 is not secure and you should never ever see it in your list of cipher suites.


First available in TLS1.2, and short for Authenticated Encryption with Associated Data, AEAD is a way of indicating that no MAC is required as the message encryption algorithm already contains an authentication component (such as with GCM above). However, those encryption methods will still use a hash function internally, so you often see this represented as ECDHE-RSA-AES128-GCM-SHA384. OpenSSL will label this suite as Mac=AEAD and Enc=AESGCM(128), meaning that SHA384 will actually be used by GCM internally.

TLS1.3 note: only AEAD ciphers are supported in TLS1.3


SHA384, SHA256

SHA384 and SHA256 are the two members of the SHA-2 family you'll see used for MAC in TLS. (SHA384 is actually just a conveniently truncated version of SHA512.)

Which to use again falls back to the question of whether you are targeting fast and modern clients, with 64-bit processors and plenty of bandwidth, or constrained clients, with... less. The interesting thing here is that the constrained client option (SHA256) actually runs more slowly than the modern client option (SHA384) on modern clients, so it's not as though it's strictly a security vs performance trade off; it's actually a question of knowing your user base and optimizing for performance.

The practical security difference between these two modes is negligible at this point.



Don't use this. Most browsers won't even accept it past 2017.



Introduced in RFC7539, the Poly1305 is the MAC to accompany the ChaCha20 streaming cipher algorithm. You don't really get much of a say which MAC you chose if you're using ChaCha20, so that's that. The good news is that ChaCha20 and Poly1305 are both designed to be easy to implement and to operate in constant time, which means fewer bugs and side-channel attacks. They also have the virtue of having helpful pseudo-code to read in their RFC.

Security Considerations

Where attacks happen

Mistakes have been made. We clearly would not be on TLS1.2 if all the versions before it got everything correct the first time. As a community, we have learned that there are common sources for security failures, and how to prepare for them.

Below are recommendations for preparing yourself to keep your configuration secure.

Failing to keep up to date

This is meant to be a living document; undoubtedly over the course of the next few years some of this information will become dangerously outdated, and we will strive to keep this document up to date as we go. (Note that if you subscribe to this resource, we will notify you of updates to the content). It is important to be notified when cipher suites become compromised. Mailing lists and twitter feeds are good sources, as are security sites (eg. Threat Post). Basic Tier itself is designed to serve as a monitoring suite for your cipher configuration, alerting you to changes to your configuration during development, as well as keeping updating our alerts as new exploits and best practices become available.

Whatever else, setting up your TLS server is not a fire-and-forget activity; web servers tend to be long lived and only periodically reconfigured, making them vulnerable to human inattention.

Software Misconfiguration

Believe it or not, the math is usually not the weak part of cryptography; more often the implementation in software or hardware violates some assumption of the math, or just plain misses some edge-cases with the underlying data primitives (it helps to know the guts of your language if you're writing crypto).

Usually when these bugs are detected, a CVE goes out to notify the world. Subscribing to a good CVE mailing list is pretty important for catching these; most OSs will maintain such a list (eg. the ubuntu-security-announce list) which will come right to your inbox with CVE's relevant to your distro.

If you are using Docker, many of the registries with commercial support will also scan your container images for CVE violations, letting you know of the precise CVEs you are susceptible to which helps cut down on the spam and noise from a general CVE.

Probably the NSA

In all honesty, three-letter agencies have many other, easier ways of cracking your server's security than breaking TLS, so if this is really your main fear, you probably have other things to worry about. Should this bother the average web security admin? Probably not. If it bothers you, let us know! We will happily build you a custom thermite-tamper-trip-case for your servers. Seriously, tweet us!


Of course, Mozilla maintains a great general TLS cipher suite configuration generator, and you should definitely refer to it here. Below are some more specific considerations based on all the conditions we have covered.

For the Paranoid

Congratulations on your new dark web, whistleblower, human-rights, and/or torrent site. Odds are you should be worried about one three-letter agency or another. We will stick to AEAD suites, and the CHACHA20 streamer to avoid side-channel attacks. The question you now have to ask is which camp of paranoid you fall into.

You believe that elliptic curve cryptography is a ruse by the NSA

ECDHE and ECDSA are all out then. This leaves you with the following:


Just remember to use large RSA keys and re-read that section above about using strong dhparam values.

Also note that you are giving up perfect forward secrecy, so take appropriate precautions; there are some automations you can set up to give you effective forward secrecy without DHE, and we leave that as an exercise for the reader.

You believe that the NSA wants you to think that elliptic curve cryptography is a ruse

You are probably right, which means we should use it! And since we are paranoid and are prioritizing security over adoption, we're going to insist on ECDSA as well.


The same rules about large dhparam values applies here too.

For the IoT and Mobile Crowd

Admittedly, by "mobile" we are not talking about those who buy the new iPhone at release, but rather the actual bulk of the world running on "low-end" Android phones across the world, with less optimal hardware and networking conditions.

These recommendations are aimed more squarely at performance than anything else, including a preference for the new streaming ciphers if supported.


For the Practical

Actually, the practical should just stick to Mozilla's recommendation:


But let's talk about them a bit. Elliptic curves are given a lot of play here, and we have to agree; despite all the shadowy antics of the NSA, elliptic curves are a great way to go for the vast majority of us. The lack of AEAD on the last few suites should not really be a major concern for most of us just yet. This cipher suite group should be stable for the next few years at least.

ECDSA is well backed here, despite the current difficulty in getting appropriate certificates; LetsEncrypt has announced it's intention to support DSA in 2017, and we expect adoption to climb significantly afterwards—both directly and as other CAs begin to get onboard.


You made it to the end! Congratulations! We really didn't think you would. If you have noticed an egregious mistake, or just want to say 'hi', you can tweet us at or drop us a line at

PS. Free stickers to anyone who spots an error!



Want more?

Subscribe to get new resources like this one, and to be notified of updates.

Subscribed! An email confirmation has been sent.