Weak Cipher Suites Still Running in Production
Most gym lockers have a padlock. The padlock clicks shut. It looks secure. To anyone glancing at it, the locker is locked. To anyone with a YouTube video and ninety seconds, it isn't.
That's roughly the situation with a lot of TLS configurations in 2026. The server presents a cert. The cert is valid. The browser shows a padlock icon. To anyone glancing at it, the connection is secure. But somewhere in the negotiated cipher suite is a primitive that has been formally deprecated for years, sometimes a decade. Modern clients still accept it because backwards compatibility is sticky. Attackers love it for the same reason.
Here's a tour of the cipher suites and protocols that should be gone but aren't, what public scan data shows, why they're still running, and what to do about them.
The ciphers and protocols that still won't die
TLS 1.0 and TLS 1.1. Both officially deprecated by the IETF in March 2021 (RFC 8996). PCI-DSS, NIST, and pretty much every other framework requires TLS 1.2 minimum. Qualys SSL Pulse - a public, monthly survey of the top 150,000 HTTPS sites - has shown single-digit-to-low-double-digit percentages of these sites still negotiating TLS 1.0 and TLS 1.1 for years. The numbers are dropping but slowly.
RC4. A stream cipher that was the default for years and was banned by the IETF in 2015 (RFC 7465). It is still occasionally found in legacy systems, old appliances, and configurations that haven't been audited since 2018. There is no good reason to accept it.
3DES (Triple DES). Banned by NIST for new applications, and especially vulnerable in TLS due to the SWEET32 attack on 64-bit block ciphers. Still found in older Java services, some VPN appliances, and a surprising number of internal-facing tools.
Weak Diffie-Hellman groups. The LogJam attack (2015) showed that DH groups smaller than 2048 bits could be broken by a well-resourced attacker. Many servers still allow 1024-bit DH or smaller for backwards compatibility.
Anonymous cipher suites (aNULL). Suites that don't authenticate the server. Nobody should configure these intentionally. They appear when defaults include "everything" and nobody trimmed the list. Functionally equivalent to no encryption against an active attacker.
Export-grade ciphers. A relic of 1990s US export controls - deliberately weak suites that should never be enabled. The FREAK attack (2015) exploited the fact that some servers still negotiated them. Mostly gone, occasionally found.
The thread connecting all of these: they're enabled because somewhere, sometime, a client needed them. The client is usually gone. The configuration isn't.
What public scans show
The numbers below come from publicly available scans - Qualys SSL Labs / SSL Pulse, censys.io, and Mozilla Observatory - that aggregate data across hundreds of thousands of sites and update monthly. We see similar patterns in customer environments.
TLS 1.0/1.1 still supported. A meaningful percentage of major HTTPS sites still negotiate TLS 1.0 if asked, and a slightly larger percentage still allow TLS 1.1. The numbers were higher five years ago and will keep declining, but the long tail is sticky.
RC4 still accepted. Low single-digit percentages of public sites still offer it. Internal scans typically find higher rates, because internal admin tools and legacy enterprise software haven't been touched.
Weak DH groups. A meaningful minority of HTTPS sites in mass scans still offer DH groups below 2048 bits. The bigger surprise: many of these are sites that otherwise have modern TLS configurations. The weak group is in there as a fallback nobody removed.
SSLv3. Officially dead since POODLE (2014). Should be zero. Is not zero. Tiny percentages of internal-facing tools still support it.
Below-A grades. The Qualys SSL Pulse "A" grade requires no obvious issues. A significant fraction of sites scanned each month fall below A - usually because of cipher or configuration issues, sometimes because of validation issues.
The pattern: in a well-known and publicly-scanned dataset, double-digit percentages of sites have configuration issues that PCI-DSS, SOC 2, and HIPAA all consider noncompliant. The pattern is worse for internal-facing systems, because those don't get scanned by the public databases.
Why they're still running
Three reasons, in order of frequency.
Legacy clients. Somewhere, a customer's mobile app, a partner's integration, an old browser, or an internal tool needs TLS 1.0. Somebody decided that breaking the client was worse than weakening the configuration. The decision was probably reasonable at the time. It's now four years old and nobody revisits it.
Old appliances and enterprise software. Load balancers and firewalls and identity providers with default cipher lists from 2017. Vendor updates have come and gone; the configuration hasn't been re-baselined. The defaults shipped insecure and nobody noticed.
Cargo culting and copy-pasted configs. Someone copied an nginx config from Stack Overflow in 2019. The config supported a long cipher list to be "compatible with everything." That config is now production. The original author has no recollection of writing it.
There is a fourth, less polite reason: cipher hardening is one of those tasks that has no visible payoff. It moves you from "things work" to "things still work, but more securely." Nobody gets a promotion for it. It only gets attention after an audit finding or a breach. As a result, it's the kind of work that lives forever on a backlog.
How to find them in your environment
Three tools, in order of effort.
External: Qualys SSL Labs (free). Drop a URL in, get a grade. Anything below A is worth investigating. Anything F is urgent. Great for quick checks of public-facing endpoints.
External, at scale: a continuous TLS scanner. Something that checks all your endpoints daily and tells you when configuration drifts. TLS Radar does this; other tools mentioned in our alternatives pages do too. The point is automation - manual Qualys checks don't catch drift.
Internal: testssl.sh or sslyze. Both are command-line tools that do detailed cipher and protocol scans. Aim them at your internal services. The first time you do this, expect to find things.
The "internal" part is where most teams have the largest gap. External scanners can't reach internal admin tools, internal CAs, or behind-firewall services. Those are where the weak ciphers most often hide.
What to do
Three steps.
One: pick a target configuration. The Mozilla SSL Configuration Generator is the easiest starting point - pick "Modern" if you don't need to support old clients, "Intermediate" if you have a typical user base. Document the choice.
Two: roll it out incrementally. Start with one service. Confirm it works for your traffic. Then expand.
Three: monitor for drift. The day you fix the cipher list is not the day the problem is solved. The problem is solved when configuration drift is monitored and triggers alerts.
One small ask
The padlock on the gym locker looks fine until somebody decides to look closely. Same with your TLS configuration. A continuous external scan is the cheapest way to find what's there - the weak ciphers, the old protocols, the configurations nobody's reviewed since 2019. TLS Radar runs that scan automatically across all your endpoints. Free tier covers three domains, which is enough to find at least one thing you didn't know about.
Find the ciphers nobody's reviewed since 2019
TLS Radar continuously checks the protocols and cipher suites your servers actually negotiate and flags the weak, deprecated ones modern browsers are dropping - before they quietly start failing for updated clients. Run a scan, or set up monitoring across every endpoint you own.
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.