TLS Configuration Hardening: Disabling Weak Ciphers, Enforcing TLS 1.3, and Scanning for Misconfigurations
TLS configuration hardening closes the gap between what your servers support and what they should support. A server that accepts TLS 1.0, RC4, or 3DES is vulnerable to BEAST, POODLE, SWEET32, and various downgrade attacks even if all your application code is correct. The configuration is the vulnerability. Modern TLS hardening targets three outcomes: eliminate weak protocol versions (TLS 1.0 and 1.1), remove weak and deprecated cipher suites (RC4, 3DES, export-grade, NULL), and enforce security mechanisms that prevent downgrade even when weak protocol support is technically absent (HSTS, HPKP, certificate transparency).
This guide covers the configuration changes for the major web servers and load balancers, the scanning tools to verify your configuration, and the decision matrix for choosing cipher suite ordering in different compliance contexts.
TLS Protocol Version Support: What to Disable and Why
TLS 1.0 (1999) — Disable immediately: TLS 1.0 is vulnerable to BEAST (Browser Exploit Against SSL/TLS) which allows an attacker with a man-in-the-middle position to decrypt session cookies via a chosen-plaintext attack. PCI DSS 3.2.1 prohibited TLS 1.0 for payment card data environments since 2018. NIST SP 800-52 Rev 2 prohibits TLS 1.0 for US federal systems. All major browsers removed TLS 1.0 support in 2020-2021. There is no legitimate reason for a modern server to support TLS 1.0.
TLS 1.1 (2006) — Disable immediately: TLS 1.1 mitigated BEAST but retains mandatory support for RC4 (now broken) in the cipher suite list and lacks the additional security improvements in TLS 1.2. Browsers removed TLS 1.1 alongside TLS 1.0. Disable TLS 1.1 concurrently with TLS 1.0.
TLS 1.2 (2008) — Retain with restricted cipher suites: TLS 1.2 is secure when configured with modern cipher suites and authenticated encryption (AEAD). A significant portion of legitimate clients (particularly older enterprise software and IoT devices) still require TLS 1.2. Retain TLS 1.2 with the following cipher suites only: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Explicitly disable all non-AEAD cipher suites in TLS 1.2.
TLS 1.3 (2018) — Enforce as default: TLS 1.3 redesigned the handshake to eliminate known weaknesses: deprecated all non-AEAD cipher suites, removed RSA key exchange (vulnerable to RSA decryption attacks against recorded sessions), reduced handshake round trips from 2-RTT to 1-RTT (performance improvement), and integrated forward secrecy as mandatory rather than optional. Configure servers to prefer TLS 1.3 and fall back to TLS 1.2 only for clients that cannot negotiate TLS 1.3.
SSL 3.0 and earlier — Disable entirely: SSL 3.0 is vulnerable to POODLE (Padding Oracle On Downgraded Legacy Encryption) and should be disabled on all servers. Any modern SSL/TLS library has SSL 3.0 disabled by default; the risk is legacy appliances or custom applications built on old SSL library versions.
Cipher Suite Configuration by Platform
The following configurations implement Mozilla's Intermediate compatibility profile — supporting TLS 1.2 and 1.3 while maintaining compatibility with clients from the past 5 years. For maximum security environments (TLS 1.3 only), see the Modern profile.
Nginx (nginx.conf):
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
ssl_dhparam /etc/nginx/dhparam.pem; # Generate: openssl dhparam -out dhparam.pem 4096
Apache (ssl.conf):
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
SSLHonorCipherOrder off
SSLSessionTickets off
Windows IIS (via registry — apply then restart IIS):
# Disable TLS 1.0
New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Name 'Enabled' -Value 0
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' -Name 'DisabledByDefault' -Value 1
# Disable TLS 1.1 (same pattern, replace '1.0' with '1.1')
# Enable TLS 1.3 (Windows Server 2022+ only)
New-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -Force
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server' -Name 'Enabled' -Value 1
HAProxy:
bind *:443 ssl crt /etc/ssl/cert.pem no-sslv3 no-tlsv10 no-tlsv11 ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384 curves X25519:prime256v1:secp384r1
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
HTTP Security Headers: HSTS, HPKP, and CSP
TLS protocol and cipher configuration secures the connection layer. HTTP security headers enforce policy at the application layer, preventing downgrade attacks and ensuring browsers refuse to connect via insecure channels even if the server would allow it.
HTTP Strict Transport Security (HSTS): HSTS tells browsers to refuse HTTP connections to a domain for a specified duration, preventing SSL stripping attacks where an attacker intercepts the first HTTP request before HTTPS is negotiated.
Configuration:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
max-age=31536000: browsers enforce HTTPS for 1 year after receiving this headerincludeSubDomains: applies the policy to all subdomains (required for preload)preload: allows submission to the browser HSTS preload list (hstspreload.org) — the domain is hardcoded into browser source code to always use HTTPS, even on first visit before any header is received
HSTS deployment sequence (critical — wrong order causes outages):
- Enable HTTPS on all subdomains first
- Deploy HSTS with
max-age=300(5 minutes) andincludeSubDomainsto test - Verify no HTTP-only subdomains exist that would become unreachable
- Increase max-age to
31536000after 30 days of incident-free operation - Add
preloaddirective and submit to hstspreload.org
Content Security Policy (CSP): CSP prevents cross-site scripting and data injection by specifying which sources browsers may load content from. A strict CSP that disallows inline scripts eliminates the majority of XSS attack surface:
Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; frame-ancestors 'none'; upgrade-insecure-requests;
The upgrade-insecure-requests directive instructs browsers to upgrade any HTTP resource references on the page to HTTPS automatically, preventing mixed content issues without code changes.
X-Content-Type-Options: nosniff
Prevents browsers from MIME-type sniffing responses away from the declared Content-Type. Stops attacks where an attacker serves a malicious script disguised as an image file. Set on all responses: X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Prevents your pages from being embedded in iframes on other domains, blocking clickjacking attacks where a malicious site renders your site invisibly and tricks users into clicking. Modern equivalent is frame-ancestors in CSP, but X-Frame-Options provides backward compatibility. Use DENY to prevent all framing or SAMEORIGIN to allow same-domain framing only.
Referrer-Policy: strict-origin-when-cross-origin
Controls how much referrer information is sent with requests. This setting sends the full URL for same-origin requests (useful for analytics) but only the origin (not the full path) for cross-origin requests, preventing sensitive URL path information (containing user IDs, session tokens, or PII) from leaking to third-party domains.
Permissions-Policy (formerly Feature-Policy)
Disables browser features your application does not need, reducing attack surface for browser-based exploits. Example: Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(). Disabling features you do not use prevents malicious scripts from abusing them if injected.
Scanning Tools: Verifying Your TLS Configuration
Never trust configuration changes without verification. Use these tools to confirm your changes had the intended effect and identify any remaining weaknesses.
testssl.sh — Comprehensive local scanning: testssl.sh is the most comprehensive open-source TLS scanner. It tests protocol versions, cipher suites, certificate validity, HSTS configuration, HPKP, CSP headers, key exchange parameters, and known vulnerabilities (HEARTBLEED, ROBOT, BEAST, CRIME, BREACH, POODLE, DROWN, LOGJAM, FREAK, SWEET32).
# Basic scan
testssl.sh https://example.com
# Save results as HTML report
testssl.sh --html --logfile /tmp/tls-report.html https://example.com
# Scan internal host (non-HTTP service)
testssl.sh --starttls smtp mail.example.com:25
# Batch scan from file
testssl.sh --file hosts.txt --parallel
sslyze — Python-based TLS scanner (CI/CD integration): sslyze is purpose-built for automated scanning and produces JSON output for easy parsing in pipelines:
pip install sslyze
python -m sslyze --json_out results.json example.com:443
Integrate sslyze into your CI/CD pipeline to prevent TLS regressions from being deployed: run sslyze against staging environments during the deployment pipeline and fail the build if TLS 1.0/1.1 or weak cipher suites are detected.
Qualys SSL Labs (external, browser-based): SSL Labs provides an externally sourced grade (A+ through F) and detailed analysis of your public-facing TLS configuration. A+ requires: TLS 1.2+ only, AEAD cipher suites, HSTS with 6-month min-age, no vulnerabilities. Run SSL Labs against all internet-facing endpoints quarterly and after any TLS configuration change.
Nmap TLS scanning (internal networks):
# Enumerate supported cipher suites on internal host
nmap --script ssl-enum-ciphers -p 443 10.0.0.1
# Scan for TLS 1.0/1.1 support across a subnet
nmap --script ssl-dh-params,ssl-poodle -p 443 10.0.0.0/24
TLS Configuration Compliance Matrix
Different compliance frameworks have specific TLS requirements. Use this matrix to confirm your configuration meets the applicable standard.
PCI DSS 4.0 — Payment card environments
Requires TLS 1.2 minimum (TLS 1.0 and 1.1 prohibited since PCI DSS 3.2.1 migration deadline in 2018). Requires AEAD cipher suites; prohibits RC4, DES, 3DES, and export cipher suites. Certificate key lengths: RSA 2048-bit minimum, ECDSA 256-bit minimum. The 2024 additions in PCI DSS 4.0 add requirements for managing cryptographic key lifetimes and maintaining an inventory of all cryptographic implementations.
NIST SP 800-52 Rev 2 — US Federal systems
Requires TLS 1.2 or 1.3 only (TLS 1.0 and 1.1 prohibited). Mandates FIPS 140-2 approved cipher suites: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. DHE cipher suites require minimum 3072-bit DH parameters. TLS 1.3 cipher suites are all FIPS-approved by default.
HIPAA — Healthcare data
HIPAA does not specify TLS version or cipher suite requirements directly, but NIST guidance for HIPAA-covered entities recommends following NIST SP 800-52. The HIPAA Security Rule requires 'encryption and decryption of electronic protected health information' in transmission, which regulators and auditors interpret as requiring current standards. TLS 1.0 and 1.1 are considered insufficient by HHS and OCR in breach investigations.
SOC 2 Type II — Service organizations
SOC 2 auditors assess encryption controls under the CC9.1 criterion (encryption of data in transit). TLS 1.0 and 1.1 support will typically generate a finding under SOC 2. Auditors assess encryption against 'industry-standard' definitions; the current industry standard is TLS 1.2+ with AEAD cipher suites. Document your TLS configuration policy and evidence of quarterly scanning to satisfy auditor requests for evidence.
The bottom line
TLS configuration hardening is a configuration change, not a code change — making it one of the lowest-cost, highest-impact security improvements available for most organizations. The baseline changes (disable TLS 1.0/1.1, restrict to AEAD cipher suites, deploy HSTS) can typically be implemented in a maintenance window for standard web server deployments. The high-value next step is automated scanning integration: add testssl.sh or sslyze to your CI/CD pipeline so that TLS regressions are caught before they reach production. Run Qualys SSL Labs against all internet-facing endpoints quarterly and target A+ on all externally accessible services.
Frequently asked questions
Is TLS 1.2 still secure in 2026?
TLS 1.2 is secure when configured with modern AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) and is still widely used for compatibility reasons. The security weaknesses in TLS 1.2 come from its optional support for insecure cipher suites (RC4, 3DES, CBC mode with SHA-1) and insecure key exchange mechanisms (RSA key exchange without forward secrecy). A properly configured TLS 1.2 deployment using only ECDHE + AES-GCM cipher suites is not meaningfully less secure than TLS 1.3 for most threat models. TLS 1.3 is preferable for new deployments primarily because its design eliminates the possibility of insecure configuration.
What is the difference between forward secrecy and regular TLS encryption?
Forward secrecy (also called Perfect Forward Secrecy or PFS) means that the compromise of a server's long-term private key in the future cannot be used to decrypt previously recorded TLS sessions. Without forward secrecy (RSA key exchange), an attacker who records encrypted traffic and later obtains the server private key can retroactively decrypt all past sessions. With forward secrecy (ECDHE or DHE key exchange), each session uses an ephemeral key that is discarded after the session ends — past sessions cannot be decrypted even with the private key. All TLS 1.3 cipher suites provide forward secrecy by design; in TLS 1.2, forward secrecy requires specifically selecting ECDHE or DHE cipher suites.
What is HSTS preloading and should I use it?
HSTS preloading means your domain is hardcoded into browser source code to always use HTTPS, enforced even on the very first connection before any HSTS header is received. This closes the window where a first-time visitor on an attacker-controlled network could be SSL-stripped before the HSTS header arrives. Preloading is appropriate for domains where: HTTPS works reliably for all subdomains, no HTTP-only subdomains exist or ever will, and the domain is not expected to need HTTP access in future. Preloading is difficult to reverse — removal from the preload list can take months to propagate. Do not preload internal-only domains or domains that may need HTTP access for operational reasons.
How do I handle legacy clients that require TLS 1.0 or 1.1?
The correct answer is: update or replace the legacy client, not maintain server-side weak protocol support. For internal applications with legacy clients, maintain a separate TLS termination endpoint that supports TLS 1.0/1.1 but is accessible only from the internal network segment containing the legacy clients, with that segment isolated from internet access. For external-facing services, accepting the incompatibility is the correct security decision — the client population requiring TLS 1.0/1.1 is statistically near-zero on modern networks. Document any exceptions with business justification, compensating controls, and a timeline for remediation.
What is testssl.sh and how do I use it to audit my TLS configuration?
testssl.sh is an open-source bash script that comprehensively tests TLS/SSL configurations against a target host. It checks protocol version support, cipher suites offered, certificate validity and chain, HSTS header presence, DH parameter strength, and known vulnerabilities (HEARTBLEED, POODLE, ROBOT, BEAST, CRIME, DROWN, LOGJAM). Run it as: testssl.sh https://yourdomain.com for internet-facing hosts, or testssl.sh 10.0.0.1:443 for internal hosts. The output flags each finding as OK, WARNING, or NOT OK. Target zero NOT OK findings before deploying to production. testssl.sh is preferable to Qualys SSL Labs for internal hosts and automated pipeline scanning.
Should I implement certificate pinning for my web application?
Certificate pinning for public web applications is generally not recommended due to operational complexity and risk. If the pinned certificate expires or is replaced (for legitimate reasons like CA compromise or organizational changes), all pinned clients break simultaneously until updated. HTTP Public Key Pinning (HPKP) was deprecated by all major browsers due to catastrophic misconfiguration incidents. For mobile applications connecting to known internal APIs, certificate pinning at the application layer (pinning in the mobile app binary) remains appropriate and standard practice. For web browsers connecting to public web servers, rely on certificate transparency logs and CAA DNS records instead of pinning.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.