TLS

TLS stands for Transport Layer Security, the protocol that encrypts a network connection and lets the client verify who it is talking to. The current version is TLS 1.3. It first appeared as RFC 8446 in August 2018 and is now specified by RFC 9846 (July 2026), which also obsoletes RFC 5246, the TLS 1.2 document. Versions 1.0 and 1.1 were formally deprecated by RFC 8996 in March 2021. HTTPS is HTTP carried over TLS, and WebSocket connections use it too through the wss scheme.

How it works

A TLS connection starts with a handshake that agrees on a version and a cipher suite, authenticates the server with a certificate, and derives shared session keys. After that, application data travels in encrypted records.

In TLS 1.3 the client sends a ClientHello that includes a key_share and a supported_versions extension. The server answers with a ServerHello, and everything after that is encrypted: EncryptedExtensions, Certificate, CertificateVerify and Finished. The client replies with its own Finished and can send application data. That is one round trip before data flows.

TLS 1.2 needs a second round trip. With an ECDHE suite, the server sends ServerHello, Certificate, ServerKeyExchange and ServerHelloDone. The client sends ClientKeyExchange, ChangeCipherSpec and Finished, and the server answers with ChangeCipherSpec and its own Finished.

A cipher suite names the algorithms in use:

• TLS 1.3 suites only describe record protection and a hash. RFC 9846 keeps the five that RFC 8446 defined: TLS_AES_128_GCM_SHA256 (0x1301), TLS_AES_256_GCM_SHA384 (0x1302), TLS_CHACHA20_POLY1305_SHA256 (0x1303), TLS_AES_128_CCM_SHA256 (0x1304) and TLS_AES_128_CCM_8_SHA256 (0x1305). A compliant application must implement the first one.
• TLS 1.2 suites also name key exchange and authentication, for example TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.
• Forward secrecy: TLS 1.3 removed static RSA and static Diffie-Hellman suites, so every public-key key exchange gives forward secrecy.

The commands below connect to a local openssl s_server with a self-signed certificate and show the version and cipher each handshake chose, then the TLS 1.3 handshake message order. The awk filter keeps only the direction and the message name from the -msg trace.

$ openssl s_client -connect localhost:4433 -CAfile c.pem -tls1_3 </dev/null 2>/dev/null | grep "^New,"
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
$ openssl s_client -connect localhost:4433 -CAfile c.pem -tls1_2 </dev/null 2>/dev/null | grep "^New,"
New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384
$ openssl s_client -connect localhost:4433 -CAfile c.pem -tls1_3 -msg </dev/null 2>/dev/null | awk '/Handshake/ {print $1, $NF}'
>>> ClientHello
<<< ServerHello
<<< EncryptedExtensions
<<< Certificate
<<< CertificateVerify
<<< Finished
>>> Finished

Which TLS versions are still allowed?

Only TLS 1.2 and TLS 1.3 should be negotiated. RFC 8996 says implementations must not negotiate TLS 1.0 or TLS 1.1, and it moved both specifications to Historic status. It cites the lack of AEAD cipher suites, which arrived only in TLS 1.2, and handshake integrity that depends on SHA-1. TLS 1.0 also lacks a per-record initialization vector for CBC suites.

Common pitfalls

• Leaving TLS 1.0 and 1.1 enabled: this contradicts RFC 8996. Set the minimum version to TLS 1.2 on servers and load balancers.
• Treating the version number literally: a TLS 1.3 ClientHello carries legacy_version 0x0303, the TLS 1.2 value, and signals 1.3 through the supported_versions extension. Code that reads only the legacy field will report it as TLS 1.2.
• Sending unsafe requests as 0-RTT data: early data is not forward secret and has no non-replay guarantee between connections. Allow it only for requests that are safe to replay.
• Confusing the OpenSSL name with the standard name: OpenSSL prints ECDHE-RSA-AES256-GCM-SHA384 for TLS 1.2, which openssl ciphers -stdname maps to TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. Configuration files may expect either form.
• Testing through a TLS-intercepting proxy: openssl s_client then shows the proxy's certificate and negotiated parameters, not the origin server's. Check the issuer line in the certificate chain before trusting the result.
• Forcing an old version from a modern client: OpenSSL 3.0.13 with default settings refused -tls1_1 locally with "no protocols available". OpenSSL 3.0 allows TLS 1.0 and 1.1 only at security level 0, so this failure is the client's own policy and says nothing about the server.

Related terms

• HTTPS — HTTP running over a TLS connection.
• HTTP — the application protocol most often carried inside TLS.
• SHA-256 — the hash named in suites such as TLS_AES_128_GCM_SHA256.
• HMAC — the message authentication construction used by the HKDF key derivation in TLS 1.3.
• WebSocket — encrypted wss connections perform a TLS handshake before the WebSocket handshake.

See also

• Term: HTTPS — what TLS looks like to a browser, including certificates and the padlock.