TLS 1.0 and 1.1 Deprecation: How to Find Endpoints Still Using Them

Why TLS 1.0 and 1.1 are gone

TLS 1.0 (1999) and 1.1 (2006) carry weaknesses modern cryptography has moved past: reliance on SHA-1 and MD5 in the handshake, exposure to attacks like BEAST and POODLE, and no support for modern AEAD cipher suites. RFC 8996 formally deprecated both in March 2021, and the major browsers removed support back in 2020.

Compliance frameworks got there first. PCI DSS required disabling TLS 1.0 by June 2018, and current baselines expect TLS 1.2 as a floor with 1.3 preferred. If you handle payments or regulated data, an endpoint still negotiating TLS 1.0 is not just a theoretical risk, it is an audit finding.

Where old TLS still hides

Your public web front door is almost certainly fine; CDNs and modern web servers dropped these versions years ago. The stragglers are elsewhere:

• Load balancers and reverse proxies with security policies set years ago and never revisited
• Legacy internal APIs and service-to-service calls behind the firewall
• Mail servers (SMTP/IMAP/POP over STARTTLS) that quietly accept old versions
• Database and admin ports with TLS enabled but unconstrained
• Network appliances, printers, IoT, and vendor boxes with firmware frozen in 2015
• Redirect hosts and marketing subdomains no one remembers owning

Check a single endpoint

For one host, openssl is the fastest answer. Force each old version and see whether the handshake completes:

• openssl s_client -connect example.com:443 -tls1
• openssl s_client -connect example.com:443 -tls1_1

Find them at scale

If the connection establishes and shows a certificate, that version is enabled. If it fails, that version is refused, but note one caveat: OpenSSL 3.x is often built with 1.0/1.1 disabled, so a failure may mean your client cannot offer it rather than the server refusing it. Cross-check with nmap --script ssl-enum-ciphers -p 443 example.com, which grades every protocol a host accepts, or spot-check any public host with our SSL checker.

For an estate, two tools scale well. testssl.sh is a self-contained bash script that scans thoroughly and highlights deprecated versions in red; sslyze is faster for bulk runs and scriptable via sslyze --tlsv1 --tlsv1_1 example.com:443 with JSON output. But tools only test what you feed them, so the harder half is the target list: pull hostnames from DNS zone exports, your certificate inventory, load-balancer configs, and cloud asset inventories, then de-duplicate. Do not forget non-443 ports like 8443, 993, 465, and 587. The endpoints most likely to still run TLS 1.0 are precisely the ones missing from your neat list.

Fix it, and keep it fixed

Remediation is usually a config change: raise the minimum protocol to TLS 1.2 on the server, proxy, or load balancer and reload. The risk is not the change itself but what breaks, an old client, a payment terminal, a partner integration on an ancient library. Check access logs for the versions clients actually negotiate before you flip the switch, and stage the change where you can roll back.

The part teams underestimate is regression. A firmware update, a restored-from-backup appliance, or a new vendor box can quietly re-enable an old version months later. A one-time sweep proves today is clean; it says nothing about next quarter.

From periodic scans to continuous monitoring

This is where scanning turns into monitoring. VigilDog tracks the TLS configuration and certificates on the endpoints you care about and alerts you if a deprecated protocol reappears or a certificate drifts, so a re-enabled TLS 1.0 surfaces as an alert, not an audit finding six months later.

If you are weighing this against your existing tooling, our take on SSL monitoring versus uptime monitoring explains why the two catch genuinely different failures.