TLS is the encryption layer that protects data in transit for virtually every web application, API, and networked service. When configured correctly, it provides confidentiality, integrity, and authentication. When configured poorly, it provides a false sense of security while leaving data exposed.
Most TLS misconfigurations are not obvious. The connection still works, the browser shows a padlock, and nobody notices that the server supports TLS 1.0, uses a weak cipher suite, or has a certificate chain error that clients silently ignore. A proper TLS audit catches these issues before attackers exploit them.
Protocol Version Audit
What to Check
Disable SSL 3.0. SSL 3.0 is broken (POODLE attack). No modern client needs it.
Disable TLS 1.0 and 1.1. Both versions have known weaknesses and have been deprecated by all major browsers. PCI DSS has required disabling TLS 1.0 since 2018.
Enable TLS 1.2. TLS 1.2 is the minimum acceptable version for general use. It supports modern cipher suites and has no known protocol-level vulnerabilities when configured correctly.
Enable TLS 1.3. TLS 1.3 removes legacy cipher suites, simplifies the handshake (improving performance), and provides forward secrecy by default. It should be the preferred version.
Testing
Use nmap --script ssl-enum-ciphers -p 443 your-server.com or testssl.sh to enumerate supported protocol versions. SSL Labs (ssllabs.com) provides a free web-based test for public servers.
Cipher Suite Audit
Modern Cipher Suite Selection
For TLS 1.3, the cipher suites are fixed by the specification: TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256, and TLS_CHACHA20_POLY1305_SHA256. There is nothing to misconfigure.
For TLS 1.2, cipher suite selection matters. Prefer:
- ECDHE key exchange for forward secrecy
- AES-GCM or ChaCha20-Poly1305 for authenticated encryption
- SHA-256 or SHA-384 for the MAC
Reject: RC4 (broken), DES/3DES (weak), MD5 (broken), export-grade ciphers (weak by design), CBC mode ciphers (vulnerable to padding oracle attacks in many implementations), and static RSA key exchange (no forward secrecy).
Forward Secrecy
Forward secrecy means that compromising the server long-term private key does not compromise past sessions. ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) and DHE (Diffie-Hellman Ephemeral) key exchanges provide forward secrecy.
Verify that your server prioritizes ECDHE cipher suites over static RSA. If RSA key exchange is still enabled, disable it.
Certificate Audit
Check expiration. Monitor certificate expiration dates and renew before they expire. Automated certificate management (Let's Encrypt, ACME protocol) prevents expiration surprises.
Verify the chain. Ensure your server sends the complete certificate chain (leaf + intermediates). A missing intermediate certificate causes validation failures in some clients.
Check key strength. RSA keys should be at least 2048 bits (4096 preferred). ECDSA keys should use P-256 or P-384 curves.
Verify SANs. Ensure the Subject Alternative Names (SANs) cover all hostnames your server responds to. Wildcard certificates should not be overused -- they expand the impact of key compromise.
Check revocation configuration. Ensure OCSP stapling is enabled so clients can verify certificate revocation status without contacting the CA directly.
HTTP Security Headers
TLS configuration extends beyond the connection itself to HTTP headers that enforce security policies:
Strict-Transport-Security (HSTS). Tells browsers to always use HTTPS for your domain. Set max-age to at least one year and include includeSubDomains if all subdomains support HTTPS.
Content-Security-Policy. Prevents mixed content and restricts resource loading to HTTPS.
Automated Monitoring
TLS configuration is not a one-time task. Certificates expire, new vulnerabilities are discovered, and configuration changes can introduce regressions. Implement automated monitoring:
- Certificate expiration alerts (30 days, 14 days, 7 days before expiration)
- Regular cipher suite scans to detect configuration drift
- TLS version compliance checks after server updates
- HSTS preload list submission for critical domains
How Safeguard.sh Helps
Safeguard.sh monitors the TLS libraries and configurations across your application portfolio. Our platform detects vulnerable TLS library versions, flags insecure default configurations in web frameworks, and tracks certificate status. Combined with comprehensive SBOM generation, Safeguard.sh ensures your encryption infrastructure is properly configured and continuously monitored.