Chapter 17 — Quantum and post-quantum security: tooling
Lesson map
Lesson 17 published. Map, example, EX033.
flowchart TD
N0["Learning outcomes"]
N1["17.1 Tool classes"]
N2["17.2 Practical activity — Lab T"]
N3["17.3 Evaluating tools"]
N4["17.4 Authorized use"]
N5["17.7 Making tools routine"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX033"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["17.1 Tool classes"]
N2["17.2 Practical activity — Lab T"]
N3["17.3 Evaluating tools"]
N4["17.4 Authorized use"]
N5["17.7 Making tools routine"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX033"]
[Learning outcomes]
|
v
[17.1 Tool classes]
|
v
[17.2 Practical activity — Lab T]
|
v
[17.3 Evaluating tools]
|
v
[17.4 Authorized use]
|
v
[17.7 Making tools routine]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX033]
Learning outcomes
You will (1) use configuration audits to detect classical-only and misordered services; (2) combine scanners, log parsers and image analysers; (3) evaluate tool output critically; and (4) integrate tools into routine checks.
17.1 Tool classes
Configuration auditors read server configuration and report offered groups and preference. Active TLS/SSH clients in a lab or authorized scope report what a server negotiates. Log parsers summarise negotiated algorithms from production logs. Image and binary analysers find library versions. Certificate inventories list signature algorithms and validity. Each sees part of the picture.
KLS runs all five classes and keeps them separate in the CBOM, each with its own method label. When they disagree, the disagreement is investigated rather than averaged.
17.2 Practical activity — Lab T
# Lab T (ch 17): audit synthetic TLS server configurations for post-quantum key exchange and preference order.
configs = { # service: ordered list of offered groups (server preference) - synthetic
"api-gateway": ["X25519MLKEM768", "X25519", "secp256r1"],
"customer-portal": ["X25519", "X25519MLKEM768", "secp256r1"],
"partner-sftp": ["ecdh-sha2-nistp256"],
"internal-grafana": ["X25519", "secp384r1"]}
HYBRID = {"X25519MLKEM768", "SecP256r1MLKEM768", "SecP384r1MLKEM1024"}
for svc, groups in configs.items():
offered = [g for g in groups if g in HYBRID]
if not offered: verdict = "CLASSICAL ONLY"
elif groups[0] in HYBRID: verdict = "OK (hybrid preferred)"
else: verdict = "WARN hybrid offered but not preferred"
print(f"{svc:17s} {verdict}")
Expected output:
api-gateway OK (hybrid preferred)
customer-portal WARN hybrid offered but not preferred
partner-sftp CLASSICAL ONLY
internal-grafana CLASSICAL ONLY
The customer portal offers hybrid but prefers X25519 — a quiet misconfiguration that a simple "is hybrid present?" check would miss.
The audit reads only the configured group list, so it answers two questions without touching any server: is a hybrid group present, and is it first. The gateway passes; the portal lists X25519MLKEM768 second and is flagged; SFTP and Grafana have no hybrid group at all. Notice that partner-sftp is an SSH service with an SSH algorithm name; the lab treats it with the same rule, but a production audit should check SSH names such as mlkem768x25519-sha256 separately. Extending the HYBRID set or the rules is a code change reviewed like any other.
17.3 Evaluating tools
Ask what a tool actually observes, from where, with which client library. An active scanner using an old library cannot negotiate hybrid and will report every server as classical. Validate tools against a lab server with known configuration before trusting them.
KLS validates each tool against three lab servers: hybrid preferred, hybrid offered but not preferred, and classical only. A tool that reports all three correctly, with its version recorded, is allowed in routine use; one that cannot tell the first two apart is limited to presence checks and labelled so in the CBOM.
17.4 Authorized use
Active scanning of services requires authorization even inside your organization; scope it to listed hosts and agreed windows. Never scan partners or third parties without written permission.
At KLS the written scope lists hostnames, ports, the scanner host, the time window and the contact who can stop the scan. Partner SFTP servers are never scanned; their support is learned from KLS's own server logs when partners connect, which needs no permission because it observes KLS's side only.
KLS runs its TLS group scans on Tuesday mornings and posts the scanner host's address in the SRE channel first; the one scan that ran without notice was paged as a possible intrusion and cost an hour of on-call time.
17.5 Worked example
KLS's first active scan reported "0 % hybrid" across the estate. The scanner's bundled OpenSSL predated ML-KEM support. After upgrading the scanner and validating it against the lab server, the scan showed the API gateway and CDN-fronted services negotiating hybrid, consistent with logs.
The lesson KLS drew was procedural. Validation against the lab's three known servers is now a precondition for any scanner result reaching the dashboard, and the scanner's library version is printed in every report. The "0 %" report was withdrawn with a note explaining why, so nobody later cited it.
17.6 Common errors and limits
- Trusting tool output without validation.
- Checking presence rather than preference.
- Scanning outside authorized scope.
The 0 % scan is KLS's example of the first error: the tool, not the estate, was classical. The second is the portal: a presence check passed it, a preference check flagged it. The third is a risk KLS avoided by scoping: a scanner pointed at a partner's SFTP server would have been unauthorized testing of a third party, regardless of intent. Tool limits remain: configuration audits miss hops that are not exported, and active scans see only what their client library can negotiate.
17.7 Making tools routine
Run configuration audits nightly against exported configuration and publish the result to the same dashboard as negotiation logs. A configuration audit that disagrees with logs is a signal: either the configuration export is stale, or a hop not in the export is changing negotiations. Keep each tool's version and validation record in the repository, and re-validate after every tool upgrade, since a scanner whose bundled library changes can silently change its findings.
Where possible, prefer passive and configuration-based tools for routine use and reserve active scanning for scheduled, authorized windows. This keeps operational load low and avoids surprising service owners with probes they did not expect.
Exercises
- EX033 — Extend Lab T. Add a rule that flags services offering more than four groups as "review". Rubric: 3 = working code and sensible output.
- EX034 — Tool validation. Describe how to validate a TLS scanner before use. Rubric: 3 = lab server with known configurations, positive and negative cases.
Synthesis
Tools see different slices; implementers validate them against known configurations, check preference as well as presence, and use them within authorized scope.
Continue studying — chapter 17 of 30
← Chapter 16 (draft) · Course chapter index · Chapter 18 (draft) →