TLS: which version to use and why you should disable TLS 1.0 and 1.1

The padlock in the browser depends on TLS — the protocol that encrypts the connection between the user and the server. But it is not enough to "have HTTPS": the TLS version matters as much as the certificate. Keeping old versions enabled is one of the quietest ways for a site to remain vulnerable.

What TLS is

TLS (Transport Layer Security) is the successor of SSL and the foundation of HTTPS. It protects three things in the connection: confidentiality (nobody reads the traffic), integrity (nobody alters the traffic) and authentication (the client validates the server identity through the certificate).

Negotiation happens at the start of each connection: client and server decide together which version and which cipher suites to use. That is where misconfiguration shows up — if the server accepts old versions, they will be used.

Why TLS 1.0 and 1.1 are obsolete

TLS 1.0 (1999) and TLS 1.1 (2006) have accumulated decades of known attacks: BEAST, POODLE (against SSL 3.0 and related patterns), Lucky 13 and others. Some flaws are at the core of the protocol and cannot be fixed by configuration — only by changing the version.

In 2020, the main browsers discontinued TLS 1.0 and 1.1 and started showing insecure connection warnings on sites that only support them. Today, a server that accepts TLS 1.0 fails an audit even with a valid certificate.

TLS 1.2 — the current floor

TLS 1.2 (2008) is supported by any modern client and is still the recommended minimum version. With a proper cipher configuration, it is safe for production. If you can only change one thing on the server, disable 1.0/1.1 and keep 1.2 at minimum.

TLS 1.3 — the current version

TLS 1.3 (2018) removed cipher suites and modes considered fragile, reduced the number of round trips in the negotiation (faster connections) and removed mid-connection renegotiation — a historic source of attacks.

Modern browsers use TLS 1.3 when the server offers it. Enabling 1.3 alongside 1.2 gives the best result: broad compatibility with new clients and maximum security.

How to configure it

nginx:

ssl_protocols TLSv1.2 TLSv1.3;

Apache:

SSLProtocol TLSv1.2 TLSv1.3

Cloudflare and other CDNs — most manage the version automatically but allow setting the minimum under "TLS" or "Security Level" in the dashboard.

After the change, test: the negotiation should happen over TLS 1.2 or 1.3, never below.

Common mistakes

• Keeping TLS 1.0/1.1 "for old clients": most of those clients can be updated; the risk of keeping the versions is higher than the benefit.
• Disabling 1.2 together with 1.0/1.1: some old guides assume "removing everything old" includes 1.2. 1.2 is the floor, not the ceiling.
• Accepting weak ciphers on TLS 1.2: the right version with the wrong cipher is still insecure — review the cipher list.
• Trusting only the certificate: a valid certificate does not indicate a secure version; server configuration is a separate item.
• Using tools that only test that the site is on HTTPS: check the actually negotiated version, not just the padlock.
• Forgetting internal servers: APIs, dashboards and subdomains need the same rule.

Once only TLS 1.2 and 1.3 are accepted, the natural next step is forcing HTTPS across every navigation with the HSTS header.

How to check it

The VulnexusAI scanner connects to the site, records which TLS version was negotiated and flags whether TLS 1.0 or 1.1 are enabled. Together with the certificate check, this is the "HTTPS & Certificate" category of the report — and a fix that takes minutes on the server.