Chapter 10 — Quantum and post-quantum security: control configuration | Technical Quantum and post-quantum security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 10 — Quantum and post-quantum security: control configuration

Lesson map

Lesson 10 published. Map, example, EX028.

flowchart TD
  N0["Learning outcomes"]
  N1["10.1 TLS configuration"]
  N2["10.2 SSH configuration"]
  N3["10.3 Practical activity — Lab T"]
  N4["10.4 Change control"]
  N5["10.6 Hands-on activity"]
  N6["10.7 Keep fallback for now"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX028"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["10.1 TLS configuration"]
  N2["10.2 SSH configuration"]
  N3["10.3 Practical activity — Lab T"]
  N4["10.4 Change control"]
  N5["10.6 Hands-on activity"]
  N6["10.7 Keep fallback for now"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX028"]

[Learning outcomes]
    |
    v
[10.1 TLS configuration]
    |
    v
[10.2 SSH configuration]
    |
    v
[10.3 Practical activity — Lab T]
    |
    v
[10.4 Change control]
    |
    v
[10.6 Hands-on activity]
    |
    v
[10.7 Keep fallback for now]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX028]

Learning outcomes

You will (1) configure hybrid key exchange on TLS and SSH servers in a lab; (2) audit configurations for presence and preference; (3) keep classical fallback during transition; and (4) apply changes through change control.

10.1 TLS configuration

On OpenSSL-based servers, set the group list with hybrid first, for example X25519MLKEM768:X25519:secp256r1. Web servers and load balancers expose this through a directive or profile; check your product documentation for exact names. Order matters when the server decides.

At HHG, the guest portal's load balancer listed X25519 first, so most clients negotiated classical. Keep classical groups after the hybrid, not instead of it, and save the exact group string in the baseline so every listener uses the same order.

10.2 SSH configuration

In OpenSSH's server configuration, put mlkem768x25519-sha256 first in KexAlgorithms, followed by sntrup761x25519-sha512@openssh.com and curve25519-sha256 for compatibility. Reload the service and test with ssh -v from a client that supports the hybrid.

At HHG, this is the change the file-exchange server needs after its OpenSSH upgrade. Save the KexAlgorithms line before and after the edit, check the configuration syntax before reloading, and keep an existing session open while you test, so a mistake does not lock you out.

10.3 Practical activity — Lab T

# Lab T (ch 10): audit synthetic TLS and SSH server configurations for post-quantum key exchange and preference order.
configs = {  # service: ordered list of offered groups (server preference) - synthetic
    "booking-api": ["X25519MLKEM768", "X25519", "secp256r1"],
    "guest-portal": ["X25519", "X25519MLKEM768", "secp256r1"],
    "channel-sftp": ["ecdh-sha2-nistp256"],
    "ops-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:

booking-api       OK (hybrid preferred)
guest-portal      WARN hybrid offered but not preferred
channel-sftp      CLASSICAL ONLY
ops-grafana       CLASSICAL ONLY

The guest portal offers hybrid but prefers X25519 — the problem found in Chapter 5. The channel SFTP and ops dashboard are classical only.

The script audits each service's ordered list for two properties: whether any hybrid method is offered and whether one is first. The booking API passes both checks, while the guest portal fails preference and the other two fail presence. Note that channel-sftp's entry is an SSH method, which the script's TLS list does not know; an SSH audit needs its own list of hybrid names, such as mlkem768x25519-sha256. Extend the script to handle that case.

10.4 Change control

Every production change goes through a change ticket: what, why, when, risk, test evidence, rollback, approver. Make the change in staging, verify, then apply in production in a low-traffic window, verify again and close the ticket with evidence.

At HHG, ticket OPS-430 is an example of a complete record. Attach the staging evidence before asking for approval, and close the ticket only after production verification. At HHG, the production change for OPS-430 was made at 06:00 on a Tuesday, a low-traffic time for the guest portal. Record the approver's name.

10.5 Worked example

Ticket OPS-430: reorder groups on guest-portal load balancer to X25519MLKEM768:X25519:secp256r1. Staging test: hybrid negotiated by current clients, X25519 by an old client. Production change Tuesday 06:00; verification at 06:10 shows hybrid negotiated; dashboard hybrid share climbs from 3 % to 85 % by noon. Rollback plan (restore previous order) not needed.

The ticket follows every step: staging test with both client types, a low-traffic window, immediate verification and a measurable result. The rollback was written in advance even though it was not used. The rise in the hybrid share also confirms the Chapter 5 finding.

10.6 Hands-on activity

In the lab, configure a TLS server and an SSH server with hybrid first; verify with clients; write the change ticket you would raise for production.

Put the hybrid method first and keep classical methods after it on both servers. Verify from the client side with openssl s_client and ssh -v, and from the server side with logs. Test with an old client too, to confirm fallback. Then write the production ticket with what, why, when, risk, test evidence, rollback and approver, using OPS-430 as a model.

10.7 Keep fallback for now

During transition, keep classical options after the hybrid so that older clients still connect. Removing them is a separate, later decision based on monitoring that shows few remaining classical clients and agreement with service owners and partners.

At HHG, four travel agencies still used old SFTP clients after the upgrade, so removing classical methods would have cut them off. Monitor the classical share per service and per partner before proposing removal, and record the decision and who agreed it. Removal is not an operator's decision alone.

10.8 Common errors and limits

Hybrid listed after classical.
Removing fallback too early.
Changes without tickets or verification.

Each error weakens protection or control. Listing hybrid after classical means most clients negotiate classical, as on HHG's guest portal. Removing fallback too early cuts off older clients, such as the four agencies on old SFTP clients. A change without a ticket or verification cannot be reviewed, rolled back reliably or proven to work. Check each configuration change for all three before approval. Fix any you find.

Exercises

EX028 — TLS line. Write a group list with hybrid first and two classical fallbacks. Rubric: 3 = hybrid first, valid names.
EX029 — SSH line. Write a KexAlgorithms line with hybrid first and compatible fallbacks. Rubric: 3 = valid ordered list.
EX030 — Ticket. Write the change ticket for enabling hybrid SSH on the channel SFTP server. Rubric: 3 = what, why, when, risk, test evidence, rollback, approver.

Synthesis

Operators configure hybrid first with classical fallback on TLS and SSH, audit preference as well as presence, and make changes through tested, verified tickets.

Continue studying — chapter 10 of 18

← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →