TLS audit and middleboxes

0.2.0

New in pqdoctor 0.2.0. Both are opt-in, for one host or a scan.

–audit

pqdoctor legacy.example.com --audit

About 60 ordinary ClientHellos, one at a time, 150 ms apart:

1. Versions: SSL 3.0, TLS 1.0, 1.1 and 1.2, each offered alone as legacy_version, and TLS 1.3 through supported_versions.
2. Cipher suites: each of 51 TLS 1.2 suites (codepoints and names from IANA) offered alone, under TLS 1.2 or the newest older version the server speaks. The ServerKeyExchange gives the curve of an ECDHE suite and the prime’s size of a DHE suite.
3. Server preference: the weakest accepted suite offered before the strongest. If the server still picks the strongest, it uses its own order.
4. Extensions: whether the ServerHello echoes extended_master_secret (RFC 7627) and renegotiation_info (RFC 5746).

Audit
  versions: TLS 1.0, TLS 1.1, TLS 1.2
  3 suites accepted under TLS 1.2 (of 51 tested), server's order
    · TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (P-256)
    · TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (ffdhe-1024)
    · TLS_RSA_WITH_3DES_EDE_CBC_SHA
  [medium] 64-bit block ciphers accepted — SWEET32 (CVE-2016-2183)
  [high] Diffie-Hellman group under 2048 bits — Logjam (CVE-2015-4000)

That’s 3des.badssl.com on 2026-10-15, shortened. tls-v1-0.badssl.com:1010, rc4.badssl.com and cbc.badssl.com gave the BEAST, RC4 and Logjam findings their names suggest.

Findings

id	Severity	When	Known issue
sslv3	high	SSL 3.0 answers	POODLE (CVE-2014-3566)
tls10, tls11	medium	TLS 1.0 / 1.1 answer	Deprecated by RFC 8996
cbc-tls10	medium	A CBC suite is picked for a TLS 1.0 client	BEAST (CVE-2011-3389)
rc4	high	An RC4 suite is accepted	RC4 biases (CVE-2013-2566, CVE-2015-2808)
3des	medium	3DES, DES or IDEA (64-bit blocks)	SWEET32 (CVE-2016-2183)
null	high	A NULL suite (no encryption)	—
export	high	An EXPORT suite	FREAK (CVE-2015-0204), Logjam (CVE-2015-4000)
anon	high	Anonymous Diffie-Hellman	—
weak-dh	high	A DHE prime under 2048 bits	Logjam (CVE-2015-4000)
rsa-kex	low	RSA key exchange (no forward secrecy)	ROBOT-class risk, not tested
no-ems	low	No extended master secret	Triple handshake (CVE-2014-1295)
no-secure-renegotiation	medium	No renegotiation_info	CVE-2009-3555
client-order	low	Takes the client’s order	—

By configuration only

pqdoctor never sends an exploit, a padding-oracle probe, a renegotiation, Heartbleed bytes or a malformed record. A finding says the server’s configuration exposes it to a known issue; whether the implementation is actually vulnerable isn’t tested.

–middlebox

pqdoctor example.com --middlebox

Eight deliveries of a hello, one connection each:

id	What’s sent
split-header	The post-quantum hello, split after the 5-byte record header
split-1, split-200, split-512	Split after 1, 200 and 512 bytes (two TCP segments, 40 ms apart)
two-records	The same handshake message in two TLS records
size-1200, size-1400, size-1600	A classical hello padded to that many bytes, sent whole

A healthy server answers all of them (github.com did, on 2026-10-15). A load balancer, firewall or TLS-inspecting proxy that can’t reassemble, or that drops big hellos, fails some, and failed lists which. This is the detail behind large-hello-dropped and pq-split-dropped.