TLS Downgrade Attack

A TLS downgrade attack tricks a client and server into using an older protocol version or a weaker cipher suite than both actually support. The attacker sits in the middle, interferes with the handshake, and hopes to exploit known flaws in the weaker option.

Why it matters

Old protocol versions have practical attacks against them, such as POODLE against SSL 3.0 and BEAST against TLS 1.0. If your server still accepts those versions, an attacker only needs to push a connection down to one of them. Defenses exist in the protocol itself: TLS 1.3 servers embed a special marker in their random value when they negotiate a lower version, and clients abort if they see it. The cleanest defense is simply refusing old versions on the server.

Example

Check what your server accepts with OpenSSL:

openssl s_client -connect example.com:443 -tls1_1

If the output shows a certificate and a cipher instead of a handshake failure, TLS 1.1 is still enabled and should be disabled. A related downgrade targets the URL scheme rather than the protocol: HSTS stops a browser from being pushed from HTTPS back to HTTP.

Common mistakes

• Leaving TLS 1.0 and 1.1 enabled "for old clients" without checking whether any real traffic uses them.
• Disabling weak versions on one load balancer but not on the origin server behind it.
• Assuming a valid certificate means a strong connection. The certificate says nothing about the negotiated version.

Related

• SSL/TLS
• TLS handshake
• Cipher suite
• HSTS
• Tool: TLS version checker

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.