SSL Toolkit Logo

Protocol Version Matrix

Check supported TLS/SSL protocol versions

Results


        

About

The Protocol Version Matrix shows which TLS and SSL protocol versions are supported by your server, along with their security status and client compatibility. It provides a clear view of TLS 1.3, TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0, and SSL 2.0 support with color-coded security ratings.

This matrix helps you understand the security implications of your protocol configuration and plan protocol deprecation strategies. It shows which client populations would be affected by disabling older protocols, helping you make informed decisions about security versus compatibility.

How to Use

  1. 1Enter the domain name you want to analyze
  2. 2Click "Check Protocol Versions" to scan all supported protocols
  3. 3Review the matrix showing supported/unsupported versions with security ratings
  4. 4Use the compatibility data to plan protocol deprecation if needed

Use Cases

  • •Security Assessment:** Quickly identify which protocol versions are enabled and their security implications
  • •Deprecation Planning:** Understand which clients would be affected by disabling TLS 1.0 or 1.1
  • •Compliance Verification:** Verify that only approved protocol versions are enabled for PCI DSS, NIST, or HIPAA
  • •Compatibility Testing:** Check protocol support across different client types and browsers
  • •Migration Monitoring:** Track protocol support changes during server upgrades or configuration updates

How Each Version Is Tested

A version counts as supported only when a handshake restricted to exactly that version succeeds. Pinning both ends of the range is what makes the answer mean anything.

  1. 1Offer each version alone in its own connection, with the minimum and maximum both set to it. A server that merely prefers modern versions while still accepting old ones answers yes to the old ones too, which is exactly what needs detecting.
  2. 2List deprecated versions found alongside the recommended set, so the report shows both what is acceptable and what should not be reachable.
  3. 3State the limits plainly. An earlier version of the related matrix page tested SSLv2 and SSLv3 using a context that disabled those versions rather than requiring them, so it reported both as supported on every host. Here the untestable versions are left out and the reason is given.

The result describes one connection's worth of negotiation. A server may negotiate differently for different client types, so where you suspect a split, test from more than one vantage point.

Tips & Best Practices

  • •Disable TLS 1.0 and 1.1 unless you have specific legacy client requirements
  • •TLS 1.3 should be preferred for its security and performance improvements
  • •Monitor client traffic to understand what percentage of users still need older protocols
  • •Plan protocol deprecation with advance notice to affected users

Technical Details

●Protocols Tested: TLS 1.3, TLS 1.2, TLS 1.1, TLS 1.0, SSL 3.0, SSL 2.0
●Security Ratings: Secure (TLS 1.3), Strong (TLS 1.2), Deprecated (TLS 1.1/1.0), Insecure (SSL 3.0/2.0)
●Client Data:** Browser and OS compatibility matrix for each protocol version
●NIST Compliance:** Comparison against NIST SP 800-52 Rev 2 protocol requirements

Frequently Asked Questions

For most modern websites, yes. TLS 1.0 and 1.1 are deprecated by all major browsers and have known vulnerabilities. However, if you have legacy clients (older Android devices, older Windows systems), check your traffic analytics first. If less than 1% of traffic uses these protocols, the security benefit of disabling them outweighs the compatibility cost.
TLS 1.3 reduces the handshake from 2 round trips to 1, removes weak cipher suites (RC4, 3DES, AES-CBC), requires forward secrecy, and simplifies the protocol. It is both faster and more secure than TLS 1.2. All modern browsers support TLS 1.3.
TLS 1.3 support depends on your TLS library version. OpenSSL 1.1.1+ supports TLS 1.3. For Nginx, add TLSv1.3 to ssl_protocols. For Apache, add -all +TLSv1.3 to SSLProtocol. For HAProxy, set ssl-min-version TLSv1.3. Restart the server after configuration changes.
The deprecated list is the part to read first, because it names the exact versions that are still negotiable rather than reducing them to a count. Each entry corresponds to a configuration setting somewhere in your stack, so TLS 1.0 on the list points you at one directive and 1.1 points at another. The recommended set shown alongside it is what the remaining versions should look like — anything not on the deprecated list and not in the recommended set is worth understanding on its own terms.
That a client can be forced down to it. A downgrade-capable attacker who can influence the handshake may talk a modern client into an older protocol, where weaker constructions apply — and on TLS 1.0 and 1.1 the padding-oracle attacks are practical. The finding means the option exists, not that it is being used; disabling the old versions removes it regardless.
Not necessarily, and that is why a single test can mislead. Some servers offer different version ranges to different client types, and some middleboxes block 1.3 while passing 1.2 through cleanly — so a test from one location may not represent what users elsewhere see. When the result disagrees with expectation, test from a second network before changing configuration.
Because the two answer different questions. The downgrade checker reduces every version to a single risk grade, which is what you want for a yes-or-no decision. This page keeps the per-version results as a table alongside the deprecated list, which is what you want when you need to know which specific version is still negotiable so you can find where in your configuration it is enabled. Same measurements, different shape of answer — use whichever fits the question in front of you.
After any change to TLS configuration, and on a schedule for anything you did not change. The failures it catches are silent: a server accepting an old version does not break your own modern clients, so nothing alerts you. It also pairs naturally with the configuration snapshots — one shows the negotiated version, the other shows what remains reachable.