Chapter 8 — Quantum and post-quantum security: failure modes
Lesson map
Lesson 08 published. Map, example, EX022.
flowchart TD
N0["Learning outcomes"]
N1["8.1 Common failure modes"]
N2["8.2 Safe first responses"]
N3["8.3 Silent fallback deserves alerts"]
N4["8.5 Hands-on activity"]
N5["8.6 Rollback rules"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX022"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["8.1 Common failure modes"]
N2["8.2 Safe first responses"]
N3["8.3 Silent fallback deserves alerts"]
N4["8.5 Hands-on activity"]
N5["8.6 Rollback rules"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX022"]
[Learning outcomes]
|
v
[8.1 Common failure modes]
|
v
[8.2 Safe first responses]
|
v
[8.3 Silent fallback deserves alerts]
|
v
[8.5 Hands-on activity]
|
v
[8.6 Rollback rules]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX022]
Learning outcomes
You will (1) list ways post-quantum changes can fail; (2) recognise each from symptoms; (3) know the safe first response; and (4) avoid fixes that remove protection everywhere.
8.1 Common failure modes
Large handshake dropped: an old firewall, proxy or load balancer cannot handle the bigger first message; symptom: timeouts on one path only. No shared group: client and server have no algorithm in common, often after removing classical options too early. Silent fallback: hybrid is offered but classical is chosen, because of order or old clients; symptom: nothing breaks, but logs show classical. Certificate failure: a client cannot check a post-quantum certificate or does not trust the new root. Slow devices: small devices take longer for larger messages.
8.2 Safe first responses
Collect evidence first (time, client, path, error). Limit impact narrowly: route the affected client group to a compatible listener, or roll back the change on the affected site only. Do not disable hybrid everywhere because of one path; that removes protection from all other traffic.
At HHG, the Summit timeout was handled this way: the front-desk subnet was routed to a listener without the hybrid group while the firewall was fixed. Every other property kept hybrid protection. Record the narrow measure as an exception with an end date.
8.3 Silent fallback deserves alerts
Because nothing breaks, silent fallback can last for months. Add an alert when the hybrid share on a service drops sharply, and check the last change on that service first.
At HHG, the booking API's drop from 88 % to 2 % produced no errors at all; only the hybrid share showed it. Set the alert threshold from normal variation on each service, and link the alert to the runbook for hybrid share drops. Make sure the alert reaches someone who can act, and that it names the service and the size of the drop.
8.4 Worked example
After a load-balancer update at the data centre, the booking API's hybrid share falls from 88 % to 2 % with no errors. The operator checks the change log: the update restored a default TLS profile. Restoring the approved profile returns the share to 87 % within ten minutes. A note is added to the change checklist: "Re-apply TLS profile after firmware updates."
The operator followed the safe order: evidence first, then the last change, then a narrow fix. The checklist note turns the incident into a lasting improvement.
8.5 Hands-on activity
For each failure mode listed in this chapter, write the symptom you would see on the dashboard or in a ticket, and your first check.
Cover all five: large handshake dropped, no shared group, silent fallback, certificate failure and slow devices. For each, write what an operator would actually see, such as a ticket from one property, a falling hybrid share or a certificate error in a client log, and the first check you would run. Keep each first check safe and narrow. Compare with Chapter 13's typical fixes when you reach it.
8.6 Rollback rules
Every change that touches cryptographic settings needs a written rollback: the exact previous configuration, who may trigger rollback, and how to confirm success. Prefer rolling back one site or listener rather than the whole estate. After rollback, keep the evidence and open a problem ticket so the cause is fixed instead of the change being forgotten.
At HHG the approved TLS profile is stored in version control, which made the booking API rollback quick and exact. Test the rollback in staging too.
8.7 Common errors and limits
- Global disable to fix a local fault.
- No alert for silent fallback.
- Rollbacks without evidence.
Each error causes harm. Disabling hybrid everywhere because of one path, such as Summit's firewall, removes protection from every other property. Without an alert, silent fallback can last for months, as the booking API's profile reset could have done. A rollback without evidence leaves the cause unknown, so the same fault returns at the next change. Check your change plans and runbooks for all three before approval.
Exercises
- EX022 — Symptom match. Match symptoms to failure modes: timeouts through one proxy; "no shared group" error; hybrid share drops, no errors. Rubric: 3 = three correct matches.
- EX023 — First response. A guest portal path through one property firewall times out. Give three first steps. Rubric: 3 = evidence, narrow mitigation, escalate/owner.
- EX024 — Checklist line. Write a change-checklist line that would have prevented the incident in 8.4. Rubric: 3 = specific, checkable.
Synthesis
Post-quantum changes fail in a few recognisable ways; operators collect evidence, limit impact narrowly, alert on silent fallback and keep rollbacks local.
Continue studying — chapter 08 of 18
← Chapter 07 (draft) · Course chapter index · Chapter 09 (draft) →