Chapter 27 — Cryptography and trust services: verification
Lesson map
Lesson 27 published. Map, example, EX079.
flowchart TD
N0["Learning outcomes"]
N1["27.1 Configuration verification"]
N2["27.2 Testing validation"]
N3["27.3 Reporting findings"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX079"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["27.1 Configuration verification"]
N2["27.2 Testing validation"]
N3["27.3 Reporting findings"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX079"]
[Learning outcomes]
|
v
[27.1 Configuration verification]
|
v
[27.2 Testing validation]
|
v
[27.3 Reporting findings]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX079]
Learning outcomes
You will (1) verify cryptographic configurations against requirements; (2) test certificate validation in applications; (3) report findings with evidence.
27.1 Configuration verification
Priya verifies Tidewell's services against its cryptographic requirements: TLS 1.2 minimum with TLS 1.3 preferred, certificates from approved authorities, no SHA-1 signatures and HSTS on public sites. With authorisation she runs configuration scanners and records results. The patron portal passes; the staff wiki, already flagged in Chapter 7, now supports TLS 1.3 but still accepts TLS 1.0, so the earlier change was incomplete. Verification after changes catches partial fixes. Priya reopens the original ticket and attaches the scan output, so the team can see exactly which protocol versions remain enabled and why the change was incomplete.
27.2 Testing validation
Applications must reject bad certificates. In a test environment Priya presents a reporting application with an expired certificate, a certificate for the wrong name and a self-signed certificate. The application rejects the first two but accepts the self-signed one, because a developer had added it to a trust list during testing and never removed it. She reports the issue and suggests that test trust settings live only in test configuration files that cannot ship to production. The developer removes the entry the same day.
27.3 Reporting findings
Priya's report lists each finding with severity, evidence, affected system and recommended fix, and separates confirmed findings from observations. She avoids sensational language and includes what passed, so readers see the overall state. Grace uses the report to schedule fixes, and Priya retests after each fix, recording dates. The report becomes evidence for the consortium's annual security review. Grace presents the summary to the consortium board, which approves budget for the remaining fixes. Priya keeps the raw scan outputs and test logs in the evidence store, linked from the report, so later reviewers can check every statement she made.
Worked example
Priya verifies TLS settings, finds the staff wiki still accepting TLS 1.0 and a reporting app trusting a leftover self-signed certificate, and reports with evidence and retests.
Synthetic case. Findings are invented.
Errors and limits
Scanners miss application-level validation flaws; test them directly. Reports that omit passes distort the picture.
Exercises
- EX079 — Partial fix. What did verification reveal about the staff wiki? Rubric: 3 = supports TLS 1.3 but still accepts TLS 1.0, so earlier fix incomplete;; 2 = partial;; 1 = fixed;; 0 = none.
- EX080 — Self-signed acceptance. Why did the reporting app accept a self-signed certificate? Rubric: 3 = a developer added it to the trust list during testing and never removed it;; 2 = test leftover;; 1 = bug in TLS;; 0 = none.
- EX081 — Report contents. What does each finding in the report include? Rubric: 3 = severity, evidence, affected system, recommended fix;; 2 = three;; 1 = one;; 0 = none.
Synthesis
Verification after changes, direct validation tests and evidence-based reports keep cryptographic configurations honest.
Continue studying — chapter 27 of 40
← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →