What this tool checks
A TLS server can be configured to accept a range of protocol versions and cipher suites, but a single connection only ever reveals what was negotiated for that handshake — usually the newest, strongest option both sides support. This tool deliberately pins each connection to one specific protocol version at a time (TLSv1 through TLSv1.3), to map out everything the server is configured to accept, not just what it prefers to use.
Why a support matrix matters more than a single result
A server can present a perfectly modern TLSv1.3 connection to your browser while quietly still accepting TLSv1.0 from a client — or an attacker — that specifically asks for it. This is a downgrade attack surface: if any legacy protocol or cipher is still accepted, it remains exploitable regardless of what modern clients actually use day to day. Configuring a server to reject old protocols outright (not just deprioritize them) is the only way to close that door completely.
What "untested" means, and why it's not a false negative
Testing a specific protocol version means forcing a connection that many modern servers will simply refuse to attempt at the TCP level for old versions, and a genuine network hiccup (a timeout, a dropped packet) looks identical to that from the outside. This tool distinguishes the two: an active rejection means "not supported" (the informative result you want), while an infrastructure failure is reported as "untested" — worth a retry, not evidence either way.