Defaults.Exposed › Fixes › Modern encryption (TLS version & ciphers)

How to fix Modern encryption (TLS version & ciphers)

TLS is the lock that scrambles the data flowing between your visitors and your website. Two things make that lock trustworthy: using a modern version of TLS (not the old, broken ones), and using strong ciphers (the actual scrambling recipe). This page covers both — plus a few related settings that don't affect your grade but are worth knowing about.

Bottom line for your business: If your site runs on outdated encryption or weak ciphers, the private details your customers type in — logins, card numbers, contact info — can be quietly intercepted and read on shared networks, and you can fail the security checks that banks, payment processors, and bigger clients now require before they will do business with you.

What this can cost you

• A customer pays or signs in over hotel or cafe Wi-Fi, an outdated connection or weak cipher lets a stranger on that network read their card and password, and the fraud — and the angry phone call — traces straight back to your site.
• You apply to take card payments (or your payment provider re-audits you) and get rejected because outdated TLS or a banned cipher breaks the payment-security rules — your online checkout is frozen until it's fixed.
• A larger client's IT team runs a routine security scan before signing, sees your site still allows broken encryption, and flags you as a risk — the contract stalls over a problem that costs nothing to fix.
• A data-protection complaint or breach lands on your desk and the first question regulators ask is whether you protected customer data 'appropriately' — running encryption that's been publicly known-broken for years is a very hard answer to give.
• Your site shows a padlock, so everyone assumes it's fully safe, and this gap goes unnoticed for years — until one intercepted login or card number turns into an incident far more expensive than the free fix would have been.

Why it matters. Encryption that's safe is invisible; encryption that's outdated or weak is a liability that sits quietly until the day it costs you a customer, a contract, or a compliance pass. The TLS version and cipher checks are the two parts that actually move your grade, and both are typically a single free setting — there is no upside to leaving the old, broken options switched on.

In plain words

When someone visits your website, everything they type — logins, card numbers, names, phone numbers, messages — is scrambled in transit so that strangers can’t read it. The technology that does the scrambling is called TLS (you may also hear it called SSL, its older name). For that scrambling to actually be safe, two things have to be right:

1. The TLS version — which generation of the technology you’re using. The early versions (TLS 1.0 and 1.1) have been publicly broken for years; the safe ones are TLS 1.2 and TLS 1.3.
2. The cipher — the specific recipe TLS uses to do the scrambling. Some ciphers (like RC4, DES and 3DES) have been cracked and are now banned; modern ciphers are still strong.

This page covers both, because a site can get one right and the other wrong. You can have a modern lock with an old, crackable recipe still switched on — or a strong recipe protected by an outdated lock. Either gap is an open door. Both are usually closed by the same single free change to your server or hosting settings.

What this can cost you

• A customer is robbed on public Wi-Fi. Someone signs into their account or pays from a hotel, cafe or airport. Because your site still allows an old TLS version or a weak cipher, a stranger on that same network forces the connection down to the breakable option and reads their password and card number in real time. The fraud lands on the customer, but the blame — and the support call — lands on you.
• Your card payments get switched off. Payment-security rules (PCI DSS) require TLS 1.2 as a minimum and explicitly ban weak ciphers like RC4. When your processor re-audits you, or when you apply to take cards, an outdated configuration fails the check and your checkout is frozen until it’s fixed — at exactly the wrong moment for cash flow.
• A deal stalls in a security review. Before a larger client signs, their IT team runs a routine scan. It immediately flags that your site still accepts broken encryption — the kind of finding that looks careless and makes a buyer wonder what else is loose. The contract sits in limbo over a problem that costs nothing to fix.
• A regulator asks the awkward question. After any complaint or breach, the first thing a data-protection authority wants to know is whether you protected personal data “appropriately.” Running encryption that’s been known-broken in public for years is very hard to defend, and “we didn’t realise the old version was still on” is not a comfortable answer.
• It hides behind the padlock for years. Because your site still shows a normal padlock, nobody notices the gap — until a single intercepted login or card number becomes a public incident far more expensive than the five-minute fix would have been.

What it actually is

The TLS version

A site doesn’t just support one version of TLS — it can offer several at once and let each visitor’s browser pick. A modern visitor will use the newest version available and see a normal padlock. The danger is that the old, broken versions can sit there alongside the good ones as an open back door: an attacker can force a visitor’s connection to “downgrade” to TLS 1.0 or 1.1 and then exploit the known weaknesses in those versions (the BEAST and POODLE attacks are the famous examples) to decrypt the traffic.

So our check connects to your site and tests each version individually — TLS 1.0, 1.1, 1.2 and 1.3 — to see which ones your server still accepts. Here’s what “good” looks like and how it scores:

• TLS 1.3 (with or without 1.2), and no legacy: the best result — a modern, clean configuration. Full marks.
• TLS 1.2 only, no 1.3: safe and passes, but you’re leaving the newest, fastest version on the table. Most marks; enabling 1.3 is worth doing.
• TLS 1.0 or 1.1 still accepted: an automatic fail, scored zero and flagged critical — it doesn’t matter that 1.2/1.3 also work, because the broken versions are the open door. This is what you must fix.

The cipher

Once a version is chosen, TLS picks a cipher — the actual algorithm that scrambles the data. Most modern ciphers are strong. A handful are broken and must never be used: RC4 (its scrambling is biased and leaks the plaintext), DES (its key is so short it can be brute-forced), 3DES (vulnerable to the “Sweet32” attack), plus NULL (no encryption at all), EXPORT-grade ciphers (deliberately weakened — the FREAK and Logjam attacks), and anonymous ciphers (no identity check, so an impostor can sit in the middle).

Our cipher check does two things. First it looks at the cipher your server actually negotiated with us. Then — and this is the important part — it actively tries to handshake using several known-broken ciphers (RC4, 3DES, EXPORT, NULL and anonymous variants). A server can pick a strong cipher when talking to a modern client yet still accept a weak one if an attacker insists — and that’s a real downgrade risk. If your server accepts any banned cipher, the check flags it; accepting a critical one (like RC4 or NULL) is a fail. (On TLS 1.3 there’s nothing to worry about here — that version removed every weak cipher by design, so the probes are skipped.)

The three informational extras

Three related items are reported but do not affect your grade — they’re flagged as informational because they can’t be reliably verified from the outside, and on any modern server or CDN they’re already handled correctly:

• TLS compression (the CRIME attack): an old feature that, if left on, could let an attacker tease out session cookies. It’s been disabled by default in every modern web server for over a decade, so this is effectively a non-issue today.
• OCSP stapling: a performance and privacy nicety where your server pre-fetches proof that its certificate hasn’t been revoked, so each visitor doesn’t have to ask the certificate authority themselves (which is slower and leaks browsing data). CDNs like Cloudflare do this automatically.
• Secure renegotiation: a fix for an old flaw (CVE-2009-3555) that let attackers inject data into a session. TLS 1.3 removed renegotiation entirely, so it’s a non-issue there, and modern TLS 1.2 servers implement the fix by default.

We surface these so your IT person has the full picture, but for the vast majority of owners there’s nothing to do — your score is driven by the version and cipher checks above.

How to fix it (free, ~30 minutes)

Hand this to your IT person — the fix is free. This section is for whoever manages your domain, website or hosting. The fix is a configuration change, not a purchase; we only charge to monitor that your encryption stays correctly configured over time. The single modern configuration below fixes both the version and the cipher findings at once.

The simplest reliable approach is to generate a known-good config rather than hand-write one: paste your server type into Mozilla’s SSL Configuration Generator at https://ssl-config.mozilla.org/ and choose the “Intermediate” profile (broad compatibility) or “Modern” (TLS 1.3 only, if you don’t need to support anything old). It outputs the correct ssl_protocols and ssl_ciphers lines for you.

By platform:

1. Cloudflare or a managed host — usually one or two clicks. In Cloudflare: SSL/TLS → Edge Certificates → Minimum TLS Version → TLS 1.2, and the cipher suites there are managed for you (the platform won’t offer banned ciphers). Most managed hosts and site builders (Squarespace, Wix, Shopify, modern WordPress hosts) already enforce TLS 1.2+ with strong ciphers — just confirm there’s no “legacy TLS” or “old-browser compatibility” option still switched on.
2. Nginx. Set modern-only versions and an explicit strong cipher list, then reload:

   ssl_protocols TLSv1.2 TLSv1.3;
   ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
   ssl_prefer_server_ciphers on;
   

   (TLS 1.3 requires OpenSSL 1.1.1+ on the box.)
3. Apache. Disable the old versions and pin a strong cipher list, then restart:

   SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
   SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
   SSLHonorCipherOrder on
   

4. Windows / IIS. Use the free IIS Crypto tool (or the equivalent registry settings) to disable TLS 1.0 and 1.1, disable RC4/DES/3DES/NULL/EXPORT ciphers, and leave TLS 1.2 and 1.3 with strong ciphers enabled. The tool’s “Best Practices” template does all of this in one click.
5. The informational extras (optional, free). If you want the clean sweep: on Nginx add ssl_stapling on; ssl_stapling_verify on; (with a resolver line) for OCSP stapling; on Apache, SSLUseStapling On. TLS compression and secure renegotiation are already safe by default on modern servers — no action needed. On Cloudflare all three are handled automatically.
6. Verify, then re-check here. Confirm only the safe versions and ciphers remain — for example with nmap --script ssl-enum-ciphers -p 443 yourdomain.com, or test at https://ssl-config.mozilla.org/’s linked tools — then re-run this check. Where possible, enable TLS 1.3 alongside 1.2: it’s both faster and more secure.

Common mistakes

• “We have a padlock, so we’re fine.” The padlock only proves a secure connection exists. It says nothing about whether an old version or a banned cipher is still accepted in the background — which is precisely the gap these checks find.
• Fixing the version but not the ciphers (or vice versa). Disabling TLS 1.0/1.1 doesn’t automatically remove RC4 or 3DES, and pinning strong ciphers doesn’t automatically disable old versions. Set both — the generated config above does.
• Leaving “legacy” or “old-browser compatibility” toggles on. Many hosts and CDNs have an option that quietly re-enables the broken versions or weak ciphers “for compatibility.” It almost never helps a real visitor and directly causes this finding.
• Forgetting to actually reload/restart the server. Config changes don’t take effect until the web server is reloaded — a surprisingly common reason a “fixed” site still fails the re-check.
• Configuring one server but not all of them. If you run a load balancer, multiple web servers, or separate subdomains (shop, blog, app), each TLS endpoint needs the same configuration — the weakest one is what an attacker targets.

What to remember

The TLS version and the cipher are the two parts of your encryption that actually move your grade, and both come down to switching off options that have been broken in public for years. The fix is free, it’s usually one modern configuration line per server, and to a normal visitor it changes nothing except making their connection genuinely safe. The related items — compression, OCSP stapling, secure renegotiation — are worth knowing about but won’t affect your score, and on any modern setup they’re already handled for you.

FAQ