ASVS 5.0 V12.1.1: Enable Only TLS 1.2 and TLS 1.3

ASVS 5.0 V12.1.1 (Level 1) requires that only the latest recommended versions of TLS are enabled, such as TLS 1.2 and TLS 1.3, and that the newest version is the preferred one. SSL 2.0, SSL 3.0, TLS 1.0 and TLS 1.1 must be off.

Why it matters

Old protocol versions carry known attacks, and a server that still offers them can be pushed back to them by a network attacker. Old versions also lack modern ciphers and forward secrecy by design. Browsers and clients have dropped them, so leaving them on mostly helps attackers and hurts nobody else.

The requirement covers every TLS endpoint, not just the public site. Load balancers, internal services, database connections, message brokers and health check ports all count.

How to implement it

Set a minimum version at each place TLS terminates. Then confirm the effective setting, because defaults vary by version and platform.

nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;

With off, modern clients choose their best suite, and TLS 1.3 wins automatically when both sides support it.

Node.js:

import https from 'node:https';
import fs from 'node:fs';

https.createServer({
  key: fs.readFileSync('key.pem'),
  cert: fs.readFileSync('cert.pem'),
  minVersion: 'TLSv1.2',
}, app).listen(443);

Java: restrict jdk.tls.disabledAlgorithms in the security properties and set https.protocols to TLSv1.3,TLSv1.2. Go: set MinVersion: tls.VersionTLS12 in tls.Config.

For cloud load balancers, pick a security policy that lists TLS 1.2 as the floor, and apply the same policy to every listener. Keep client side settings in step: HTTP clients, database drivers and agents should set the same minimum so they never negotiate down.

If a legacy partner truly needs an older version, isolate that connection on its own endpoint with a documented exception and a retirement date. Do not weaken the main listener for it.

Try it yourself

Click through it at your own pace, or open it full screen.

How to test it

Probe each protocol version directly with OpenSSL. The older ones must fail, the newer ones succeed.

openssl s_client -connect example.com:443 -tls1   </dev/null   # expect failure
openssl s_client -connect example.com:443 -tls1_1 </dev/null   # expect failure
openssl s_client -connect example.com:443 -tls1_2 </dev/null   # expect success
openssl s_client -connect example.com:443 -tls1_3 </dev/null   # expect success

Some modern OpenSSL builds refuse to speak the old versions at all, so a local failure can mean the client, not the server. Use an external scanner or a tool such as nmap with its ssl-enum-ciphers script for a trustworthy answer, and run it against every listener from your inventory, including internal ones.

Put the check in CI or a scheduled job so a configuration change cannot silently bring back an old version. A dynamic scan of your web application can also report weak protocol support as part of a wider run.

Common mistakes

• Fixing the public site and forgetting internal ports and admin consoles
• Setting a maximum instead of a minimum version
• Trusting a config file without testing the live endpoint
• Letting a CDN or load balancer keep an old default policy
• Keeping TLS 1.0 for one legacy client on the main listener

Quick check

Sources

• OWASP ASVS
• OWASP Transport Layer Security Cheat Sheet