Only TLS 1.2+ enabled
Demonstrate that all systems handling encrypted network communications have disabled TLS versions prior to 1.2 and actively reject connection attempts using deprecated protocols.
Description
What this control does
This control mandates that all systems, applications, and network infrastructure exclusively use Transport Layer Security (TLS) version 1.2 or higher for encrypted communications, explicitly disabling older protocols including TLS 1.0, TLS 1.1, SSL 3.0, and SSL 2.0. Implementation typically involves configuration changes at web servers, load balancers, API gateways, application middleware, and client software to reject connections using deprecated cryptographic protocols. Enforcing TLS 1.2+ protects against protocol-level vulnerabilities such as POODLE, BEAST, and CRIME attacks while ensuring strong cipher suite availability.
Control objective
What auditing this proves
Demonstrate that all systems handling encrypted network communications have disabled TLS versions prior to 1.2 and actively reject connection attempts using deprecated protocols.
Associated risks
Risks this control addresses
- Man-in-the-middle attackers exploit protocol downgrade attacks (e.g., POODLE, BEAST) to force connections to use SSL 3.0 or TLS 1.0, enabling decryption of sensitive data
- Attackers leverage known vulnerabilities in TLS 1.0/1.1 cipher suites such as RC4 weaknesses or CBC-mode timing attacks to extract session tokens or credentials
- Compliance failures result in regulatory penalties when payment card data, healthcare information, or personal data is transmitted over protocols that fail PCI DSS, HIPAA, or GDPR cryptographic requirements
- Legacy protocol support creates attack surface for cipher suite negotiation exploits allowing adversaries to force weak encryption parameters
- Incident response complexity increases when forensic analysis must account for potentially compromised data transmitted via deprecated protocols with insufficient forward secrecy
- Third-party API integrations using older TLS versions expose data in transit to passive eavesdropping by network-positioned adversaries or malicious insiders with packet capture access
- Browser and client compatibility warnings erode user trust and expose organizations to social engineering attacks when users become desensitized to security warnings
Testing procedure
How an auditor verifies this control
- Obtain and review the organization's cryptographic standards policy and TLS configuration standards documentation to identify stated requirements for protocol versions
- Generate an inventory of all internet-facing and internal systems that provide TLS/SSL services including web servers, APIs, mail servers, VPN concentrators, and database listeners
- Execute automated scanning using tools such as Nmap with ssl-enum-ciphers script, SSLyze, or testssl.sh against a representative sample of at least 20% of identified endpoints across different system types
- Manually test connection attempts to critical systems using OpenSSL command-line client with explicit protocol flags (openssl s_client -tls1, -tls1_1) to verify rejection of deprecated protocols
- Review configuration files from web servers (Apache httpd.conf, Nginx nginx.conf, IIS applicationHost.config), load balancers, and API gateways to verify SSLProtocol or equivalent directives exclude TLS 1.0 and 1.1
- Interview system administrators and examine change management records to confirm configuration hardening procedures and validation testing performed during initial implementation and after system updates
- Test a sample of internal applications and services that communicate via encrypted channels to verify both client and server components enforce TLS 1.2+ requirements
- Analyze network traffic captures or TLS handshake logs from production systems over a 7-day period to confirm no successful connections negotiated protocols below TLS 1.2
Where this control is tested