TLS versions

TLS has gone through several versions, and the earlier ones have known design weaknesses. TLS 1.0 dates from 1999 and TLS 1.1 from 2006. Both depend on constructions that have been broken in practice over the years (attacks such as BEAST, and weaknesses in the hash functions and padding they use), and neither supports modern cipher suites. RFC 8996, published in 2021, formally deprecated them. All current browsers have long since removed support, so almost no legitimate visitor needs them.

A server that still accepts them is not usually vulnerable on its own to a casual attacker. The risk is twofold: it gives an attacker who can interfere with the connection a weaker version to try to force a downgrade to, and it fails compliance regimes outright. PCI DSS, for example, has prohibited early TLS for payment pages for years.

What to serve

• •TLS 1.3 — faster (one round trip to set up), removes every legacy feature, and every cipher suite in it is a strong one. Enable it everywhere you can.
• •TLS 1.2 — still required for older clients and some email servers. It is safe when configured with modern ECDHE key exchange and AEAD ciphers such as AES-GCM or ChaCha20-Poly1305.
• •TLS 1.1, TLS 1.0, SSL 3.0 — turn off.

Forward secrecy

With forward secrecy, each connection uses a one-off key that is thrown away afterwards. An attacker who records encrypted traffic today and steals the server's private key next year still cannot read it. TLS 1.3 always provides it. In TLS 1.2 it depends on the key exchange: suites that start with ECDHE or DHE have it, and the old RSA key exchange (suite names with no ECDHE or DHE prefix) does not. Surface reports the suite the server actually chose, and warns if it lacks forward secrecy or if the server does not support TLS 1.3.

How Surface checks

Surface attempts a handshake that offers only TLS 1.0 and then only TLS 1.1. If the server completes it, that is a failure. If the server refuses with a protocol alert, or drops the connection, the old version is off, which is the correct state. A check that could not run, for instance because the network blocked it, is reported as neutral, never as a pass or fail.

Common failure modes

• •An old default left in a server configuration, or a load balancer with a legacy security policy that was never updated.
• •Disabling the old versions on the web server but not on a second listener, for example an admin port, a mail server or an API on another hostname.
• •Keeping them on for a few legacy clients without measuring whether any still connect. Check your access logs for the negotiated protocol before deciding.