TLS cipher suites

Website test: enumerates the suites individually – it repeatedly offers everything the engine can encode (with OpenSSL @SECLEVEL=0, so weak suites are offered too) minus what the server has already chosen, and probes each of the five TLS 1.3 suites, to report which ones a server accepts. The iteration is bounded by a suite cap and a time budget; when it stops early the report says so – a partial result is marked with a leading “≥” and is never used to claim that something is absent.

Mail test (STARTTLS): classifies the suite the mail server negotiates, runs two targeted downgrade probes per MX – one for obsolete TLS ≤ 1.1 and one for the weak families (RC4, 3DES, DES, export, NULL) – and enumerates the suites per TLS version for one representative MX: the reachable host with the lowest preference. The other reachable MX are compared by certificate fingerprint and negotiated suite instead of being enumerated, which keeps the outbound port-25 footprint small (blacklist protection). The enumeration has a connection and time budget, and the report says when it was reached.

Engine note: the list below is what our TLS engine (Node.js / OpenSSL) reports as enabled, plus the five TLS 1.3 suites. Modern OpenSSL 3.x can no longer encode some long-broken families at all – our probes cannot solicit those, and the report names them per scan instead of giving an all-clear. NULL and anonymous suites are a different case: they are absent from the list, yet our probes can still offer them at @SECLEVEL=0, so a server accepting one is detected and capped at F. The remaining legacy entries (CBC mode or static-RSA key exchange) are flagged as legacy/acceptable, not weak.