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. The boundary between deprecated SSL versions and permissible TLS versions is not merely technical — it carries direct compliance weight under federal standards enforced by agencies including the National Institute of Standards and Technology (NIST) and the Payment Card Industry Security Standards Council (PCI SSC). Professionals working in encryption services and provider providers or compliance-driven security architecture will find this a structured reference for version-level decision-making.

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 published standard, TLS 1.3, is defined in RFC 8446 (IETF, 2018). SSL — developed by Netscape in the 1990s — preceded TLS and shares its conceptual architecture but differs substantially in cryptographic construction. SSL versions 2.0 and 3.0 are formally deprecated; SSL 2.0 was prohibited by RFC 6176 (IETF, 2011), and SSL 3.0 by RFC 7568 (IETF, 2015).

The scope of TLS/SSL governance extends across virtually every sector that transmits sensitive data electronically. Federal agencies operating under NIST SP 800-52 Rev. 2 are required to support TLS 1.2 at minimum and are directed toward TLS 1.3 for new implementations. The Payment Card Industry Data Security Standard (PCI DSS), version 4.0 published by the PCI Security Standards Council, prohibits TLS 1.0 and SSL in all cardholder data environments. Healthcare entities subject to the HIPAA Security Rule (45 CFR Part 164) are not prescribed a specific TLS version by the rule text itself, but NIST guidance and HHS enforcement position make TLS 1.2 or higher the operative floor for covered entities. The scope therefore encompasses web servers, load balancers, VPN endpoints, mail transfer agents, and any API gateway transmitting regulated data. For a broader orientation to the encryption service sector, see the .

Core mechanics or structure

The TLS handshake is the negotiation sequence that establishes a secure session before any application data is transmitted. The mechanics differ between TLS 1.2 and TLS 1.3 in ways that have direct security and performance implications.

TLS 1.2 Handshake (as defined in RFC 5246):
The client sends a ClientHello message advertising supported cipher suites, compression methods, and TLS version. The server responds with a ServerHello selecting from those options, followed by its certificate and optionally a ServerKeyExchange message. The client verifies the certificate against a trusted Certificate Authority (CA), generates a pre-master secret, and encrypts it with the server's public key. Both sides derive session keys from this pre-master secret using a pseudorandom function (PRF). The handshake requires 2 round trips before application data flows.

TLS 1.3 Handshake (as defined in RFC 8446):
TLS 1.3 consolidates the handshake to 1 round trip (1-RTT) under normal conditions by moving key exchange to the ClientHello itself, using Diffie-Hellman ephemeral (DHE) or Elliptic Curve Diffie-Hellman ephemeral (ECDHE) key shares. A 0-RTT (zero round-trip) resumption mode is also available for reconnecting clients, though it carries replay attack risk. TLS 1.3 eliminates RSA static key exchange entirely, making forward secrecy mandatory rather than optional. The handshake encrypts more of its own metadata compared to TLS 1.2, reducing exposure of certificate details during negotiation.

Cipher suite structure:
In TLS 1.2, a cipher suite specifies 4 components: key exchange algorithm, authentication algorithm, bulk encryption algorithm, and message authentication code (MAC) algorithm. An example is TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. In TLS 1.3, cipher suites are reduced to 2 components — bulk cipher and hash function (e.g., TLS_AES_256_GCM_SHA384) — because key exchange and authentication are handled separately through named groups and signature algorithms.

Certificate infrastructure:
TLS relies on X.509 certificates issued by Certificate Authorities operating under the CA/Browser Forum Baseline Requirements. Server certificates carry a public key, identity information, and a CA signature. The chain of trust runs from the server certificate through intermediate CAs to a root CA embedded in the client's trust store. Certificate validity periods were reduced by the CA/Browser Forum to a maximum of 398 days for publicly trusted certificates, a constraint formalized in 2020 ballot SC31.

Causal relationships or drivers

The version deprecation timeline for SSL and early TLS versions is driven by specific documented vulnerabilities rather than arbitrary policy cycles.

Regulatory drivers operate on a parallel track. NIST SP 800-52 Rev. 2 sets the federal floor and is incorporated by reference in FedRAMP authorization requirements. PCI DSS 4.0 drives commercial adoption through contractual enforcement by card brands. The FIPS 140-3 validation program, administered by NIST's Cryptographic Module Validation Program (CMVP), governs which cryptographic modules can be used in federal systems, indirectly constraining which TLS implementations are permissible.

Classification boundaries

TLS and SSL versions fall into three operational categories based on current regulatory and standards posture:

Prohibited (no compliant use case exists):
- SSL 2.0 — prohibited by RFC 6176; no known compliant deployment context
- SSL 3.0 — prohibited by RFC 7568; POODLE vulnerability renders it indefensible
- TLS 1.0 — prohibited in PCI DSS cardholder data environments; prohibited for federal use under NIST SP 800-52 Rev. 2 except in documented legacy interoperability cases with time-limited exceptions

Permitted with restrictions (legacy interoperability only):
- TLS 1.1 — deprecated by RFC 8996 (IETF, 2021); NIST SP 800-52 Rev. 2 does not include TLS 1.1 as a recommended configuration; no new implementations should use TLS 1.1

Recommended or required:
- TLS 1.2 — minimum floor for federal agency servers under NIST SP 800-52 Rev. 2; must use AEAD cipher suites and forward-secret key exchange to satisfy current guidance; required for PCI DSS compliance
- TLS 1.3 — preferred version under NIST SP 800-52 Rev. 2; mandatory for new federal server deployments; eliminates legacy cipher suite categories entirely

Cipher suite classification within TLS 1.2 further divides into: AEAD-based (AES-GCM, ChaCha20-Poly1305 — recommended), CBC-based (AES-CBC — conditionally permitted with mitigations), and explicitly prohibited suites including RC4, 3DES (SWEET32 attack, CVE-2016-2183), NULL encryption, and anonymous (non-authenticated) key exchange. For context on how these cipher choices fit within the broader encryption algorithm landscape, see the how to use this encryption resource reference page.

Tradeoffs and tensions

TLS 1.3 adoption vs. enterprise inspection infrastructure:
TLS 1.3's elimination of RSA static key exchange and mandatory use of ephemeral key exchange prevents passive decryption of recorded traffic. Enterprise Security Information and Event Management (SIEM) systems and Data Loss Prevention (DLP) appliances that relied on pre-shared RSA private keys to decrypt TLS 1.2 traffic for inspection cannot use the same technique with TLS 1.3. Organizations must deploy TLS interception proxies that terminate and re-originate TLS connections — introducing a new trust boundary and potential single point of failure.

0-RTT resumption performance vs. replay attack surface:
TLS 1.3's 0-RTT mode reduces latency for reconnecting clients, benefiting high-frequency API environments. However, 0-RTT data is not protected against replay attacks; an attacker who captures a 0-RTT record can retransmit it. RFC 8446 explicitly restricts 0-RTT to non-idempotent operations and requires application-layer replay protection. Implementations that enable 0-RTT without application-layer controls introduce vulnerability.

Certificate authority trust model vs. key pinning:
HTTP Public Key Pinning (HPKI, RFC 7469) was a mechanism to bind a specific certificate or CA key to a domain, preventing MITM attacks via rogue CA certificates. Google deprecated HPKI support in Chrome 67 (2018) due to the operational risk of misconfiguration causing site outages. The replacement, Certificate Transparency (CT), defined in RFC 9162, shifts assurance from pinning to public auditability of issued certificates, but does not prevent issuance of unauthorized certificates in real time.

FIPS 140 compliance vs. modern cipher support:
FIPS 140-2 validated modules may lag behind TLS 1.3 cipher suite support timelines. Organizations requiring FIPS 140-2 validated cryptography for federal use must verify that their TLS library's validated module boundary covers TLS 1.3 operations, which was not uniformly available in earlier FIPS 140-2 module validations. FIPS 140-3, which aligns with ISO/IEC 19790, provides better coverage but module validation backlogs at NIST's CMVP can create gaps between algorithm availability and validated module availability.

Common misconceptions

"SSL and TLS are interchangeable terms for the same thing."
SSL and TLS are related but distinct protocols with incompatible handshake formats. TLS 1.0 was designed to be backward-compatible with SSL 3.0 in specific negotiation modes, but TLS 1.3 has no SSL compatibility. Referring to TLS connections as "SSL" is a colloquial habit inherited from early web tooling (openssl, ssl_certificate directives) — it does not reflect protocol equivalence. RFC 7568 explicitly prohibits SSL 3.0 while TLS 1.2 and 1.3 remain active standards.

"A valid HTTPS padlock icon means the connection uses a secure TLS version."
Browser padlock indicators confirm that a certificate was presented and accepted and that the connection uses TLS, not that a specific version or cipher suite is in use. A server configured to accept TLS 1.0 will display a padlock in most browsers. Version enforcement must be verified through server configuration audit, not browser UI. Tools such as SSL Labs' server test (Qualys) or nmap --script ssl-enum-ciphers enumerate the actual protocol versions and cipher suites accepted.

"TLS 1.3 is backwards-compatible with TLS 1.2 clients."
TLS version negotiation is designed so that a TLS 1.3 server can negotiate down to TLS 1.2 with a client that does not support TLS 1.3. However, a server configured to require TLS 1.3 minimum will reject TLS 1.2 clients entirely. Backwards compatibility exists at the negotiation protocol level, not as a guarantee that all clients will succeed. Misconfigured middleboxes — such as firewalls and load balancers that perform TLS inspection — were documented to interfere with TLS 1.3 negotiation, a problem IETF addressed in the TLS 1.3 specification through a version disguise mechanism using a legacy version field value.

"Disabling older TLS versions is sufficient to harden a TLS deployment."
Version selection is one layer of configuration. A TLS 1.2 server configured with 1024-bit DHE parameters, RC4 cipher suites, or SHA-1 signed certificates remains vulnerable independent of version. NIST SP 800-52 Rev. 2 specifies both minimum version floors and approved cipher suite lists. Version enforcement without cipher suite restriction and certificate hygiene does not constitute a hardened deployment under federal guidance.

Checklist or steps (non-advisory)

The following sequence describes the configuration verification process for TLS deployments against NIST SP 800-52 Rev. 2 and PCI DSS 4.0 requirements. This is a structural enumeration of steps, not professional advice.

  1. Inventory all TLS-terminating endpoints — web servers, load balancers, reverse proxies, mail transfer agents, VPN concentrators, and API gateways. Document software stack and version for each.

  2. Enumerate accepted protocol versions — use a protocol scanning tool (e.g., openssl s_client, nmap ssl-enum-ciphers, or Qualys SSL Labs) to confirm which SSL/TLS versions each endpoint will negotiate.

  3. Identify prohibited protocol versions — flag any endpoint accepting SSL 2.0, SSL 3.0, TLS 1.0, or TLS 1.1. These require remediation under NIST SP 800-52 Rev. 2 and PCI DSS 4.0.

  4. Enumerate accepted cipher suites for TLS 1.2 endpoints — verify that only AEAD cipher suites with forward-secret key exchange (ECDHE or DHE) are enabled. Remove RC4, 3DES, NULL, EXPORT-grade, and anonymous cipher suites.

  5. Verify DHE parameter strength — if DHE cipher suites are retained, confirm key sizes of 2048 bits or greater. 1024-bit DHE is vulnerable to LOGJAM (CVE-2015-4000).

  6. Verify certificate chain validity — confirm certificate validity period does not exceed 398 days, that the issuing CA is included in the Certificate Transparency log, and that SHA-1 signatures are absent from the chain.

  7. Evaluate TLS 1.3 readiness — confirm whether the TLS library version in use supports TLS 1.3. For federal systems, verify FIPS

References

Read Next

Encryption Listings ANA › Professional Services Authority Authority › National Cyber Authority Authority › Encryption Authority Encryption Providers The providers indexed on Encryption... Encryption Directory: Purpose and Scope ANA › Professional Services Authority Authority › National Cyber Authority Authority › Encryption Authority Encryption Network: Purpose and Scope The Encryption... AES Encryption Standard: Specifications and Applications ANA › Professional Services Authority Authority › National Cyber Authority Authority › Encryption Authority AES Encryption Standard: Specifications and Applications...