Skip to content
Tech HistoryDeep Dive Published Updated 8 min readViews unavailable

From SSL to TLS 1.3: A Standards Timeline for the Secure Channel

Trace SSL's transition to TLS and follow TLS 1.0 through the 2026 TLS 1.3 revision, deprecation rules, and current IETF guidance.

The web’s secure transport did not arrive as one finished protocol. Netscape developed the Secure Sockets Layer (SSL) protocol for browser-server communication; the IETF then standardized Transport Layer Security (TLS) as a distinct protocol with a related but not wire-compatible lineage. The standards record is more reliable than the shorthand claim that TLS is simply a new name for SSL. RFC 2246 says TLS 1.0 was based on SSL 3.0, but also documents differences significant enough that the two versions do not interoperate directly.

This distinction matters because protocol names are often used loosely in product interfaces and operational conversations. “SSL certificate” is still a common informal label for a public-key certificate used with TLS, but that phrase does not mean a current server should negotiate SSL. Certificate formats and the negotiated record protocol are separate parts of a connection. A certificate can remain the authentication credential while the peers negotiate a modern TLS version.

One secure channel, two cooperating layers

TLS provides an authenticated, integrity-protected channel and, after setup, confidentiality for application data. It is commonly carried over a reliable byte-stream transport such as TCP, while application protocols such as HTTPS, IMAP, and SMTP define how to begin the TLS handshake and what identities to authenticate. TLS itself does not decide that an arbitrary hostname is trustworthy; the application protocol and implementation must define certificate validation and identity checks correctly.

The handshake negotiates a protocol version and cryptographic parameters, authenticates the server and optionally the client, and derives traffic keys. The record protocol then protects application data with those negotiated keys. This separation lets multiple application protocols reuse TLS without inventing a new encryption protocol for every service, but it also means a successful cryptographic handshake is only one part of a secure application connection. The client still needs to validate the intended service identity and the application must use the channel appropriately.

A standards timeline, not a rename

Era and specification What changed in the standards record
SSL 3.0 lineage Netscape’s published design supplied a foundation for TLS, but SSL and TLS were distinct protocol versions.
TLS 1.0, RFC 2246 (January 1999) Formalized the IETF protocol derived from SSL 3.0, with changes that prevented direct wire interoperability.
TLS 1.1, RFC 4346 (April 2006) Clarified the protocol and introduced explicit CBC initialization vectors, among other security and editorial changes.
TLS 1.2, RFC 5246 (August 2008) Extended cryptographic negotiation and later became the long-lived compatibility version for many deployments.
TLS 1.3, RFC 8446 (August 2018) Restructured handshakes, pruned legacy algorithms, and added optional 0-RTT early data with replay tradeoffs.
TLS 1.3, RFC 9846 (July 2026) Replaced RFC 8446 while keeping the TLS 1.3 version number; tightened requirements and clarified implementation behavior.

RFC 4346 describes TLS 1.1 as a revision with security improvements and clarifications. Among its specific changes, it replaced an implicit CBC initialization vector with an explicit one and changed padding-error handling. Such a change illustrates how an incremental version can respond to attacks without replacing the whole record and handshake architecture. It should not be read as evidence that TLS 1.1 is suitable for current deployment: later IETF policy deprecated it.

TLS 1.2 continued the same broad architecture while supporting newer cryptographic options. A version number alone does not tell an operator which cipher suites are enabled, whether the implementation has been patched, or whether the server chose a safe configuration. TLS 1.2’s flexibility helped interoperability across a wide installed base, but also left administrators with more legacy choices to disable and made strong configurations dependent on policy and implementation details.

TLS 1.3 was a larger redesign. Its cipher suites are limited to authenticated-encryption algorithms and describe record protection separately from authentication and key exchange. Static RSA key exchange was removed; the remaining public-key-based key exchanges provide forward secrecy. The protocol also encrypts handshake messages after ServerHello, which protects more negotiation details from passive observers. These are protocol changes, not just new default cipher-suite strings.

Handshake latency and the 0-RTT tradeoff

A normal full TLS 1.3 handshake is designed to let the client and server begin protected application traffic after one round trip of handshake messages, assuming the network and application exchange proceed normally. That does not mean every HTTPS request takes one round trip from a cold start: DNS lookup, TCP setup, certificate and application behavior, packet loss, and additional redirects can add latency outside the TLS handshake itself.

TLS 1.3 also defines early data for some resumed connections using a pre-shared key. A client can send application data with its first flight, which is the source of the “0-RTT” label. This mode has weaker replay guarantees than ordinary post-handshake application data: an attacker may replay captured early data under specified conditions. An application should only permit it for operations that are safe to repeat and must follow its protocol’s replay-handling guidance. Saving a network round trip is not a blanket reason to enable early data for state-changing requests.

Session resumption also should not be confused with an unauthenticated shortcut. It relies on previously established keying material and protocol-defined tickets or PSKs; endpoints still need to protect ticket keys and apply appropriate lifetime and server-side policies. A server may reject early data or a resumption attempt and continue through a full handshake. These are negotiated protocol paths, not proof that each connection has identical latency or risk.

Deprecation changed what “current TLS” means

RFC 8996 formally deprecated TLS 1.0 and TLS 1.1 in 2021 and moved their specifications to Historic status. The reasons included obsolete cryptographic capabilities, lack of modern recommended authenticated-encryption options in those versions, and the maintenance and configuration burden of keeping old versions available. Enabling TLS 1.0 or 1.1 for a legacy client should therefore be treated as a documented compatibility exception with a retirement plan, not as an ordinary secure default.

As of this article’s October 2026 update, RFC 8446 is no longer the latest TLS 1.3 specification. RFC 9846 replaces it, retains the TLS 1.3 version number and wire compatibility, and tightens and clarifies requirements based on implementation experience. Its updates include forbidding reuse of key-share values between connections, clarifying key derivation and key-usage limits, and describing the use of key-encapsulation mechanisms. Older references to RFC 8446 remain historically correct for the original 2018 TLS 1.3 specification, but implementers should consult RFC 9846 for the current text.

The policy landscape also changed in 2026. RFC 9851 puts TLS 1.2 into feature freeze, allowing only urgent security fixes and narrowly specified registry additions. RFC 9852 updates the TLS best-current-practice guidance: a new protocol using TLS must require TLS 1.3; TLS 1.2 may be included as a non-default option when deployment needs justify it. The separate RFC 10015 deprecates RSA and finite-field Diffie-Hellman key exchanges in TLS 1.2 and discourages static elliptic-curve Diffie-Hellman. These updates revise RFC 9325, so citing that earlier best-practice document by itself is not a complete account of current guidance.

This does not mean every existing service should disable TLS 1.2 immediately. Current IETF rules distinguish new protocol design from deployment compatibility. For a new protocol, RFC 9852 sets TLS 1.3 as the requirement. Existing application protocols may still need carefully configured TLS 1.2 while clients and libraries transition. The right policy depends on the protocol’s current requirements, client population, platform support, and the newer RFCs that update the older ones.

Read the specification before repeating folklore

The publication date of a standard does not establish when a browser, server, or operating system implemented it, and implementation support does not establish which version a particular connection negotiated. Distinguish at least three facts in a historical or incident report: the protocol’s original publication, the later status of that document, and the actual negotiated version and configuration observed on the endpoint.

Likewise, a TLS 1.3 label is not a complete security assessment. Verify the current TLS library and configuration, negotiated protocol and cipher suite, certificate chain and service identity, resumption behavior, and whether the application has a safe policy for any early data. For present-day deployment recommendations, use the RFC Editor status and the latest BCP updates rather than copying an old configuration guide. Protocol history explains how the ecosystem arrived here; it does not replace an up-to-date configuration review.

Related:

Sources:

Comments