Weak TLS/SSL Configuration

Weak TLS (Transport Layer Security) and SSL (Secure Sockets Layer) configuration refers to the use of deprecated protocol versions, insecure cipher suites, weak key exchange parameters, or improperly configured certificates on services that rely on encrypted communications. This includes web servers, mail servers (SMTP, IMAP, POP3), VPN gateways, database connections, LDAPS, and any other service that uses TLS/SSL for transport encryption. Common issues include support for SSLv3, TLS 1.0, and TLS 1.1 (all deprecated), the use of cipher suites containing NULL, export-grade, DES, 3DES, or RC4 algorithms, and RSA key exchange without forward secrecy.

The TLS protocol has undergone significant evolution to address discovered vulnerabilities. SSLv2 and SSLv3 are fundamentally broken (DROWN, POODLE attacks). TLS 1.0 and 1.1 are deprecated by all major browser vendors and standards bodies due to weaknesses in their handshake mechanisms and supported cipher suites. Modern best practice mandates TLS 1.2 as a minimum with TLS 1.3 preferred, using only AEAD cipher suites (AES-GCM, ChaCha20-Poly1305) with ECDHE or DHE key exchange for forward secrecy.

Certificate-related issues compound protocol and cipher weaknesses. Common certificate problems include expired certificates, self-signed certificates used in production, certificates with weak signature algorithms (SHA-1, MD5), certificates with insufficient key sizes (RSA < 2048 bits), missing certificate chain intermediates, and hostname mismatches. Each of these issues can enable man-in-the-middle attacks, degrade user trust, or cause application failures that lead to users accepting insecure connections.

Attackers exploit weak TLS configurations through several vectors. Protocol downgrade attacks force a connection to use a weaker protocol version that has known vulnerabilities. The POODLE attack (CVE-2014-3566) exploits SSLv3's CBC padding to decrypt ciphertext one byte at a time. BEAST targets TLS 1.0's predictable CBC initialisation vectors. DROWN (CVE-2016-0800) uses SSLv2 support on any server sharing a certificate to decrypt TLS connections. Modern downgrade attacks use techniques like the Raccoon attack (CVE-2020-1968) against DH key exchange in TLS 1.2.

Weak cipher suites enable various cryptographic attacks. Export-grade ciphers (FREAK, Logjam) use intentionally weakened cryptographic parameters (512-bit RSA, 512-bit DH) that can be factored in minutes. RC4 has known biases that enable plaintext recovery with sufficient captured ciphertext (CVE-2015-2808). NULL cipher suites provide no encryption at all, transmitting data in cleartext while still going through the TLS handshake. Sweet32 (CVE-2016-2183) targets 64-bit block ciphers like 3DES, enabling plaintext recovery through birthday attacks on long-lived connections.

Without forward secrecy (provided by ECDHE or DHE key exchange), all past and future communications can be decrypted if the server's private key is ever compromised. An attacker who captures encrypted traffic and later obtains the private key (through server compromise, legal compulsion, or a vendor vulnerability) can decrypt every previously recorded session. Nation-state adversaries are known to capture and store encrypted traffic at scale, waiting for future decryption capabilities. TLS 1.3 mandates forward secrecy for all cipher suites, eliminating this risk when properly deployed.

• Decryption of encrypted communications through cryptographic attacks against weak protocols and cipher suites (POODLE, BEAST, DROWN, Sweet32)
• Man-in-the-middle attacks enabled by protocol downgrade, weak key exchange, or certificate validation failures
• Loss of forward secrecy allowing historical decryption of captured traffic if the server private key is compromised
• Credential theft through interception of authentication credentials transmitted over weakened TLS connections
• Regulatory non-compliance, as PCI DSS explicitly prohibits SSLv3, TLS 1.0, and requires strong cryptography for cardholder data in transit
• User trust degradation and browser security warnings for sites with certificate issues or deprecated protocol support
• Data integrity compromise through manipulation of weakly protected communications channels

1. Disable SSLv2, SSLv3, TLS 1.0, and TLS 1.1 on all services. Configure TLS 1.2 as the minimum supported version, with TLS 1.3 enabled and preferred where supported by the platform
2. Configure cipher suite ordering to prefer strong AEAD ciphers with forward secrecy. For TLS 1.2, use: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305
3. Explicitly disable all insecure cipher suites: NULL, export, anonymous, DES, 3DES, RC4, and any cipher suite without forward secrecy (static RSA key exchange)
4. Use ECDHE key exchange with curve P-256 (secp256r1) or X25519, and DH parameters of at least 2048 bits if DHE is required. Generate custom DH parameters: openssl dhparam -out dhparams.pem 4096
5. Deploy certificates with RSA keys of at least 2048 bits (4096 preferred) or ECDSA keys with P-256 or P-384 curves, signed with SHA-256 or stronger hash algorithms
6. Implement HSTS (HTTP Strict Transport Security) with a minimum max-age of 31536000 seconds and include subdomains: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
7. Configure OCSP stapling to improve certificate revocation checking performance and reliability, and ensure the complete certificate chain is served by the server
8. Establish automated certificate monitoring and renewal using tools like certbot (Let's Encrypt) or commercial certificate lifecycle management platforms to prevent certificate expiration

The primary tool for comprehensive TLS/SSL testing is testssl.sh, which performs an exhaustive analysis of all TLS-related configuration aspects: testssl.sh --wide --color 3 target:port. This tests protocol versions, cipher suites, key exchange parameters, certificate details, known vulnerabilities (Heartbleed, POODLE, DROWN, ROBOT, etc.), and provides severity ratings. For batch scanning, use: testssl.sh --file targets.txt --wide --json-pretty to generate structured output. The sslyze tool provides similar functionality with Python scripting capabilities: sslyze target:port --regular.

Supplement automated tools with Nmap NSE scripts for specific checks: nmap -p 443 --script ssl-enum-ciphers,ssl-cert,ssl-heartbleed,ssl-poodle,ssl-dh-params target. The ssl-enum-ciphers script grades each cipher suite and identifies the weakest accepted ciphers. Use OpenSSL directly for targeted testing: openssl s_client -connect target:443 -tls1 (test TLS 1.0 support), openssl s_client -connect target:443 -ssl3 (test SSLv3), and openssl s_client -connect target:443 -cipher 'NULL:eNULL:aNULL' (test NULL ciphers). Check certificate details: openssl s_client -connect target:443 | openssl x509 -noout -text.

Test all TLS-wrapped services, not just HTTPS. Check SMTPS (465/587), IMAPS (993), POP3S (995), LDAPS (636), FTPS (990), database connections (MySQL 3306, PostgreSQL 5432 with TLS), and any custom application ports using TLS. Use STARTTLS-aware testing where applicable: testssl.sh --starttls smtp target:25. For each finding, document the specific protocol version or cipher suite, the known vulnerability it enables, the affected service and host, and reference the appropriate standard (Mozilla TLS configuration guidelines, NIST SP 800-52, PCI DSS requirements). Compare the results against the Mozilla Server Side TLS guidelines, categorising the configuration as Modern, Intermediate, or Old.