TLS versions: 1.0 to 1.3, and which to enable

TLS versions are the successive revisions of the protocol behind every TLS connection. Four exist, two are still allowed, and the current one, TLS 1.3, changed more than any revision before it. This page is about the versions themselves: what each one is, what changed, and how to check and set what a server accepts.

Which versions exist, and which are still allowed

The versions before them were called SSL and are deprecated as well; how the name changed is covered on SSL vs TLS. RFC 8996 formally deprecates TLS 1.0 and 1.1, and current browsers refuse them. A server today should accept TLS 1.2 and TLS 1.3 and nothing older.

What TLS 1.3 changed

TLS 1.3 is not an incremental revision. It removed the options that caused most of the trouble in earlier versions and rebuilt the handshake around fewer choices.

• A shorter handshake. A full handshake completes in one round trip instead of two, because the client sends its key share in the first message. The steps are on the TLS handshake.

• Only forward-secret key exchange. Static RSA and static Diffie–Hellman key exchange are gone; every full handshake uses an ephemeral exchange, so a stolen server key cannot decrypt recorded sessions. See forward secrecy.

• Only authenticated encryption. The remaining cipher suites all use AEAD constructions. Older ciphers and modes that earlier versions still allowed cannot be negotiated at all.

• More of the handshake encrypted. Everything after the ServerHello, including the server's certificate and its ALPN protocol choice, travels encrypted, so an observer sees less of the exchange.

• Built-in downgrade protection. The server signals in its random value when it is being pushed to an older version, and a TLS 1.3 client detects it.

Is TLS 1.2 still safe?

Yes, when configured with modern cipher suites. TLS 1.2 itself is not deprecated; the risk is in the options it still permits, such as non-forward-secret key exchange and older ciphers. A TLS 1.2 configuration that allows only ephemeral key exchange and AEAD ciphers is sound, and keeping it enabled lets older clients connect while newer ones negotiate TLS 1.3.

How to check which versions a server accepts

Ask for each version in turn and see which handshakes complete:

$ openssl s_client -connect example.com:443 -servername example.com -tls1_3
$ openssl s_client -connect example.com:443 -servername example.com -tls1_2
$ openssl s_client -connect example.com:443 -servername example.com -tls1_1

The first two should complete; the third should fail. A scan lists everything at once:

$ nmap --script ssl-enum-ciphers -p 443 example.com

Check from outside, against the hostname visitors use. A configuration file says what was intended; the handshake says what is actually served, and behind a CDN or load balancer the two may be different machines.

How to set the versions

Web servers name the accepted versions in one directive. In nginx:

ssl_protocols TLSv1.2 TLSv1.3;

In Apache:

SSLProtocol -all +TLSv1.2 +TLSv1.3

Both directive names still say SSL; the values are what matter. Reload the server and repeat the checks above, because a directive in a file that is not loaded changes nothing.

0-RTT and its trade-off

TLS 1.3 also lets a returning client send its first request together with the ClientHello, using a key from a previous session. This "early data" saves a full round trip, but it can be replayed: an attacker who captures it can send it again. That is acceptable for requests that change nothing, such as fetching a page, and not for anything that does. Servers that enable early data should accept it only for safe requests.

FAQ