Server still accepts TLS 1.0 or 1.1

The site's server still agrees to set up an encrypted connection using TLS 1.0 or TLS 1.1 — protocol versions from 1999 and 2006 that are now formally deprecated (RFC 8996).

Modern browsers use TLS 1.2 or 1.3 and no longer offer 1.0 or 1.1 at all, so your visitors are not using the old versions. The problem is that the server still accepts them: any client that asks for an old version gets one.

For a site to pass this check:

• The server refuses a connection that offers only TLS 1.0 and 1.1.

This is a site-wide check. Protocol support is a setting of the server (or CDN or load balancer) in front of the site, not of individual pages, so it is tested once per scan against the site's host and reported once.

• Known weaknesses. TLS 1.0 and 1.1 depend on cryptography that is no longer considered safe (SHA-1 and MD5 in the handshake, CBC-mode ciphers affected by attacks such as BEAST and POODLE variants). Accepting them leaves room for downgrade attacks against clients that still support them.

• Compliance. PCI DSS has required disabling TLS 1.0 for card data since 2018, and many security standards, audits and vendor questionnaires flag TLS 1.0/1.1 support as a finding.

• Trust signals. Public scanners such as SSL Labs cap a site's grade when old protocols are enabled. It is one of the first things a security review checks.

• No benefit. Every browser from the last several years supports TLS 1.2. Turning off 1.0 and 1.1 costs nothing for real visitors.

Effect on the health score

This is a standard issue. It deducts once from the Delivery & Trust score, as a site-wide finding.

Allow only TLS 1.2 and TLS 1.3.

nginx

ssl_protocols TLSv1.2 TLSv1.3;

Apache

SSLProtocol -all +TLSv1.2 +TLSv1.3

HAProxy

global
    ssl-default-bind-options ssl-min-ver TLSv1.2

Cloudflare: SSL/TLS → Edge Certificates → Minimum TLS Version: TLS 1.2.

AWS (CloudFront / ALB): choose a security policy with TLS 1.2 as the minimum, such as TLSv1.2_2021 (CloudFront) or ELBSecurityPolicy-TLS13-1-2-2021-06 (ALB).

Check the result:

openssl s_client -connect example.com:443 -tls1_1 </dev/null
## should fail with a protocol version alert

Mozilla's SSL Configuration Generator produces a complete, current configuration for most servers.

If the site is behind a CDN, the CDN's setting is the one visitors reach; also lock down the origin if it is reachable directly.

Example 1: Old protocols enabled

ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

Reported: the probe's TLS 1.1 handshake completes.

negotiatedProtocol: TLSv1.1
cipher:             ECDHE-RSA-AES256-SHA

Example 2: Modern configuration

ssl_protocols TLSv1.2 TLSv1.3;

Passes: the server answers the probe with a "protocol version" alert.

Example 3: Host not reachable on port 443

The site is served only over plain HTTP, or a firewall drops the connection.

Not reported, and not a pass: the probe could not reach the server, so the scan log records "could not test".

1. Makes one extra connection per scan to the site's host — the host of the address the scan started from, on port 443 (or the port in that address, if it is an https:// address with its own port).

2. Offers only TLS 1.0 and TLS 1.1. The crawler's TLS library refuses these versions by default, so the probe explicitly enables them (including the lower security level OpenSSL needs to speak them) for this one connection. The certificate is not verified, because the question is which protocol the server will use, not whether the certificate is trusted.

3. Waits at most 5 seconds.

4. Reports the issue only if the handshake completes on TLS 1.0 or 1.1. The finding records the version and cipher that were negotiated.

5. Treats a refusal as a pass. A protocol-version or handshake alert from the server means it does not accept the old versions.

6. Never guesses when it could not test. Two outcomes are recorded in the scan log as "could not test" and produce no finding either way:

   • the crawler's own TLS library could not offer TLS 1.0/1.1 (for example, a build of OpenSSL without them), so the server was never asked;
   • the network got in the way: the connection was refused, timed out, or was dropped without an answer.

7. Never affects the rest of the scan. Any failure of the probe is caught and logged.

Storage Level

Site Level

Database Table / Prisma Model

audit_issues.details, with no URL (a site-wide finding)

Stored Fields

Detection Dependencies

• One TLS handshake per scan to the site's host, offering only TLS 1.0 and 1.1

Note

When the probe could not test the server, nothing is stored; the reason is written to the scan log.