Outdated TLS Protocols (TLS 1.0 / 1.1 Enabled)

SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration
SSL Certificate Analysis Open Port Detection Web Application Scanning DNS Security Audit HTTP Header Analysis Misconfiguration Detection Software Fingerprinting Subdomain Enumeration

All Entries

Scan Your Site

Check your website for this issue

Run an automated scan and see whether your site is affected — with plain-language findings and fixes.

Start Scanning
Category Cryptographic Misconfiguration
Typical Severity Medium
OWASP A02:2021 – Cryptographic Failures
CWE CWE-326 – Inadequate Encryption Strength
Also known as Deprecated TLS, Weak TLS, Legacy SSL/TLS
Affected systems Web servers, load balancers, API gateways, CDNs, and any TLS-terminating endpoint that still advertises TLS 1.0 or TLS 1.1 in their cipher negotiation
Relevant standards RFC 8996 (deprecates TLS 1.0 and 1.1), PCI DSS v3.2.1+ (requires TLS 1.2 minimum), NIST SP 800-52 Rev. 2
Protocol versions affected TLS 1.0 (RFC 2246, 1999), TLS 1.1 (RFC 4346, 2006)

Overview

Transport Layer Security (TLS) is the cryptographic protocol that secures the majority of modern internet communications. TLS 1.0 was standardised in 1999 and TLS 1.1 in 2006; both have since been formally deprecated by RFC 8996 (March 2021) due to inherent design weaknesses and the availability of practical attacks against them. Servers that still advertise support for these versions during the TLS handshake allow clients to negotiate a connection using broken cryptographic primitives, undermining the confidentiality and integrity guarantees that TLS is intended to provide.

Sensagraph automatically detects TLS 1.0 and TLS 1.1 support during its continuous transport-layer security assessments.

How it works

During a TLS handshake the client sends a ClientHello message listing the protocol versions and cipher suites it supports. If the server accepts TLS 1.0 or TLS 1.1, both parties may negotiate a session using those older protocol frames. The following weaknesses are inherent in these versions:

  • BEAST (Browser Exploit Against SSL/TLS): Affects TLS 1.0 because it uses CBC mode with a predictable IV chained from the previous record, enabling chosen-plaintext attacks against session cookies.
  • POODLE (Padding Oracle On Downgraded Legacy Encryption): Although originally an SSL 3.0 attack, variants target TLS 1.0's CBC padding, allowing a man-in-the-middle attacker to decrypt individual bytes of ciphertext.
  • LUCKY13: A timing side-channel attack against CBC-mode MAC-then-encrypt constructions used in TLS 1.0 and 1.1, enabling partial plaintext recovery.
  • Weak PRF and MAC algorithms: TLS 1.0 uses a combination of MD5 and SHA-1 in its Pseudo-Random Function (PRF), both of which are considered cryptographically broken. TLS 1.1 improved the IV handling but retained the same weak PRF.
  • Downgrade attacks: Servers that support both modern and legacy TLS versions can be forced into negotiating the weaker version via network-level interference, even when clients prefer TLS 1.2 or 1.3.
  • Absence of AEAD cipher suites: TLS 1.0 and 1.1 do not support Authenticated Encryption with Associated Data (AEAD) cipher suites such as AES-GCM, which are mandatory in TLS 1.3 and strongly recommended in TLS 1.2.

Business impact

Enabling TLS 1.0 or TLS 1.1 creates exposure across several dimensions:

  • Data confidentiality: Active network attackers (e.g., on shared Wi-Fi, or via BGP hijacking) may exploit the weaknesses above to partially or fully decrypt session traffic, exposing credentials, session tokens, and sensitive data.
  • Compliance and regulatory risk: PCI DSS has required migration away from TLS 1.0 since June 2018. HIPAA guidance, NIST SP 800-52, and many national data-protection frameworks mandate TLS 1.2 or higher. Failure to comply can result in audits, fines, or loss of payment-processing capability.
  • Browser trust degradation: Major browsers (Chrome, Firefox, Safari, Edge) removed support for TLS 1.0 and 1.1 in 2020–2021, so users on those browsers will receive security warnings or connection failures, harming user experience and brand trust.
  • Third-party and API partner requirements: Many payment processors, cloud providers, and API consumers formally reject TLS 1.0/1.1 connections, causing integration failures for organisations that have not migrated.

How to fix it

  1. Disable TLS 1.0 and TLS 1.1 at the server or load balancer level. Set the minimum accepted protocol to TLS 1.2, and enable TLS 1.3 where the platform supports it. Configuration syntax varies by software:
    • Nginx: ssl_protocols TLSv1.2 TLSv1.3;
    • Apache: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
    • IIS: Disable via registry keys under HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols or via IIS Crypto / Group Policy.
    • HAProxy: ssl-min-ver TLSv1.2
  2. Verify the change with a protocol-level scan after applying the configuration to confirm TLS 1.0 and TLS 1.1 handshakes are rejected.
  3. Pair with a strong cipher suite policy. Even on TLS 1.2, disable weak cipher suites (RC4, 3DES, export-grade ciphers, anonymous DH). Prefer ECDHE-based AEAD suites (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).
  4. Enable TLS 1.3 wherever supported. TLS 1.3 eliminates the vulnerable handshake modes present in earlier versions, mandates forward secrecy, and supports only AEAD cipher suites.
  5. Check all TLS-terminating endpoints in the environment — including CDN edge nodes, API gateways, internal microservices, mail servers, and database connections — not just public-facing HTTPS.
  6. Assess client compatibility before disabling. Review access logs to identify any remaining TLS 1.0/1.1 clients; notify or migrate them before cutting support. Very old devices (e.g., Android < 5.0, IE 10) cannot negotiate TLS 1.2 without updates.
  7. Reference Mozilla's TLS configuration generator (ssl-config.mozilla.org) for server-specific recommended configurations aligned with current best practices.

References

Frequently asked questions

TLS 1.1 addressed the predictable IV vulnerability exploited by the BEAST attack by switching to explicit IVs in CBC mode, making it marginally safer than TLS 1.0 in that regard. However, TLS 1.1 retains the same weak MD5/SHA-1 PRF, lacks AEAD cipher support, and has been formally deprecated alongside TLS 1.0 by RFC 8996. Neither version should be considered acceptable for modern deployments.

Potentially yes, for very old clients. Android versions below 5.0, Internet Explorer 10 and earlier, Java 6/7 runtimes (without manual configuration), and some legacy embedded devices cannot negotiate TLS 1.2 without updates. You should review server access logs to identify such clients before disabling the deprecated protocols, and notify users to update their platforms.

TLS 1.2 itself, when properly configured with modern cipher suites (ECDHE + AEAD), is not known to have practical exploitable vulnerabilities. However, TLS 1.2 deployments that still allow RC4, 3DES, export-grade ciphers, or CBC-mode suites without the Encrypt-then-MAC extension can be vulnerable to attacks like SWEET32 or Lucky13. TLS 1.3 eliminates all these concerns by mandating forward secrecy and AEAD-only cipher suites.

Yes. PCI DSS v3.2.1 required migration away from TLS 1.0 (designated 'early TLS') by June 2018. TLS 1.1 is similarly discouraged and many QSAs treat it as non-compliant. PCI DSS v4.0 reinforces that TLS 1.2 is the minimum acceptable version for cardholder data environments.

You can verify using command-line tools such as OpenSSL (e.g., 'openssl s_client -tls1 -connect example.com:443') or 'curl --tlsv1.0 --tls-max 1.0 https://example.com'. A successful handshake indicates the protocol is still enabled. Public tools like SSL Labs' SSL Server Test also report which protocol versions are accepted and assign a grade accordingly.