SSL Cipher Examples: How They Work

SSL/TLS ciphers are the encryption algorithms that secure data between a browser and a server, and this article explains them with concrete examples. You will learn what a cipher suite is, how the handshake uses them, and how to see which ones your server supports. By the end, you will be able to read a cipher suite name and understand what each part does.

What Is an SSL Cipher Suite?

An SSL/TLS cipher suite is a named combination of four algorithms that work together to create a secure connection. The suite defines the key exchange, authentication, symmetric encryption, and message integrity. For example, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 is a common suite used in modern web servers.

Each part of the name tells you exactly what is happening:

• TLS – the protocol version (TLS 1.2 or 1.3).
• ECDHE – the key exchange method (Elliptic Curve Diffie-Hellman Ephemeral).
• RSA – the authentication algorithm (RSA certificates).
• AES_128_GCM – the symmetric cipher and mode (AES with 128-bit key in Galois/Counter Mode).
• SHA256 – the hash function used for message authentication (HMAC).

In TLS 1.3, the suite names are shorter because the key exchange and authentication are negotiated separately. For instance, TLS_AES_256_GCM_SHA384 is a TLS 1.3 suite that uses AES-256-GCM and SHA-384.

How Cipher Suites Work in the TLS Handshake

When a client connects to a server, the two sides perform a handshake to agree on a cipher suite. The client sends a list of supported suites in the ClientHello message. The server picks one from that list, usually the strongest it supports, and replies with the chosen suite in the ServerHello.

Here is a simplified example of the handshake steps:

1. ClientHello – the client sends its TLS version, a random number, and a list of cipher suites.
2. ServerHello – the server selects one suite and sends its own random number and certificate.
3. Key Exchange – the client and server use the agreed method (e.g., ECDHE) to compute a shared secret without sending it directly.
4. ChangeCipherSpec – both sides switch to encrypted communication using the symmetric cipher.
5. Finished – both sides send a hash of the handshake messages to verify integrity.

If the client does not support any suite the server offers, the handshake fails with an error like “no shared cipher.”

Real-World Cipher Suite Examples

Here are three common cipher suites you might see on a modern server, with what each does:

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 – Uses ephemeral ECDH key exchange, RSA authentication, AES-256-GCM encryption, and SHA-384 for integrity. This is a strong, forward-secret suite.
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 – Similar but uses ECDSA certificates instead of RSA. Often used with elliptic curve keys.
• TLS_RSA_WITH_AES_128_CBC_SHA – An older suite using RSA key exchange, AES in CBC mode, and SHA-1. This is now considered weak and should be disabled.

In TLS 1.3, only five suites are officially defined, and they all use AEAD ciphers (GCM or ChaCha20). For example, TLS_CHACHA20_POLY1305_SHA256 is a TLS 1.3 suite that uses ChaCha20-Poly1305 for encryption and authentication.

How to Check Which Ciphers Your Server Supports

You can use command-line tools to list the cipher suites your server advertises. The most common is openssl. For example, to see all ciphers supported by your OpenSSL build:

openssl ciphers -v

To test a specific server, you can use openssl s_client:

openssl s_client -connect example.com:443 -cipher 'ECDHE-RSA-AES128-GCM-SHA256'

This will attempt a handshake using only that cipher. If it succeeds, the server supports it; if not, you will see an error.

For a more user-friendly scan, tools like sslscan or nmap --script ssl-enum-ciphers can enumerate all supported ciphers on a remote server. These tools are widely used by administrators to audit their TLS configuration.

How to Choose Strong Ciphers

When configuring a server, you want to enable only strong, modern ciphers and disable weak ones. Here are the general rules:

• Prefer ECDHE or DHE key exchange for forward secrecy.
• Use AEAD ciphers like AES-GCM or ChaCha20-Poly1305.
• Disable CBC mode ciphers if possible, as they are prone to padding oracle attacks.
• Disable RC4, DES, and 3DES – they are broken or too weak.
• Disable SHA-1 based suites; use SHA-256 or SHA-384.
• For TLS 1.3, you only need to choose between AES-GCM and ChaCha20.

A typical secure configuration for TLS 1.2 might include only suites like TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256. Many servers also enable ChaCha20 for clients that do not support AES hardware acceleration.

Common Problems and Misconceptions

One common misconception is that a longer key always means stronger security. In practice, AES-256 is not twice as secure as AES-128; it just has a larger key space. For most purposes, AES-128 is sufficient, but AES-256 is preferred for compliance.

Another issue is the confusion between cipher suites and protocols. A server can support TLS 1.2 but only weak ciphers, making it insecure. Conversely, a server can have strong ciphers but support an old protocol like SSLv3, which is vulnerable to POODLE. Both must be configured properly.

A frequent problem is the “no shared cipher” error when a client and server cannot agree. This often happens when the client has a very limited list (e.g., an old browser) and the server has disabled all older ciphers. The fix is usually to enable a few intermediate ciphers for compatibility, but only if they are not severely broken.

Comparing Cipher Strengths

Here is a rough comparison of common symmetric ciphers used in TLS:

• AES-128-GCM – Fast with hardware acceleration, widely supported, strong.
• AES-256-GCM – Same speed as AES-128 on modern CPUs, slightly stronger key, used for high-security.
• ChaCha20-Poly1305 – Faster than AES on devices without AES-NI (e.g., some ARM processors), strong.
• 3DES – Slow and vulnerable to Sweet32 attack; should be disabled.
• RC4 – Broken, biased output; never use.

For key exchange, ECDHE is preferred over plain RSA because it provides forward secrecy. DHE is also forward secret but slower. ECDHE with curve P-256 is a good default.

Cost and Performance Considerations

There is no direct cost for using a particular cipher suite, but there is a performance cost. AES-GCM is very fast on modern CPUs with AES-NI instructions. ChaCha20 is faster on devices without that hardware. ECDHE key exchange is computationally light compared to DHE, which uses large prime numbers.

For high-traffic servers, the choice of cipher can affect CPU usage. Enabling only strong ciphers usually does not hurt performance because the handshake is a small part of the connection. The symmetric encryption dominates, and AES-GCM is extremely fast.

Frequently Asked Questions

What does “ephemeral” mean in ECDHE?

Ephemeral means the key exchange uses a temporary key that is generated for each session and discarded afterward. This provides forward secrecy: even if the server’s long-term private key is compromised, past sessions cannot be decrypted.

Why is RC4 considered broken?

RC4 has statistical biases in its output that allow an attacker to recover plaintext after observing a large amount of traffic. It has been deprecated by all major browsers and standards bodies.

Can I use the same cipher suite for TLS 1.2 and TLS 1.3?

No. TLS 1.3 defines its own cipher suites that are shorter and only use AEAD ciphers. TLS 1.2 suites are not compatible with TLS 1.3.

How do I see what cipher a website is using?

In most browsers, click the padlock icon and look for “Connection secure” or “Certificate.” In Chrome, you can use the Security tab in DevTools. Alternatively, use openssl s_client as shown above.

Is AES-128 enough for government use?

Yes, AES-128 is approved for classified information up to SECRET in the US government. AES-256 is used for TOP SECRET. For general web traffic, AES-128 is more than sufficient.

Related

• Household Water Conservation During a Western Drought
• Sega Classic Games Revival at Game Awards
• Structured Human Input in Agentic Work