Outdated TLS protocol version: 1.0 and 1.1 still enabled

In one paragraph

TLS 1.0 and 1.1 are deprecated protocol versions that should not remain available on a modern HTTPS service. Test whether the server actually accepts each version, then disable them at the TLS endpoint. The documented WebAuditOS check observes a modern negotiation rather than enumerating legacy support, so a passing result alone does not prove those older versions are disabled.

Why it matters

RFC 8996 formally deprecates TLS 1.0 and 1.1 and prohibits their use. Later protocols support improved cryptographic mechanisms and reduce the need to retain obsolete implementation paths. Prefer TLS 1.3 with appropriately configured TLS 1.2 where compatibility requires it.

Protocol versions and cipher suites are related but distinct settings. Disabling old versions does not automatically validate every remaining suite or certificate. Likewise, a valid certificate does not establish a safe minimum protocol.

The practical challenge is often an old API integration rather than a current browser. A legacy runtime can continue using an old version while ordinary visitors negotiate a newer one. Inventory real usage before changing a service that supports third-party clients.

How WebAuditOS evaluates this finding

The supplied implementation opens a connection using a client that offers TLS 1.2 and 1.3, then records the negotiated version. A modern version passes; an older negotiated version would fail. Non-HTTPS origins and incomplete handshakes are not graded here.

Because the described client does not offer 1.0 or 1.1, a server supporting both old and new versions can pass. A legacy-only endpoint may fail the handshake instead, without this rule establishing which old version it supports. Read the result as a modern-client observation, not a legacy-disablement certificate.

How to fix it

1. Find the client-facing TLS endpoint. A CDN, managed load balancer, or reverse proxy may negotiate the public connection independently of the application server. Review origin-side TLS separately where used.
2. Test protocol support with a tool that explicitly offers each version. A capable testssl.sh or SSL Labs assessment can enumerate support. For your authorised endpoint, examples include:

testssl.sh --protocols example.com
openssl s_client -connect example.com:443 -servername example.com -tls1_1

The OpenSSL command requests one legacy version; it is not a complete protocol inventory. Recent libraries may reject the attempt locally. An error saying no usable local protocol or cipher is not proof the remote server refused it. Use an appropriate controlled test environment rather than weakening your general system configuration.

3. Review TLS-layer logs for existing legacy connections, where available, and contact integration owners. Application access logs may not capture handshakes that fail before an HTTP request exists.
4. Set the intended minimum where TLS terminates. In nginx, an illustrative allowed-protocol setting is:

ssl_protocols TLSv1.2 TLSv1.3;

For Apache with a compatible TLS module:

SSLProtocol -all +TLSv1.2 +TLSv1.3

Use the documentation for your actual versions, listeners, and virtual hosts. Default-server and SNI handling can matter; changing one included block is not proof that every endpoint changed.

5. On a managed edge, select a current policy whose supported minimum matches your design. Review the full policy, since it may also change cipher suites or other negotiation settings.
6. Validate configuration, deploy safely, and repeat explicit tests from outside. Confirm 1.0 and 1.1 are rejected while intended 1.2 and 1.3 clients connect with valid certificate verification.
7. Rescan in WebAuditOS and retain the independent enumeration evidence. Monitor handshake failures and partner journeys after rollout rather than relying solely on a modern browser opening the homepage.

What the fix can break

Clients limited to a removed protocol lose connectivity, often without a helpful application error. Provide an upgrade path and a communicated retirement date where needed; do not indefinitely retain deprecated versions because one unidentified integration might exist.

Different ports, IPv6 addresses, edge locations, or hostnames can expose inconsistent configurations. Test the public interfaces you intend to cover.

This page concerns HTTPS. Do not copy settings blindly into mail or other infrastructure without considering its separate deployment requirements and current protocol guidance.

Questions

Can TLS 1.0 remain enabled when a scan negotiates TLS 1.3?

Yes. A server can support both. Only explicit legacy-version testing answers whether the older option is accepted.

Does a local OpenSSL failure prove the server rejected TLS 1.1?

Not necessarily. The client may be unable or unwilling to offer it. Inspect where the failure occurred.

Must TLS 1.2 also be disabled?

Not automatically. Properly configured TLS 1.2 remains useful for compatibility; review its suites and implementation alongside support for TLS 1.3.

Which related checks help?

Review weak cipher suites, certificate expiry, and the security headers guide.