Why pinning one version/cipher at a time is the only reliable way to test this

A normal TLS handshake lets the client offer a whole list of acceptable versions and ciphers, and the server picks its preferred one from the overlap — which tells you what the server picked, but not what else it would have accepted. To find out whether a server truly still allows a weak, older cipher or protocol version, this tool restricts the ClientHello to offer exactly one option at a time (pinning min/max protocol version, or offering only a single cipher suite) and sees whether the handshake succeeds or fails. A rejection means the target genuinely won't negotiate that option under any circumstances; an acceptance means it will, even if a normal client's broader offer would never have surfaced that particular choice.

Why "not testable" is a real answer, not an error

This tool runs on the server's installed OpenSSL, and modern OpenSSL builds — like the one behind virtually every current Linux distribution — have removed TLS 1.0/1.1 and legacy ciphers like RC4, 3DES, and export-grade suites entirely, meaning this tool has no way to even construct a ClientHello offering them. That's categorically different from "the target rejected this option": rejection means we tried and the target said no; "not testable" means we structurally couldn't try at all. Collapsing those two into one "unsupported" bucket would misrepresent the target's actual behavior, which is why they're reported as distinct outcomes.

Why forward secrecy is worth a dedicated column

Static RSA key exchange means every session's encryption ultimately derives from the server's long-term private key — if that key is ever compromised (a server breach, a misconfigured backup, a future cryptographic break), every session ever captured that used a non-PFS cipher becomes retroactively decryptable, no matter how long ago it happened. Ephemeral key exchange (ECDHE/DHE) generates a fresh, disposable key for every single session, so a future compromise of the server's long-term key doesn't unlock anything that was already captured. This is exactly the property that made mass surveillance of "harvest now, decrypt later" traffic captures a real concern, and it's why modern TLS configuration guidance treats forward secrecy as effectively mandatory rather than optional.