TLS Version Support Test

Test which versions of the TLS/SSL protocol are supported by your server.

Evidence ASSESSED

Checked against: A separate handshake attempted per TLS version

RED TEAM 0 findings BLUE TEAM control did not hold

Protocol Guidelines

For maximum security and compliance (like PCI DSS), your server should only support modern protocols:

TLS 1.3: The latest and most secure version. Essential for modern web security.
TLS 1.2: Still widely used and considered secure when configured correctly.
Deprecated: TLS 1.0 and 1.1 are officially deprecated and should be disabled as they are vulnerable to various attacks.
Insecure: SSLv2 and SSLv3 are old and highly insecure. They must never be used.

Our TLS Version Checker negotiates connections to your server to determine which TLS protocol versions it accepts. It flags deprecated protocols such as TLS 1.0 and 1.1 that fail PCI DSS compliance and expose you to known downgrade attacks.

What are TLS Versions?

TLS (Transport Layer Security) is the protocol that encrypts HTTPS traffic. It has evolved through several versions, and older ones carry weaknesses that cannot be configured away.

SSL 2.0 and 3.0 are long broken and must never be enabled. TLS 1.0 and 1.1 were formally deprecated by RFC 8996 in 2021 — they rely on outdated cryptographic primitives including SHA-1 and MD5 and are vulnerable to attacks such as BEAST and POODLE. TLS 1.2 remains secure when configured with strong cipher suites. TLS 1.3, published as RFC 8446, removes every legacy option, simplifies the handshake to a single round trip and provides forward secrecy by default.

A server typically supports several versions and negotiates the highest one the client also supports. The risk is in what it still accepts, not in what it prefers.

TLS 1.3 is current, fastest and the most secure
TLS 1.2 is acceptable with strong cipher suites
TLS 1.0 and 1.1 were deprecated by RFC 8996 in 2021
SSL 2.0 and 3.0 are fundamentally broken
Servers negotiate the highest version both sides support

Why TLS Version Matters

Supporting an obsolete protocol version does not merely fail an audit — it creates an exploitable path. An attacker who can influence the handshake may force a downgrade to the weakest version the server still accepts, then attack that. The presence of TLS 1.0 as a fallback undermines the security of a server that otherwise prefers TLS 1.3.

PCI DSS has prohibited TLS 1.0 for card data environments since 2018. All major browsers removed support for TLS 1.0 and 1.1 in 2020, so leaving them enabled serves no compatibility purpose for ordinary web traffic while keeping the downgrade surface open.

Legacy versions permit protocol downgrade attacks
TLS 1.0 fails PCI DSS and most compliance frameworks
Browsers dropped TLS 1.0 and 1.1 support in 2020
BEAST, POODLE and related attacks target the older protocols
TLS 1.3 is measurably faster, needing one round trip instead of two

How This TLS Version Checker Works

The tool attempts handshakes with each protocol version in turn and records which ones the server accepts.

Validates the host input against format and SSRF safety checks
Attempts a TLS handshake for each protocol version individually
Records which versions are accepted and which are refused
Identifies the highest version the server will negotiate
Flags any deprecated protocol that remains enabled

How to Use the TLS Version Checker

Enter your domain or hostname in the input field
Run the check to attempt handshakes across protocol versions
Confirm TLS 1.2 and ideally 1.3 are supported
Confirm TLS 1.0 and 1.1 are refused
Disable any deprecated version that is still accepted and re-test

Understanding Your TLS Version Results

Each protocol version is tested independently. Here is how to read the outcome:

Field / Value	Meaning
`TLS 1.3 supported`	The current standard, published as RFC 8446. Forward secrecy by default, no legacy cipher suites, and a one round trip handshake. Enable it wherever your stack allows.
`TLS 1.2 supported`	Still secure when restricted to strong cipher suites. It remains necessary for compatibility with some older clients and API consumers.
`TLS 1.1 accepted`	Deprecated by RFC 8996. No modern client needs it. Disable it.
`TLS 1.0 accepted`	Deprecated and non-compliant with PCI DSS. Vulnerable to BEAST and related attacks. Disable it as a priority.
`SSL 2.0 or 3.0`	Fundamentally broken protocols. POODLE affects SSL 3.0 directly. There is no configuration that makes these safe.
`Highest negotiated`	The version a modern client actually gets. This should be TLS 1.3, but it says nothing about what older clients can still negotiate.

Common Problems & How to Fix Them

These protocols are deprecated and allow downgrade attacks against an otherwise modern configuration.

In nginx, set ssl_protocols TLSv1.2 TLSv1.3;
In Apache, set SSLProtocol -all +TLSv1.2 +TLSv1.3

On a CDN or load balancer, set the minimum TLS version in the dashboard — the setting is usually a single dropdown. Reload the service and re-test.

You are missing the performance and security improvements of the current protocol, including forward secrecy by default.

TLS 1.3 requires OpenSSL 1.1.1 or later and a recent version of your web server. Upgrade the underlying library first, then add TLSv1.3 to the enabled protocol list. If you are behind a CDN, enabling it there is usually a single toggle.

Something in your ecosystem — an old API consumer, an embedded device, a legacy payment integration — only speaks TLS 1.0 or 1.1.

Identify the clients from your access logs before making the change, and give them a migration deadline. Where a device genuinely cannot be upgraded, isolate it behind a separate endpoint rather than weakening your main site for everyone.

The protocol version is only half the picture. TLS 1.2 with RC4, 3DES or export-grade ciphers is not secure regardless of the version number.

Restrict the cipher list to modern AEAD suites using ECDHE key exchange, which provides forward secrecy. Mozilla publishes maintained configuration templates for every common server, and using their intermediate profile is the simplest reliable approach.

Best Practices

Enable TLS 1.2 and 1.3 only, and refuse everything older
Prefer TLS 1.3 where your platform supports it
Restrict TLS 1.2 to strong AEAD cipher suites with ECDHE key exchange
Review access logs before disabling a protocol to identify affected clients
Use Mozilla published server configuration profiles rather than hand-tuning
Re-test after every server or library upgrade
Apply the same policy to mail servers and APIs, not just the website

Security Recommendations

Treat any accepted legacy protocol as a downgrade path, regardless of what modern clients actually negotiate
Disable TLS 1.0 as a compliance priority, since PCI DSS has prohibited it since 2018
Configure cipher suites deliberately — a modern protocol version with weak ciphers is still weak
Ensure forward secrecy through ECDHE so that recorded traffic cannot be decrypted later if a key is compromised
Apply the same standards to internal services, which are frequently left on outdated configurations
Monitor for protocol downgrade attempts in your logs as a possible attack signal

Frequently Asked Questions

TLS 1.2 and TLS 1.3 only. Everything older is deprecated and provides a downgrade path. No current browser requires TLS 1.0 or 1.1.

Yes, provided it is restricted to strong cipher suites using ECDHE key exchange and AEAD ciphers. It is still widely needed for compatibility with older API clients, so disabling it entirely is usually premature.

They depend on outdated cryptographic primitives including SHA-1 and MD5, and are vulnerable to attacks such as BEAST. RFC 8996 formally deprecated both in 2021, and all major browsers removed support in 2020.

A faster handshake requiring one round trip instead of two, forward secrecy by default, removal of all legacy cipher suites, and encryption of more of the handshake itself. It is both faster and more secure with no trade-off.

Possibly, if you have legacy API consumers or embedded devices that only speak the older protocols. Check your access logs for the negotiated version before making the change, and give affected clients a migration deadline.

Yes. PCI DSS has prohibited TLS 1.0 for card data environments since June 2018, and TLS 1.1 is strongly discouraged. TLS 1.2 or higher is required.

No. Cipher suite selection matters just as much. TLS 1.2 configured with RC4 or 3DES is not secure. Restrict to modern AEAD suites with ECDHE key exchange, and use a maintained configuration profile rather than assembling one by hand.