Skip to content

Module 10 — Auditing Applied-Crypto Failures

Type 4 · Audit→Build→Verify — audit a crypto config matrix, score it against OWASP/NIST, and deliver a remediation-delta report; the phase-capstone shape. (Secondary: Adversarial Review — AI proposes broken modes, you verify.) Go to the hands-on lab →

Last reviewed: 2026-06

[Track 08 — Cryptography, PKI & Secrets] — Applied cryptography fails in patterns — knowing the pattern tells you exactly where to look in an audit.

Difficulty: Intermediate  ·  Estimated time: ~5–7 hrs (study + lab)  ·  Prerequisites: Foundations

In 60 seconds

Cryptographic Failures is #2 on the OWASP Top 10 — and the failures are never mathematical. The algorithms are sound; the breaks are configuration and implementation: wrong mode, nonce reuse, hardcoded key, expired cert. Because the set of ways to misapply well-understood primitives is finite and documented, you can audit methodically — run the known failure taxonomy, confirm or rule out each box. The named breaks from this track are the checklist (Heartbleed → "is OpenSSL patched?"). The deliverable isn't a findings dump; it's a severity-scored, context-aware remediation delta.

Why this matters

Cryptography Failures is #2 on the OWASP Top 10 (2021). The failures are not mathematical — the algorithms themselves are sound. They are implementation and configuration failures: using the wrong mode, reusing a nonce, hardcoding a key, generating an IV from a predictable source, trusting an expired certificate. The named breaks you have met across this track are each one box on an audit checklist: Heartbleed (CVE-2014-0160) is "is this OpenSSL version patched?"; ROCA (CVE-2017-15361) is "were these RSA keys generated by a sound implementation?" — testssl.sh checks the first on every run, and a key-provenance review catches the second. These failures are predictable precisely because the set of ways to misapply well-understood primitives is finite and documented. A practitioner who knows the failure taxonomy can audit a system's cryptographic posture methodically — not by guessing, but by running through the known failure categories and confirming or ruling out each one.

Objective

Run testssl.sh against a matrix of TLS configurations with varying weakness levels, score the findings, map each finding to an OWASP or NIST failure category, and produce a structured audit report — the deliverable of a real applied-crypto assessment.

The core idea

Applied cryptography auditing has two distinct layers. The configuration audit checks what algorithms, modes, and protocols are configured — this is what testssl.sh, OpenSSL s_client, and cipher suite scanners do. The implementation audit checks how those algorithms are used in code — this requires source review, dynamic analysis, or both. Both layers produce findings in the OWASP Cryptographic Storage Cheat Sheet's taxonomy: insufficient algorithm (MD5, DES), missing authentication (CBC without MAC), weak key derivation (password used directly as key), nonce reuse, hardcoded key or IV, missing certificate validation, expired or untrusted certificates. Each category maps to a specific audit check and a specific remediation.

The mental model

A crypto audit is not "find weak crypto" — it's running a finite checklist. The ways to misapply sound primitives are countable: wrong mode, nonce reuse, hardcoded key, weak KDF, missing auth, expired/untrusted cert. You don't guess; you walk the taxonomy and mark each box present, absent, or not-applicable. Methodical beats clever here.

The finding severity in a crypto audit is not just about the CVSS score of the algorithm. Context matters enormously. A TLS 1.0 cipher suite on a server that is only accessible from an internal network segment with no adversaries capable of a BEAST attack is a LOW finding in practice, even though TLS 1.0 is deprecated. The same cipher suite on an internet-facing login endpoint is CRITICAL. An expired certificate on an internal health-check endpoint is MEDIUM; the same expiry on the public API that customer applications talk to is HIGH because it causes client errors and may be a sign of certificate lifecycle failure. Assigning severity requires understanding the network exposure, the sensitivity of the data in transit, and the exploitability of the finding in context.

The gotcha

A scanner's severity label is an input, not the answer. The same TLS 1.0 cipher suite is LOW on an isolated internal segment and CRITICAL on an internet-facing login page — exposure, data sensitivity, and exploitability decide severity, not the algorithm's CVSS in the abstract. An audit that copies the tool's labels verbatim hasn't done the judgment that makes it an audit.

The cumulative picture — all three TLS configurations audited, findings tallied, severity distribution charted — is also the mechanism for prioritisation. A system with one CRITICAL (TLS 1.0 on an internet endpoint) and twenty LOW findings (deprecated ciphers on internal services) has a clear remediation priority: fix the CRITICAL first, schedule the LOWs in the next hardening sprint. The crypto audit's output is a prioritised remediation backlog, not a pass/fail judgment.

Go deeper: configuration audit vs implementation audit

The two layers find different bugs and need different tools. The configuration audit — what protocols, modes, and ciphers are switched on — is what testssl.sh and cipher scanners cover; it's fast and largely automatable. The implementation audit — how the code actually uses those algorithms (does it reuse a nonce, derive a key from a password, skip cert validation?) — needs source review or dynamic analysis and no scanner sees it. A clean testssl.sh report says nothing about a hardcoded IV three layers down; both audits are required to claim coverage.

The remediation delta is the practitioner output that distinguishes an audit from a vulnerability scan dump. For each finding, the audit documents: current state (what is configured), recommended state (what the finding requires), effort estimate (a two-line nginx config change vs a code change requiring redeployment), and re-test method (how to confirm the fix). An audit report that only lists findings is half-done; the delta report that pairs each finding with its specific fix is what enables the engineering team to act without another meeting.

AI caveat

An AI is strong at drafting the "recommended state" and "re-test method" columns from a finding — but it will assign severity from the algorithm in the abstract, blind to your exposure and data sensitivity. You own severity, and you confirm every proposed fix against the Mozilla SSL Configuration Generator rather than the model's word.

Learn (~4 hrs)

OWASP Cryptographic Failure taxonomy - OWASP Top 10 — A02:2021 Cryptographic Failures — the canonical failure taxonomy; read the full entry including the example attack scenarios. - OWASP Cryptographic Storage Cheat Sheet — the practitioner reference for storage-layer failures; read the full page.

testssl.sh (revisit from module 05) - testssl.sh GitHub — Severity Rating Documentation — read the README section on severity ratings; understand how the tool assigns CRITICAL, HIGH, MEDIUM, LOW, and INFO severity to each finding.

NIST guidance on cryptographic algorithm deprecation - NIST SP 800-131A Rev 2 — Transitioning the Use of Cryptographic Algorithms — the authoritative list of deprecated and disallowed algorithms; read Tables 1–4 for the algorithm transition schedule.

Applied crypto failure case studies - Moxie Marlinspike — SSL and the Future of Authenticity (DEF CON 19) — a practitioner talk on real-world PKI and TLS failures; ~50 min; explains why the "padlock" is not what users think it is. - NVD — CVE-2014-0160 (Heartbleed) and CVE-2017-15361 (ROCA) — read both descriptions side by side as a model for how a named break becomes an audit check: Heartbleed → "is OpenSSL patched / does testssl.sh flag it?", ROCA → "was this RSA key generated by a sound library?". Each finding line in your report should trace to a failure this concrete.

Key concepts

  • Applied crypto fails in finite, documented patterns: wrong mode, nonce reuse, hardcoded key, missing auth, weak KDF, expired/untrusted cert.
  • Configuration audit (testssl.sh, cipher scanner) vs implementation audit (code review, dynamic analysis) — both are required.
  • Severity depends on context: network exposure, data sensitivity, exploitability — not just the CVSS score of the algorithm.
  • Remediation delta: current state, recommended state, effort estimate, re-test method — for each finding.
  • The audit output is a prioritised backlog, not a pass/fail.
  • Named breaks are audit checks: Heartbleed (CVE-2014-0160) → "is OpenSSL patched?" (testssl.sh flags it); ROCA (CVE-2017-15361) → "were these RSA keys soundly generated?" Each finding should trace to a failure this concrete.

AI acceleration

For each finding in your testssl.sh output, ask an AI: "What is this TLS finding, which OWASP cryptographic failure category does it map to, and what is the specific nginx or server configuration that fixes it?" Use the answer to write the "recommended state" and "re-test method" columns in your audit table. Verify the fix against the Mozilla SSL Configuration Generator — does the generated config match the AI's recommendation?

Check yourself

  • The same TLS 1.0 cipher suite appears on two hosts. Why might it be a LOW finding on one and CRITICAL on the other?
  • Why is a clean testssl.sh report insufficient to declare a system's crypto sound — what class of failure does it never see?
  • What four things does a remediation-delta entry record for each finding, and why does that turn a scan dump into an audit?

Comments

Sign in with GitHub to comment. Choose the type: Feedback (errors or suggestions on this page) · Hints (help for fellow learners — no spoilers) · General (anything else).