TLS and SSL Encryption Protocols: Versions and Configuration

Transport Layer Security (TLS) and its predecessor Secure Sockets Layer (SSL) define the dominant framework for encrypting data transmitted across networks, governing everything from HTTPS web traffic to email relay and API communications. This page covers the full protocol version history, the mechanics of handshake negotiation, the regulatory and compliance landscape that mandates specific version floors, and the configuration parameters that distinguish a hardened deployment from a vulnerable one. Understanding where SSL ends and TLS begins — and which versions remain permissible under federal standards — is foundational to any professional operating in data encryption in transit or compliance-driven security architecture.

• Definition and scope
• Core mechanics or structure
• Causal relationships or drivers
• Classification boundaries
• Tradeoffs and tensions
• Common misconceptions
• Checklist or steps (non-advisory)
• Reference table or matrix

Definition and scope

TLS is a cryptographic protocol standardized by the Internet Engineering Task Force (IETF) that provides authentication, confidentiality, and data integrity for communications over a computer network. The current authoritative specification is RFC 8446 (TLS 1.3), published in August 2018. SSL was the earlier Netscape-originated protocol family; SSL 2.0 and SSL 3.0 are the direct predecessors to TLS 1.0. Despite widespread colloquial use of "SSL" to describe active HTTPS connections, no version of SSL is considered cryptographically sound, and all three SSL versions have been formally deprecated.

The scope of TLS extends beyond web browsing. TLS secures SMTP with STARTTLS, LDAPS directory queries, FTPS file transfers, SIP voice communications, database connections, and inter-service API traffic in cloud environments. The NIST Cybersecurity Framework and companion publications treat TLS configuration as a component of the Protect function, specifically under the PR.DS (Data Security) category. Federal agencies operating under FISMA are bound by NIST SP 800-52 Rev 2, which sets minimum TLS version requirements for US government systems.

The regulatory perimeter for TLS version enforcement includes the Payment Card Industry Data Security Standard (PCI DSS), which prohibited TLS 1.0 for protecting cardholder data environments (PCI DSS v3.2.1, Requirement 4.1), HIPAA technical safeguard guidance, and the Federal Risk and Authorization Management Program (FedRAMP) baseline controls. More detail on those compliance frameworks appears at encryption compliance and US regulations.

Core mechanics or structure

The TLS handshake is the negotiation phase that establishes a secure session before any application data is exchanged. The handshake mechanics differ significantly between TLS 1.2 and TLS 1.3.

TLS 1.2 Handshake (simplified):
1. The client sends a ClientHello message listing supported cipher suites, TLS version, and a random nonce.
2. The server responds with ServerHello, selecting a cipher suite and sending its digital certificate for authentication.
3. Key exchange occurs — historically via RSA key encipherment or Diffie-Hellman (DHE/ECDHE).
4. Both parties derive session keys from the exchanged keying material plus random nonces.
5. Finished messages confirm the handshake integrity.

This process typically requires 2 round trips before application data flows.

TLS 1.3 Handshake:
TLS 1.3 mandates ephemeral key exchange (ECDHE or DHE only) and eliminates static RSA key exchange entirely. The result is a 1-RTT handshake for new sessions and a 0-RTT resumption option for sessions with prior state. 0-RTT carries replay attack risk and is not recommended for non-idempotent requests (RFC 8446, Section 2.3).

Cipher suites define the combination of: key exchange algorithm, authentication algorithm, bulk encryption cipher, and MAC/hash function. In TLS 1.2 a representative suite is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. TLS 1.3 decoupled cipher suites from key exchange; only 5 cipher suites are defined in TLS 1.3, all using AEAD (Authenticated Encryption with Associated Data) modes — primarily AES-GCM and ChaCha20-Poly1305. The AES encryption standard page covers the underlying block cipher mechanics.

Certificate authentication in TLS relies on the public key infrastructure chain of trust. The server presents a certificate signed by a recognized certificate authority, and the client validates that chain against its trusted root store. Mutual TLS (mTLS) extends this by requiring the client to also present a certificate, enabling bidirectional authentication critical in zero-trust architectures.

Causal relationships or drivers

The evolution from SSL 3.0 through TLS 1.3 was driven by the disclosure of exploitable vulnerabilities, not by planned protocol versioning cycles.

• POODLE (2014): Disclosed by Google researchers, POODLE exploited CBC padding oracle vulnerabilities in SSL 3.0, enabling decryption of secure cookies. This attack directly caused SSL 3.0 to be prohibited by RFC 7568.
• BEAST (2011): Exploited CBC chaining weaknesses in TLS 1.0 to recover plaintext. Mitigation required cipher suite reconfiguration rather than immediate protocol retirement.
• CRIME and BREACH (2012–2013): Demonstrated that TLS compression could leak session tokens via chosen-plaintext attacks. TLS 1.3 removed compression entirely.
• FREAK (2015) and Logjam (2015): Exposed export-grade cipher suites (512-bit RSA and 512-bit DH) as exploitable via downgrade attacks. Logjam demonstrated feasibility of DHE 1024-bit precomputation by state-level actors, prompting the IETF to require DHE key sizes of at least 2048 bits.
• DROWN (2016): Showed that servers supporting SSLv2 key exchange — even for non-HTTPS protocols — could decrypt TLS 1.2 sessions. Approximately 33% of HTTPS servers were vulnerable at the time of disclosure, per the DROWN Attack research team.

These cascading vulnerabilities created the compliance-driven deprecation timeline observable across PCI DSS, NIST SP 800-52, and FedRAMP. The secure socket layer deprecation reference covers that timeline in full.

Classification boundaries

TLS and SSL versions are not interchangeable or backward-compatible in their security properties. The classification breaks down as follows:

Prohibited (no compliant use case):
- SSL 2.0 — deprecated by RFC 6176 (2011); broken key exchange and MAC construction
- SSL 3.0 — deprecated by RFC 7568 (2015); POODLE-vulnerable
- TLS 1.0 — prohibited by PCI DSS for cardholder data environments; deprecated by RFC 8996 (2021)
- TLS 1.1 — deprecated by RFC 8996 (2021); no AEAD cipher suite support

Conditionally acceptable:
- TLS 1.2 — remains in use where TLS 1.3 is not yet supported; requires careful cipher suite restriction. NIST SP 800-52 Rev 2 permits TLS 1.2 for federal systems with approved cipher suites.

Recommended:
- TLS 1.3 — mandated by FedRAMP High baseline as the preferred protocol; required by NIST SP 800-52 Rev 2 as the minimum for new federal system deployments where feasible.

The FIPS 140 encryption standards framework intersects with TLS in that FIPS 140-2 and 140-3 validated cryptographic modules must be used in federal deployments, constraining cipher suite selection to FIPS-approved algorithms.

Tradeoffs and tensions

TLS 1.3 vs. enterprise inspection: TLS 1.3's mandatory ephemeral key exchange eliminates the ability to decrypt sessions using a static private key — a technique used by enterprise TLS inspection proxies (also called "man-in-the-middle" inspection appliances). Organizations relying on deep packet inspection for malware detection must deploy forward proxies that terminate and re-originate TLS sessions, introducing latency and certificate trust complexity.

0-RTT resumption: The 0-RTT feature of TLS 1.3 reduces handshake latency but introduces replay vulnerability. Application-layer idempotency checks are required before enabling 0-RTT for any state-modifying endpoint.

Certificate authority trust: Asymmetric encryption underpins certificate authentication, but the trust model depends entirely on the integrity of root certificate authorities. Incidents like the DigiNotar breach (2011) demonstrated that compromise of a single CA can undermine the entire PKI chain. Certificate Transparency (CT) logs, mandated by Chrome as of April 2018, address this by requiring public logging of all issued certificates.

Performance vs. security in cipher suite selection: AES-GCM performs efficiently on processors with AES-NI hardware acceleration. ChaCha20-Poly1305 is preferred for mobile and IoT endpoints lacking hardware acceleration, offering comparable security with better software-only performance. IoT device encryption considerations often turn on this tradeoff.

Quantum readiness: Current TLS handshake authentication and key exchange rely on RSA and elliptic curve algorithms, both vulnerable to Cryptographically Relevant Quantum Computers (CRQCs). NIST's post-quantum standardization process (completed with FIPS 203, 204, and 205 in 2024) produced algorithms being integrated into next-generation TLS configurations. See post-quantum cryptography for the migration landscape.

Common misconceptions

"The padlock icon confirms TLS 1.3."
The browser padlock indicates a TLS-encrypted connection, not a specific protocol version. The negotiated version can be verified in browser developer tools under the Security tab or via tools such as the SSL Labs Server Test (Qualys). TLS 1.0 sessions display the same padlock as TLS 1.3 sessions.

"SSL and TLS are the same protocol."
SSL 3.0 and TLS 1.0 share structural similarities but are not identical. The IETF explicitly renamed the protocol to TLS 1.0 when publishing RFC 2246 in 1999 to signal that TLS was not a simple upgrade of SSL 3.0. The underlying MAC construction differs, and they are not interoperable without downgrade negotiation.

"Disabling older TLS versions breaks backward compatibility with most users."
As of 2024, browser telemetry from sources including Google's Transparency Report shows TLS 1.2 or higher accounts for over 99% of HTTPS connections. Disabling TLS 1.0 and 1.1 affects a negligible fraction of modern clients; the compatibility cost is marginal for nearly all production deployments.

"A wildcard certificate secures all subdomains equally."
Wildcard certificates (*.example.com) cover one label depth of subdomains but do not cover the apex domain or multiple label depths. A wildcard for *.example.com does not cover sub.sub.example.com. Certificate scope boundaries are defined in RFC 5280.

"Self-signed certificates provide the same encryption as CA-issued certificates."
The bulk encryption and key exchange mechanics are equivalent, but self-signed certificates provide no third-party authentication. A client connecting to a server with a self-signed certificate cannot verify it is communicating with the intended party — only that the channel is encrypted from an unknown source.

Checklist or steps (non-advisory)

The following operational steps describe a standard TLS configuration audit sequence as documented in NIST SP 800-52 Rev 2 and the CIS Benchmark for TLS:

1. Enumerate all TLS-terminating endpoints — web servers, load balancers, API gateways, mail transfer agents, database connection strings.
2. Identify protocol versions in use — scan with a tool capable of SSLv2/SSLv3/TLS 1.0/1.1 detection (e.g., testssl.sh, nmap --script ssl-enum-ciphers, or the Qualys SSL Labs API).
3. Disable SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1 at the server/load balancer configuration layer.
4. Audit cipher suites for TLS 1.2 configurations — remove RC4, 3DES, NULL, EXPORT-grade, and anonymous DH suites. Retain ECDHE and DHE suites with AES-GCM or ChaCha20-Poly1305.
5. Enforce minimum DHE key size of 2048 bits — address Logjam-class downgrade exposure.
6. Enable HSTS (HTTP Strict Transport Security) with a max-age of at least 31,536,000 seconds and includeSubDomains where applicable. Submit to the HSTS preload list for public-facing properties.
7. Validate certificate chain completeness — confirm that intermediate certificates are served by the endpoint; missing intermediates cause validation failures on clients without cached trust stores.
8. Enable OCSP Stapling — reduces latency of revocation checking and prevents privacy leakage to certificate authorities during handshake.
9. Check for Certificate Transparency compliance — required by Chrome for certificates issued after April 2018; verify CT log inclusion.
10. Schedule certificate renewal before expiration — X.509 certificates issued after September 2020 carry a maximum validity of 398 days per CA/Browser Forum Baseline Requirements.
11. Document TLS configuration in system security plans — required for FedRAMP and FISMA-covered systems per NIST SP 800-18.
12. Retest after any server, load balancer, or library update — OpenSSL, BoringSSL, and NSS updates frequently alter default cipher suite ordering.

Reference table or matrix

Cipher Suite Comparison (TLS 1.2 Approved vs. Prohibited):