HollowLock

Problem

During the transition, servers are configured to try hybrid post-quantum key exchange and fall back to classical cryptography when the other side cannot use it. That fallback is deliberate and invisible: a server can advertise post-quantum support, negotiate classical key exchange on every real connection, and never produce an error. Turning post-quantum on and actually enforcing it are different states, and few operators can see which one they are in.

Approach

HollowLock is a local application. It writes its own TLS 1.3 ClientHello at the byte level and reads the ServerHello, so it does not depend on the local OpenSSL supporting post-quantum groups. It runs three probes against a host:

• offer only post-quantum hybrid groups (a capable server retries and picks one; an incapable one refuses);
• offer hybrid and classical groups together (what an ordinary browser gets by default);
• offer classical groups only (confirms the fallback path).

The answers place the host in one of three verdicts: Enforced (post-quantum offered and used by default), Partial (available, but classical wins by default) or Hollow (no post-quantum key exchange). Each scan ends with a cryptographic bill of materials built from the host’s real configuration, marking each asset as quantum-safe or not with the change it needs, exportable as a PDF signed with ML-DSA-65.

Observations

In the author’s scans, post-quantum status often belonged to whoever answered the connection, usually a CDN, rather than to the organisation named in the address bar: one institution inherited protection from its CDN without having acted, and two properties of another sat on different infrastructure and returned different verdicts.