# TLS Cipher Suites

CRYPTOGRAPHIC ALGORITHMS SECURITY CONFIGURATION BEST PRACTICES

Cipher Suites Define Your Security

A cipher suite is the complete set of algorithms that secure your TLS connection. Choosing the right cipher suites is critical - weak ciphers can be broken by attackers, while strong ciphers provide robust protection. Your cipher suite configuration directly determines whether your encrypted communications are secure or vulnerable.

# What is a Cipher Suite?

DEFINITION

Simple Definition: A cipher suite is a named combination of authentication, encryption, and message authentication code (MAC) algorithms used to negotiate security settings for a TLS connection.

The Components:

A cipher suite specifies ALL the cryptographic algorithms used in a TLS connection:

Key Exchange Algorithm - How client and server agree on shared secret keys
Authentication Algorithm - How server (and optionally client) proves its identity
Encryption Algorithm - How data is encrypted for confidentiality
MAC/AEAD Algorithm - How data integrity and authenticity are verified

Real-World Analogy

Think of a cipher suite like a security system package for your house:

Cipher Suite = Complete Security Package:

Lock type (Key Exchange) - Deadbolt, smart lock, or padlock?
ID verification (Authentication) - Key card, fingerprint, or face recognition?
Alarm system (Encryption) - Motion sensors, cameras, or door sensors?
Tamper detection (MAC/AEAD) - Alerts when someone tries to break in

Just like you can't mix and match incompatible security components, TLS cipher suites define compatible algorithm combinations that work together.

# Cipher Suite Naming

NAMING CONVENTION

# TLS 1.2 Cipher Suite Format

Cipher suite names follow a structured format:

plaintext
TLS_[KeyExchange]_[Authentication]_WITH_[Encryption]_[MAC]

Example: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
         │   │      │    │    │   │   │   │
         │   │      │    │    │   │   │   └─ MAC/Hash: SHA-384
         │   │      │    │    │   │   └───── AEAD Mode: GCM
         │   │      │    │    │   └───────── Key Size: 256-bit
         │   │      │    │    └───────────── Encryption: AES
         │   │      │    └────────────────── Separator
         │   │      └─────────────────────── Authentication: RSA
         │   └────────────────────────────── Key Exchange: ECDHE
         └────────────────────────────────── Protocol: TLS

1. Key Exchange (ECDHE, DHE, RSA)

Determines how the client and server agree on encryption keys:

plaintext
✅ ECDHE (Elliptic Curve Diffie-Hellman Ephemeral)
   - Modern, fast, provides Forward Secrecy
   - Recommended for all new configurations

✅ DHE (Diffie-Hellman Ephemeral)
   - Slower but provides Forward Secrecy
   - Fallback for clients that don't support ECDHE

❌ RSA (RSA key exchange)
   - NO Forward Secrecy
   - Deprecated, avoid in new configurations

2. Authentication (RSA, ECDSA, DSS)

How the server proves its identity:

plaintext
✅ RSA (Rivest-Shamir-Adleman)
   - Most common, universally supported
   - Uses RSA certificates

✅ ECDSA (Elliptic Curve Digital Signature Algorithm)
   - Smaller keys, faster operations
   - Requires ECDSA certificates
   - Better for mobile/IoT devices

❌ DSS (Digital Signature Standard)
   - Obsolete, avoid

3. Encryption (AES, CHACHA20)

The symmetric encryption algorithm for data:

plaintext
✅ AES-256 (Advanced Encryption Standard, 256-bit)
   - Industry standard, hardware accelerated
   - Excellent security
   - Best choice for most applications

✅ AES-128 (Advanced Encryption Standard, 128-bit)
   - Faster than AES-256, still very secure
   - Suitable for high-performance needs
   - Good balance of speed and security

✅ CHACHA20 (ChaCha20-Poly1305)
   - Excellent for mobile devices (no hardware AES)
   - Fast in software
   - Used by Google, Cloudflare

❌ 3DES (Triple DES)
   - Obsolete, slow, 64-bit block size
   - Vulnerable to Sweet32 attack

❌ RC4 (Rivest Cipher 4)
   - Completely broken
   - Never use

4. MAC/AEAD (GCM, SHA256, SHA384)

Ensures data hasn't been tampered with:

plaintext
✅ GCM (Galois/Counter Mode) - AEAD
   - Provides both encryption AND authentication
   - Fast, hardware accelerated
   - Recommended for all configurations

✅ POLY1305 - AEAD
   - Used with CHACHA20
   - Fast, secure AEAD mode

⚠️  CBC + SHA256/SHA384 - Legacy
   - Older "Encrypt-then-MAC" approach
   - Vulnerable to padding oracle attacks if implemented incorrectly
   - Use only for compatibility with old clients

❌ MD5
   - Completely broken
   - Never use

# TLS 1.3 Cipher Suite Format

TLS 1.3 simplified cipher suite naming by removing key exchange and authentication from the name (they're negotiated separately):

plaintext
TLS_[Encryption]_[MAC]

Example: TLS_AES_256_GCM_SHA384
         │   │   │   │   │
         │   │   │   │   └─ Hash: SHA-384
         │   │   │   └───── AEAD Mode: GCM
         │   │   └───────── Key Size: 256-bit
         │   └───────────── Encryption: AES
         └───────────────── Protocol: TLS

TLS 1.3 Simplification

TLS 1.3 removed vulnerable options and simplified configuration:

Key Exchange: Always uses ephemeral keys (Forward Secrecy mandatory)
Authentication: Negotiated separately using signature algorithms
Encryption: Only AEAD ciphers allowed (GCM, CCM, CHACHA20-POLY1305)
Result: Simpler, faster, more secure

# Recommended Cipher Suites

BEST PRACTICES

# Modern Configuration (2025)

Best for: Modern infrastructure, high-security applications, compliance requirements

# TLS 1.3 only - maximum security
ssl_protocols TLSv1.3;

# TLS 1.3 cipher suites (order matters for performance)
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256';

ssl_prefer_server_ciphers off;  # Client preference in TLS 1.3

Cipher Suites Included:

Cipher Suite	Security	Performance	Notes
TLS_AES_256_GCM_SHA384	Excellent 256-BIT	Fast (hardware AES)	Best all-around choice
TLS_CHACHA20_POLY1305_SHA256	Excellent 256-BIT	Very fast (software)	Best for mobile devices
TLS_AES_128_GCM_SHA256	Strong 128-BIT	Very fast	High-performance option

Benefits:

Forward Secrecy mandatory
No known vulnerabilities
Fast handshakes (1-RTT)
Simple configuration
Resistant to downgrade attacks

Limitations:

Drops clients older than ~2018
Some corporate proxies don't support TLS 1.3 yet

Best for: Most production websites, balance of security and compatibility

# TLS 1.2 and 1.3
ssl_protocols TLSv1.2 TLSv1.3;

# Cipher suite configuration
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';

ssl_prefer_server_ciphers on;

TLS 1.3 Ciphers (Top Priority):

TLS_AES_256_GCM_SHA384 - AES-256 with GCM
TLS_CHACHA20_POLY1305_SHA256 - ChaCha20 for mobile
TLS_AES_128_GCM_SHA256 - AES-128 for speed

TLS 1.2 Ciphers (Fallback for older clients):

ECDHE-ECDSA-AES256-GCM-SHA384 - Best TLS 1.2 with ECDSA cert
ECDHE-RSA-AES256-GCM-SHA384 - Best TLS 1.2 with RSA cert
ECDHE-ECDSA-CHACHA20-POLY1305 - ChaCha20 for mobile (ECDSA)
ECDHE-RSA-CHACHA20-POLY1305 - ChaCha20 for mobile (RSA)
ECDHE-ECDSA-AES128-GCM-SHA256 - Fast option (ECDSA)
ECDHE-RSA-AES128-GCM-SHA256 - Fast option (RSA)

Benefits:

Supports 99%+ of clients
Forward Secrecy for all connections
Strong security
Good performance
Modern and legacy client support

Who's Excluded:

IE 10 and older on Windows 7
Android 4.x and older
Java 6 and 7

Best for: Sites that must support very old clients (pre-2013)

# TLS 1.2 and 1.3
ssl_protocols TLSv1.2 TLSv1.3;

# Include CBC ciphers for ancient clients
ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

ssl_prefer_server_ciphers on;

Additional Ciphers (Legacy):

ECDHE-ECDSA-AES256-SHA384 - TLS 1.2 CBC mode (ECDSA)
ECDHE-RSA-AES256-SHA384 - TLS 1.2 CBC mode (RSA)
ECDHE-ECDSA-AES128-SHA256 - TLS 1.2 CBC mode (ECDSA)
ECDHE-RSA-AES128-SHA256 - TLS 1.2 CBC mode (RSA)

Security Trade-off

CBC mode ciphers are vulnerable to padding oracle attacks if not implemented correctly. Only include these if you have verified need for very old client support. Monitor usage and remove when possible.

PADDING ORACLE RISK

# Insecure Cipher Suites to Avoid

NEVER USE

# Completely Broken Ciphers

These cipher suites have known vulnerabilities and should NEVER be enabled:

plaintext
❌ NEVER USE:
  - TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
  - TLS_RSA_EXPORT_WITH_RC4_40_MD5
  - TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5

Vulnerabilities:
  - 40-bit keys can be brute forced in seconds
  - Deliberately weakened for 1990s export restrictions
  - FREAK attack (2015) exploited these

Real Attack: FREAK (Factoring RSA Export Keys) - attackers downgraded modern browsers to use 512-bit export-grade RSA keys, which could be factored in 7 hours.

plaintext
❌ NEVER USE:
  - TLS_RSA_WITH_RC4_128_SHA
  - TLS_RSA_WITH_RC4_128_MD5
  - TLS_ECDHE_RSA_WITH_RC4_128_SHA

Vulnerabilities:
  - Statistical biases allow plaintext recovery
  - Bar Mitzvah attack (2015)
  - RC4 NOMORE attack (2015)
  - Prohibited by RFC 7465 (2015)

Real Attack: Researchers demonstrated recovery of passwords and cookies from HTTPS traffic encrypted with RC4.

plaintext
❌ NEVER USE:
  - TLS_RSA_WITH_DES_CBC_SHA
  - TLS_RSA_WITH_3DES_EDE_CBC_SHA
  - TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

Vulnerabilities:
  - DES: 56-bit key, trivially broken
  - 3DES: 64-bit block size → Sweet32 attack
  - Can recover plaintext after ~32GB of data
  - Deprecated by NIST, prohibited by PCI-DSS

Real Attack: Sweet32 (2016) - Birthday attack on 64-bit block ciphers allows plaintext recovery from long-lived TLS connections.

plaintext
❌ NEVER USE:
  - TLS_RSA_WITH_RC4_128_MD5
  - TLS_RSA_WITH_3DES_EDE_CBC_MD5
  - Any cipher with MD5 for integrity

Vulnerabilities:
  - MD5 collision attacks well known
  - Can forge message authentication
  - Completely insecure for integrity checking

plaintext
⚠️  AVOID (No Forward Secrecy):
  - TLS_RSA_WITH_AES_256_GCM_SHA384
  - TLS_RSA_WITH_AES_128_GCM_SHA256
  - TLS_RSA_WITH_AES_256_CBC_SHA256
  - TLS_RSA_WITH_AES_128_CBC_SHA

Issues:
  - No Forward Secrecy
  - "Record and decrypt later" attack possible
  - If server's private key is stolen, ALL past traffic can be decrypted
  - Prohibited by modern compliance standards

# Vulnerability Timeline

Year	Vulnerability	Affected Ciphers	Impact
2011	BEAST	CBC mode in TLS 1.0	Plaintext recovery MEDIUM
2013	CRIME	TLS compression	Session hijacking MEDIUM
2014	POODLE	SSLv3 CBC	Plaintext recovery HIGH
2015	FREAK	Export ciphers	Downgrade to 512-bit RSA HIGH
2015	Logjam	Export DHE	MitM on weak DH HIGH
2015	RC4 NOMORE	RC4 ciphers	Plaintext recovery HIGH
2016	DROWN	SSLv2	Decrypt TLS sessions CRITICAL
2016	Sweet32	3DES, Blowfish	Birthday attack MEDIUM
2017	ROBOT	RSA PKCS#1 v1.5	Decrypt RSA ciphertext MEDIUM
2019	Zombie POODLE	CBC with bad padding	Padding oracle LOW

# Server Configuration

IMPLEMENTATION

# Nginx Configuration

# /etc/nginx/nginx.conf or site config

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name example.com;

    # Certificate configuration
    ssl_certificate /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;
    ssl_trusted_certificate /etc/ssl/certs/ca-chain.crt;

    # Protocol versions - TLS 1.2 and 1.3 only
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher suites - balanced security and compatibility
    ssl_ciphers 'TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';

    # Prefer server cipher order for TLS 1.2
    ssl_prefer_server_ciphers on;

    # DH parameters for DHE ciphers
    ssl_dhparam /etc/ssl/certs/dhparam.pem;

    # Session settings
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    ssl_session_tickets off;

    # OCSP Stapling
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8 8.8.4.4 valid=300s;
    resolver_timeout 5s;

    # Security headers
    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-XSS-Protection "1; mode=block" always;

    # Disable TLS compression (CRIME attack)
    ssl_compression off;

    location / {
        root /var/www/html;
        index index.html;
    }
}

# Redirect HTTP to HTTPS
server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    return 301 https://$server_name$request_uri;
}

# Apache Configuration

<VirtualHost *:443>
    ServerName example.com
    DocumentRoot /var/www/html

    # Enable SSL/TLS
    SSLEngine on

    # Certificate configuration
    SSLCertificateFile /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key
    SSLCertificateChainFile /etc/ssl/certs/ca-chain.crt

    # Protocol versions - TLS 1.2 and 1.3 only
    SSLProtocol -all +TLSv1.2 +TLSv1.3

    # Cipher suites - balanced security and compatibility
    SSLCipherSuite TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256

    # Prefer server cipher order
    SSLHonorCipherOrder on

    # Use strong DH parameters
    SSLOpenSSLConfCmd DHParameters "/etc/ssl/certs/dhparam.pem"

    # Session cache
    SSLSessionCache "shmcb:/var/run/ssl_scache(512000)"
    SSLSessionCacheTimeout 300
    SSLSessionTickets off

    # Disable TLS compression
    SSLCompression off

    # OCSP Stapling
    SSLUseStapling on
    SSLStaplingCache "shmcb:/var/run/ocsp(128000)"

    # Security headers
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-XSS-Protection "1; mode=block"
</VirtualHost>

# Redirect HTTP to HTTPS
<VirtualHost *:80>
    ServerName example.com
    Redirect permanent / https://example.com/
</VirtualHost>

# Testing Cipher Suites

VERIFICATION

# Command Line Testing

List supported cipher suites:

# Check which ciphers your OpenSSL supports
openssl ciphers -v 'HIGH:!aNULL:!MD5'

# Test specific cipher suite against a server
openssl s_client -connect example.com:443 -cipher ECDHE-RSA-AES256-GCM-SHA384

# See what cipher was negotiated
openssl s_client -connect example.com:443 2>&1 | grep "Cipher"

Test for specific vulnerabilities:

# Test if server supports weak ciphers
echo | openssl s_client -connect example.com:443 -cipher 'RC4' 2>&1 | grep "Cipher"
# Should fail if RC4 is properly disabled

# Test if server supports 3DES
echo | openssl s_client -connect example.com:443 -cipher '3DES' 2>&1 | grep "Cipher"
# Should fail if 3DES is properly disabled

# Test TLS 1.3 support
openssl s_client -connect example.com:443 -tls1_3

Scan all supported ciphers:

#!/bin/bash
# Scan all cipher suites supported by a server

SERVER="example.com:443"
CIPHERS=$(openssl ciphers 'ALL:eNULL' | sed 's/:/ /g')

echo "Testing cipher suites against $SERVER"
echo "========================================"

for cipher in $CIPHERS; do
    result=$(echo -n | timeout 3 openssl s_client -cipher "$cipher" -connect $SERVER 2>&1)
    if echo "$result" | grep -q "Cipher is ${cipher}"; then
        echo "✅ $cipher"
    fi
done

SSL Labs Server Test (https://www.ssllabs.com/ssltest/)

plaintext
What to look for:

✅ GOOD RESULTS:
  - Overall Rating: A or A+
  - Protocol Support: TLS 1.3, TLS 1.2
  - Cipher Strength: 256-bit or 128-bit (ECDHE/DHE)
  - Forward Secrecy: Yes
  - Weak Ciphers: None supported

❌ BAD RESULTS:
  - Rating: B, C, D, or F
  - TLS 1.0 or TLS 1.1 enabled
  - RC4, 3DES, or export ciphers supported
  - Forward Secrecy: No or limited

SSL Labs Grading Criteria:

Grade	Meaning	Cipher Requirements
A+	Exceptional	TLS 1.3, HSTS preload, strong ciphers only EXCELLENT
A	Secure	TLS 1.2+, strong ciphers, Forward Secrecy GOOD
B	Adequate	Some weak ciphers or old TLS versions ACCEPTABLE
C	Weak	3DES, TLS 1.0, or other known issues NEEDS IMPROVEMENT
F	Failing	RC4, export ciphers, or critical flaws INSECURE

# Install testssl.sh
git clone https://github.com/drwetter/testssl.sh.git
cd testssl.sh

# Run comprehensive test
./testssl.sh example.com

# Test only cipher suites
./testssl.sh --cipher-per-proto example.com

# Check for specific vulnerabilities
./testssl.sh --vulnerable example.com

# JSON output for automation
./testssl.sh --jsonfile results.json example.com

Example output:

plaintext
Testing cipher categories
 NULL ciphers (no encryption)                      not offered (OK)
 Anonymous NULL Ciphers (no authentication)        not offered (OK)
 Export ciphers (w/o ADH+NULL)                     not offered (OK)
 LOW: 64 Bit + DES, RC[2,4], MD5 (w/o export)     not offered (OK)
 Triple DES Ciphers / IDEA                         not offered (OK)
 Obsoleted CBC ciphers (AES, ARIA etc.)            offered (NOT ok)
 Strong encryption (AEAD ciphers) with Forward Secrecy  offered (OK)

# Compliance Requirements

STANDARDS

# Regulatory Cipher Suite Requirements

Different compliance standards have specific cipher suite requirements:

PCI-DSS 4.0 Requirements:

plaintext
✅ REQUIRED:
  - TLS 1.2 or higher
  - Strong cryptography (minimum 128-bit)
  - Forward Secrecy recommended

❌ PROHIBITED:
  - SSL v2, SSL v3
  - TLS 1.0, TLS 1.1 (after June 2024)
  - Weak ciphers: RC4, DES, 3DES
  - NULL ciphers
  - Anonymous ciphers

Recommended Ciphers:
  - ECDHE-ECDSA-AES256-GCM-SHA384
  - ECDHE-RSA-AES256-GCM-SHA384
  - ECDHE-ECDSA-AES128-GCM-SHA256
  - ECDHE-RSA-AES128-GCM-SHA256
  - TLS 1.3 cipher suites (all)

NIST SP 800-52 Rev. 2:

plaintext
REQUIRED for Federal Systems:

✅ Approved Protocols:
  - TLS 1.2 (minimum)
  - TLS 1.3 (recommended)

✅ Approved Cipher Suites (TLS 1.2):
  - ECDHE-ECDSA with AES-GCM (128 or 256-bit)
  - ECDHE-RSA with AES-GCM (128 or 256-bit)

✅ Approved Cipher Suites (TLS 1.3):
  - TLS_AES_256_GCM_SHA384
  - TLS_AES_128_GCM_SHA256

❌ PROHIBITED:
  - SSL v2, SSL v3, TLS 1.0, TLS 1.1
  - RSA key exchange (no Forward Secrecy)
  - CBC mode ciphers (due to padding oracle risks)
  - RC4, DES, 3DES, IDEA
  - Export ciphers

HIPAA Security Rule:

plaintext
HIPAA requires "addressable" encryption standards:

✅ Recommended Configuration:
  - TLS 1.2 or higher
  - AEAD ciphers (GCM mode)
  - Forward Secrecy (ECDHE)
  - 256-bit encryption preferred for ePHI

⚠️  While HIPAA doesn't specify exact ciphers,
    following NIST or PCI-DSS guidelines ensures
    compliance with "addressable" encryption standards.

Best Practice:
  Use same cipher configuration as PCI-DSS

GDPR Article 32 - Security of Processing:

plaintext
GDPR requires "state of the art" encryption:

✅ Recommended (State of the Art 2025):
  - TLS 1.3
  - ECDHE key exchange (Forward Secrecy)
  - AES-256-GCM or CHACHA20-POLY1305
  - Regular security assessments

⚠️  "State of the art" is interpreted as:
    - Following current NIST/BSI recommendations
    - Using modern TLS versions
    - Avoiding known vulnerable ciphers
    - Regular updates and monitoring

# Cipher Suite Best Practices

RECOMMENDATIONS

# Configuration Best Practices

Enable TLS 1.3 - Best security and performance

Prioritize AEAD ciphers - GCM and CHACHA20-POLY1305

Require Forward Secrecy - Use ECDHE, avoid RSA key exchange

Use AES-256 for sensitive data - Banking, healthcare, government

Include CHACHA20 - Better for mobile devices without hardware AES

Order by security, then performance - Strong ciphers first

Disable CBC mode when possible - Padding oracle risks

Remove all weak ciphers - RC4, 3DES, DES, MD5, export ciphers

Test regularly - Use SSL Labs, testssl.sh

Monitor cipher usage - Track which ciphers clients negotiate

Update configurations annually - Cryptography evolves

# Operational Best Practices

Document cipher choices - Explain why each cipher is included

Monitor for weak cipher usage - Alert if weak ciphers are negotiated

Have rollback plan - In case changes break compatibility

Test before production - Verify configuration in staging

Keep OpenSSL updated - Security patches and new cipher support

Review compliance requirements - PCI-DSS, HIPAA, NIST, GDPR

Educate team - Ensure everyone understands cipher security

# What NOT to Do

Don't enable weak ciphers "just in case" - Better to break old clients

Don't use default configurations - They're often insecure

Don't ignore warnings from scanners - Fix reported issues

Don't disable all CBC ciphers without testing - May break compatibility

Don't assume newer is always better - Test and verify

Don't forget about reverse proxies - They need secure configs too

# Learn More

TLS/SSL Basics - Understanding the TLS protocol

Forward Secrecy - How ephemeral keys protect past communications

Certificate Chain - Certificate authentication

HSTS - Forcing HTTPS connections

SNI - Multiple HTTPS sites on one IP

# Protected by Layerd AI

Layerd AI Guardian Proxy provides:

Automatic Cipher Selection - Always uses strongest available cipher

Weak Cipher Blocking - Prevents connections with insecure ciphers

Real-time Vulnerability Detection - Alerts on newly discovered cipher weaknesses

Compliance Enforcement - Ensures cipher configuration meets PCI-DSS, HIPAA, NIST

Cipher Usage Analytics - Tracks which ciphers are being negotiated

Automatic Updates - Keeps cipher configuration current with best practices

Learn more about Layerd AI Protection →

Last updated: November 2025