Chapter 5: Applied Cryptography: TLS, VPNs, Disk Encryption, and Securing Data in Transit and at Rest

"There are two kinds of cryptography in this world: cryptography that will stop your kid sister from reading your files, and cryptography that will stop major governments from reading your files." — Bruce Schneier

Overview

The penetration testers Meridian Regional Bank hired for its annual assessment did not break any cryptography. They did not need to. They sat on the guest WiFi in a branch lobby, pointed a free, off-the-shelf scanning tool at the bank's own externally facing services, and within an hour had a one-page finding that made CISO Dana Okafor wince: one of Meridian's marketing microsites — a forgotten thing spun up for a mortgage promotion three years earlier — still negotiated TLS 1.0, still offered cipher suites with RC4 and 3DES, and presented a certificate that had expired six weeks ago and was being silently accepted by nobody, because nobody was visiting the site, which is exactly why nobody had noticed. None of that was a cryptographic break. Every algorithm involved was, once, considered fine. The failure was that time had moved and the configuration had not, and an attacker positioned between a customer and that site could have downgraded the connection to something breakable and read or altered everything that crossed it.

That is the shape of almost every real-world cryptographic failure you will ever investigate. The mathematics — the AES, the RSA, the elliptic curves you met in Chapter 4 — is, with vanishingly rare exceptions, not the part that fails. What fails is the application of cryptography: a protocol negotiated down to a weak version, a cipher suite left enabled a decade past its expiry, a certificate that lapsed because no one owned its renewal, a private key copied onto a laptop that walked out a door, a database "encrypted" with a key sitting in a file right next to it. Chapter 4 gave you the primitives. This chapter is about wielding them in the systems that actually carry a bank's data: the TLS that protects every online-banking session, the VPNs that connect branches and remote staff, the disk and database encryption that protects data at rest, and the certificate and key management that holds the whole edifice together.

🔗 Connection: This chapter stands entirely on Chapter 4. We will use its vocabulary — symmetric and asymmetric encryption, AES, RSA, ECC, hash functions, HMAC, digital signatures, the public key infrastructure (PKI), the certificate authority (CA), and X.509 certificates — without re-defining any of it. If "Diffie–Hellman key exchange," "the key-distribution problem," or "a CA signs a certificate to bind a name to a public key" do not yet feel solid, revisit Chapter 4 before going on. Everything here is the applied layer on top of those primitives.

This is a Security Engineer's and a Certification candidate's chapter above all — but every defender meets weak TLS in a scan report, an expired certificate in an outage, and a VPN in an architecture diagram, so the material is foundational for all four paths.

In this chapter, you will learn to:

• Separate the two states of data — in transit and at rest — and choose the right control for each, because the same data needs different protection depending on where it is.
• Trace the TLS 1.3 handshake message by message and say precisely what each step accomplishes, so an outage or a scan finding stops being a black box.
• Read a cipher suite string and judge it, and explain why forward secrecy changes the consequences of a future key compromise.
• Choose and reason about VPN technologies — IPsec and WireGuard — and, just as important, articulate what a VPN does not protect.
• Apply full-disk encryption and database encryption so that they actually defend against the threat you have, which usually comes down to where the key lives.
• Manage a certificate lifecycle — issuance, renewal, revocation, and the HSM and key-management practices behind it — so that the thing that saved you does not become the thing that takes you down at 2 a.m.
• Scan for weak TLS defensively, grade what you find, and feed it into Meridian's remediation queue.

Learning Paths

This chapter is dense and practical. Here is how to weight it by role:

🏗️ Security Engineer: This is your chapter end to end. §5.2–5.4 (TLS, cipher suites, VPNs) are the protocols you will configure; §5.5 (disk/database encryption) and §5.6 (certificate and key lifecycle, HSMs) are the operations you will own. The Project Checkpoint's tls_config_grade is a tool you will reach for. 🛡️ SOC Analyst: Focus on §5.2 (so a TLS error in your logs makes sense), §5.4 (what VPN telemetry looks like), and §5.7 (reading a TLS scan and spotting downgrade attempts). You detect the abuse; the engineers fix the config. 📋 GRC: §5.1 (the in-transit/at-rest distinction maps directly to PCI-DSS and GLBA requirements), §5.5 (encryption-at-rest obligations), and §5.6 (certificate-lifecycle governance) are where audit findings live. "Encrypt cardholder data" is a control you must be able to evidence. 📜 Certification Prep: TLS, cipher suites, forward secrecy, IPsec vs SSL/TLS VPNs, full-disk encryption, HSMs, certificate lifecycle, and tokenization are all heavily tested on Security+ and CISSP. The key-takeaways.md maps each to its exam domain.

5.1 Data in transit versus data at rest

Cryptography is not applied to "data" in the abstract. It is applied to data in a particular state, and the state determines the threat, which determines the control. Getting this distinction crisp is the foundation for every decision in this chapter, and it is the framing every compliance auditor will use when they ask Meridian to prove it protects customer information.

Data in transit is data moving across a network — between a customer's phone and the online-banking server, between a branch and the data center, between an application and a database on another host, between Meridian and a cloud provider. The threat to data in transit is an attacker on the path: someone who can observe the traffic (a passive eavesdropper) or, worse, sit in the middle and alter it (an active attacker). The canonical control for data in transit is a secure transport protocol — overwhelmingly TLS today, with IPsec and WireGuard as the VPN-layer options — which provides confidentiality (the eavesdropper sees ciphertext), integrity (tampering is detected), and authentication (you are talking to the server you think you are).

Data at rest is data sitting in storage — on a disk, in a database, in a backup tape, in an object store, on a lost laptop. The threat to data at rest is an attacker who gains access to the storage medium: a stolen laptop, a decommissioned drive sold without wiping, a database file copied off a compromised server, a misconfigured cloud bucket. The canonical control is encryption of the storage itself — full-disk encryption for endpoints and servers, transparent database encryption and column/field encryption for databases, and provider-managed or customer-managed encryption for cloud storage. Here the central concern is almost never the cipher (it is AES) and almost always key management: where the key lives, who can reach it, and whether it is separated from the data it protects.

🚪 Threshold Concept: A single piece of data passes through both states many times in its life, and needs protection in each. A customer's account number is encrypted in transit by TLS as it travels from the app to the database server; it is then encrypted at rest by database encryption while stored; it is encrypted in transit again as it flows to a backup target; and it is encrypted at rest on the backup medium. Protecting it in one state says nothing about the other. The most common real breach is data that was beautifully encrypted in transit and then written to disk, or to a log, or to a cloud bucket, in the clear. Always ask, for any sensitive data: in which states does this exist, and what protects it in each?

There is a third state worth naming, because vendors and frameworks increasingly do: data in use — data loaded into memory and being processed, where it is necessarily decrypted to be operated on. Protecting data in use is the domain of confidential computing, trusted execution environments, and memory protections; it is an advanced and still-maturing area, and this book treats it only in passing. For the overwhelming majority of a defender's work, the two states that matter and that auditors enforce are in transit and at rest, and this chapter is built around them: §5.2–5.4 protect data in transit; §5.5–5.6 protect data at rest and manage the keys for both.

⚖️ Authorization & Ethics: The defensive techniques in this chapter — especially the TLS scanning in §5.7 — are read-only and safe, but they are still probing systems. Scan only assets your organization owns or you are explicitly authorized to assess. Pointing a TLS scanner at a third party's servers without permission can violate computer-misuse law even though you "only looked." Throughout, assume Meridian's own estate or your own lab.

🔄 Check Your Understanding: 1. A customer's password travels from their browser to Meridian's server, where it is hashed and stored. Name the state of the data at each step and the control that should protect it there. 2. Meridian encrypts a database with transparent encryption but the application writes full account numbers into a debug log file in plaintext. Which state is protected and which is not, and why does the encryption not help the log?

Answers

1. In transit (browser → server): protected by TLS. In use (being hashed on the server): briefly in plaintext in memory by necessity. At rest (the stored hash): protected by the password-hashing scheme from Chapter 4 — note the password itself is not stored, only its hash. 2. The database file is protected at rest; the log file is not. Transparent database encryption protects only the database's own storage; a separate plaintext file written elsewhere is outside that boundary. The data leaked at rest, in a different location the encryption never covered.

5.2 The TLS 1.3 handshake

Every time a customer's browser shows a padlock next to meridianbank.example, a TLS handshake just happened. TLS — Transport Layer Security — is the protocol that secures data in transit for the web and for much else (it is the "S" in HTTPS, and it protects email submission, APIs, database connections, and more). It is the direct successor to SSL (Secure Sockets Layer), a name you will still hear used loosely; SSL itself is long dead and every version of it is insecure. The current version, and the one you should standardize on, is TLS 1.3, defined in RFC 8446 (2018). It is faster and dramatically safer than its predecessor TLS 1.2, having removed an entire museum of broken options.

TLS gives you three guarantees, each mapping to a primitive from Chapter 4. Confidentiality: after the handshake, all data is encrypted with a symmetric cipher (AES, typically in an authenticated mode), so an eavesdropper sees only ciphertext. Integrity: that authenticated encryption also detects any tampering, so an active attacker cannot silently alter the stream. Authentication: the server proves its identity with an X.509 certificate signed by a CA the client trusts, so the client knows it is talking to the real Meridian and not an impostor. The genius of the handshake is that it establishes a shared symmetric key over a network an attacker may be watching, using asymmetric cryptography to do it, and binds that key to an authenticated identity — all in, for TLS 1.3, a single round trip.

Here is the TLS 1.3 handshake, the version you should etch into memory because you will reason about it for the rest of your career:

        CLIENT (browser)                                 SERVER (meridianbank.example)
            │                                                       │
            │  (1) ClientHello                                      │
            │      • supported TLS versions (offers 1.3)            │
            │      • supported cipher suites                        │
            │      • a key share: client's ephemeral DH public key  │
            │      • random nonce, SNI (which host), extensions     │
            │ ─────────────────────────────────────────────────►   │
            │                                                       │
            │                                  (2) ServerHello      │
            │      • chosen TLS version (1.3) + chosen cipher suite │
            │      • a key share: server's ephemeral DH public key  │
            │      ── from here on, everything is ENCRYPTED ──      │
            │      • {EncryptedExtensions}                          │
            │      • {Certificate}      (server's X.509 chain)      │
            │      • {CertificateVerify}(signature over handshake)  │
            │      • {Finished}         (MAC over the handshake)    │
            │ ◄─────────────────────────────────────────────────   │
            │                                                       │
   both sides now derive the SAME symmetric keys from the two       │
   ephemeral DH shares (this is the shared secret) + transcript     │
            │                                                       │
            │  (3) {Finished}  (client's MAC over the handshake)    │
            │ ─────────────────────────────────────────────────►   │
            │                                                       │
            │  (4) Application data, encrypted with the session keys│
            │ ◄════════════════════════════════════════════════►   │
            │                                                       │
   Legend:  {…} = encrypted under handshake keys     1-RTT to first byte of app data

Figure 5.1 — The TLS 1.3 handshake. One round trip establishes an authenticated, encrypted channel. The two ephemeral Diffie–Hellman key shares (steps 1 and 2) let both sides compute the same shared secret without ever sending it; the certificate and CertificateVerify (step 2) authenticate the server; the Finished messages (steps 2 and 3) prove neither side's handshake was tampered with.

Walk through it slowly, because each message earns its place:

(1) ClientHello. The client opens by announcing what it can do: which TLS versions it supports (a modern client offers 1.3), which cipher suites it will accept, and — the key move that makes TLS 1.3 fast — a key share: the client's ephemeral Diffie–Hellman public key. It also sends a random nonce and the Server Name Indication (SNI), telling the server which hostname it wants (one server may host many). The client guesses that the server will accept Diffie–Hellman key exchange and front-loads its share so the secret can be computed in one round trip.

(2) ServerHello and the server's flight. The server picks the highest TLS version both support (1.3) and one cipher suite from the client's list, and sends its own ephemeral Diffie–Hellman key share. With both shares now exchanged, both sides independently compute the same shared secret — and from that point in the message, everything the server sends is already encrypted. Inside that encryption, the server sends its Certificate (the X.509 chain proving it is meridianbank.example), a CertificateVerify (a digital signature over the handshake transcript, proving the server holds the private key matching the certificate — this is what stops an attacker from replaying a stolen certificate they cannot use), and a Finished message (a MAC over the entire handshake so far, proving nothing was altered in flight).

(3) Client Finished. The client validates the certificate chain (is it signed by a trusted CA? is it for the right name? is it unexpired and unrevoked?), verifies the server's signature and Finished, and sends its own encrypted Finished. The handshake is complete.

(4) Application data now flows, encrypted under the derived session keys, with authenticated encryption providing both confidentiality and integrity for every record.

The whole exchange is one round trip (1-RTT) to the first byte of application data, a real improvement over TLS 1.2's two. (TLS 1.3 also offers a 0-RTT mode for resumed connections, which trades a little security — 0-RTT data is replayable — for speed; Meridian disables 0-RTT for its banking endpoints, where the risk is not worth the milliseconds.)

How this gets attacked. The handshake itself is robust, so attackers go after the edges. A downgrade attack tries to trick client and server into negotiating an older, weaker protocol (TLS 1.0/1.1) or cipher suite that the attacker can break — by tampering with the unencrypted ClientHello/ServerHello, or by exploiting a server that still offers the weak options. (TLS 1.3 hardens against this by signing the version negotiation, but a server that still accepts TLS 1.0 at all leaves clients that will speak it exposed.) A man-in-the-middle (MITM) attack tries to terminate TLS at the attacker and re-originate it, which fails against TLS precisely because the attacker cannot produce a valid certificate for meridianbank.example signed by a CA the client trusts — unless the client can be made to trust the attacker's CA (a malicious root certificate installed on the device) or accept an invalid certificate (a user clicking through a warning). And attacks on the certificate itself — an expired cert, a mis-issued cert, a cert with a too-weak key — undermine the authentication leg even when the encryption is perfect.

How you detect and prevent it. Prevention: disable TLS 1.0 and 1.1 (and all of SSL) on every endpoint, offer only TLS 1.2 and 1.3, and configure a strong, ordered cipher-suite list (§5.3). Enforce HSTS (HTTP Strict Transport Security, detailed in Chapter 9) so browsers refuse to downgrade to plaintext HTTP. Detection: your TLS-terminating load balancers and web servers log the negotiated version and cipher for every connection — a sudden rise in TLS 1.0 negotiations, or any negotiation of a cipher you thought you had disabled, is a finding worth chasing. And the scanning in §5.7 catches the offered weaknesses before an attacker does.

🛡️ Defender's Lens: A MITM against well-configured TLS does not look like quietly decrypted traffic — it looks like certificate errors. The attacker, unable to forge a trusted certificate, must present a bad one, and a correctly configured client rejects it loudly. This is why "users trained to never click through certificate warnings" and "applications that pin certificates (§5.6) and refuse bad ones outright" are real anti-MITM controls. The cryptography forces the attack to surface as an error; your job is to make sure that error is never ignored.

🔄 Check Your Understanding: 1. In the TLS 1.3 handshake, what is the purpose of the CertificateVerify message, and what attack does it prevent? 2. Why can an attacker who can read and modify all traffic between a customer and meridianbank.example still not read the customer's banking session, assuming TLS 1.3 and a valid certificate?

Answers

1. CertificateVerify is a signature over the handshake transcript using the certificate's private key; it proves the server actually holds the private key for the certificate it presented, preventing an attacker from replaying a legitimate certificate they captured but whose private key they do not have. 2. Confidentiality comes from the ephemeral Diffie–Hellman shared secret, which the attacker cannot compute from the public key shares alone; and to MITM the connection the attacker would need a certificate for meridianbank.example trusted by the client, which the CA system denies them. Reading and modifying ciphertext gains nothing without the key or a forged identity.

5.3 Cipher suites and forward secrecy

When the server chooses "one cipher suite from the client's list" in step 2, what exactly is it choosing? A cipher suite is a named bundle of cryptographic algorithms that together implement a TLS connection. Reading one is a core defender skill, because a scan report is mostly a list of cipher suites and your job is to know which belong and which are findings.

The naming changed between TLS 1.2 and 1.3, and you must recognize both. A TLS 1.2 cipher suite names four things:

   TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   └┬┘ └─┬─┘ └┬┘      └──────┬─────┘ └──┬──┘
    │    │    │              │          └─ hash for the handshake MAC/PRF (SHA-256)
    │    │    │              └─ symmetric cipher + mode (AES-128 in GCM, an AEAD mode)
    │    │    └─ authentication / certificate type (RSA signature)
    │    └─ key exchange (Ephemeral Elliptic-Curve Diffie–Hellman — note the "E")
    └─ the protocol (TLS)

Read left to right: ECDHE is the key exchange — Ephemeral Elliptic-Curve Diffie–Hellman, the "E" on the end meaning ephemeral, which is the property that gives forward secrecy (below). RSA is the authentication: the server's certificate is an RSA certificate whose private key signs the handshake. AES_128_GCM is the bulk encryption: AES with a 128-bit key in GCM (Galois/Counter Mode), an authenticated-encryption (AEAD) mode that provides confidentiality and integrity together. SHA256 is the hash used in the handshake's key derivation and integrity functions. So this suite means: agree a key with ephemeral ECDH, authenticate the server with its RSA certificate, then encrypt the session with AES-128-GCM and use SHA-256 for the handshake's hashing. That is a good suite.

TLS 1.3 simplified this radically. Because TLS 1.3 only permits AEAD ciphers and always uses an ephemeral, forward-secret key exchange, the suite no longer needs to name the key exchange or the authentication method — those are negotiated separately, and the weak options simply do not exist. A TLS 1.3 cipher suite names only the AEAD cipher and the hash:

   TLS_AES_128_GCM_SHA256         TLS_CHACHA20_POLY1305_SHA256
   └ AES-128-GCM + SHA-256        └ ChaCha20-Poly1305 + SHA-256 (great on mobile/no-AES-HW)

This is a security feature disguised as a simplification: in TLS 1.3 you cannot accidentally configure a non-forward-secret or non-authenticated-encryption suite, because the protocol removed them. Most of the work of "hardening cipher suites" is therefore really about TLS 1.2, where the bad options still exist and must be explicitly disabled.

Forward secrecy (also called perfect forward secrecy, PFS) is the property that compromising a server's long-term private key in the future does not let an attacker decrypt past sessions they recorded. It comes from the ephemeral key exchange: each session's symmetric key is derived from fresh, throwaway Diffie–Hellman keys (the "E" in ECDHE/DHE) that exist only for that handshake and are then discarded. The server's long-term certificate key is used only to authenticate (to sign), never to encrypt the session key. So even if an attacker records months of encrypted Meridian traffic today and steals the server's private key next year, that key unlocks nothing — the ephemeral keys that protected each session are long gone.

🚪 Threshold Concept: Forward secrecy directly defeats the most patient attack in cryptography: harvest-now, decrypt-later. A well-resourced adversary records your encrypted traffic today and stores it, betting on obtaining your key — or a future cryptographic breakthrough — later. Without forward secrecy, one stolen private key retroactively decrypts every recorded session ever protected by it: a single key compromise becomes a historical catastrophe. With forward secrecy, each session is an island; cracking one helps not at all with the next, and a stolen long-term key compromises future authentication but not past confidentiality. This is why every modern TLS configuration mandates ephemeral key exchange, and why TLS 1.3 made it the only option.

How cipher suites get attacked. The attacks are a roll-call of retired algorithms, and you should recognize the names as red flags in any scan: RC4 (a stream cipher with statistical biases, broken, must be disabled), 3DES (vulnerable to the Sweet32 birthday attack on its 64-bit block; retired), export-grade ciphers (deliberately weakened 1990s relics behind the FREAK and Logjam downgrade attacks), CBC-mode ciphers in older TLS (a long history of padding-oracle attacks like BEAST and Lucky 13 — prefer AEAD/GCM), static RSA key exchange (the non-ephemeral TLS_RSA_WITH_* suites, which have no forward secrecy — a future key theft decrypts all past traffic — and were the vector for the ROBOT attack), and any suite using MD5 or SHA-1 for integrity. An attacker who can force a connection onto any of these can often read or tamper with it.

How you detect and prevent it. Prevention is configuration: define an explicit allowlist of strong suites and disable everything else. A defensible 2020s baseline for Meridian is to support only TLS 1.2 and 1.3; on 1.2, allow only ECDHE key exchange (forward secrecy) with AES-GCM or ChaCha20-Poly1305 (AEAD) and SHA-256 or better; disable all RC4, 3DES, export, static-RSA, and CBC suites. Order the server's preference list so the strongest mutually supported suite wins. Detection: log the negotiated cipher per connection and alert on anything off the allowlist; scan regularly (§5.7) to catch a server that drifted back to offering a weak suite after a patch or a config rollback.

⚠️ Common Pitfall: "We support strong ciphers" is not the same as "we only support strong ciphers." A server can offer AES-256-GCM and RC4, and an attacker performing a downgrade will simply pick RC4. The presence of one good option does not neutralize a bad one; the bad one must be removed. Audit what your servers offer, not just what your browser happens to negotiate with them — your modern browser will pick the good suite and hide the bad one that an attacker's downgraded client would gladly select.

🔄 Check Your Understanding: 1. In the suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, which component provides forward secrecy, and which provides server authentication? 2. An old internal app server offers only TLS_RSA_WITH_AES_128_CBC_SHA. Name two distinct weaknesses of this suite a defender should flag.

Answers

1. ECDHE (ephemeral elliptic-curve Diffie–Hellman) provides forward secrecy; RSA (the certificate's signature) provides authentication. 2. It uses static RSA key exchange (the absence of "DHE"/"ECDHE"), so it has no forward secrecy — a future private-key theft decrypts past sessions; and it uses CBC mode rather than an AEAD mode, exposing it to the family of padding-oracle attacks and lacking built-in integrity. (Bonus: SHA-1 for the MAC is also weak.)

5.4 VPNs and IPsec/WireGuard

TLS protects a single application's connection. Sometimes you need to protect everything between two points — to make a remote analyst's laptop behave as if it were plugged into the corporate network, or to join a branch office to the data center over the public internet as if by a private wire. That is the job of a VPN — Virtual Private Network — a technology that creates an encrypted tunnel across an untrusted network (usually the internet), so that traffic flowing through it gets confidentiality, integrity, and authentication as a property of the tunnel rather than of each application.

There are two broad VPN use cases at Meridian. Site-to-site VPNs connect whole networks — a branch to the data center, the data center to a cloud VPC — so that hosts on each side reach each other privately and automatically. Remote-access VPNs connect an individual user's device to the corporate network, which is how Meridian's remote staff and on-call engineers reach internal systems. The two cases often use different technologies, and choosing among them is a core engineering decision. The leading options:

IPsec — Internet Protocol Security — is a suite of protocols that secures traffic at the network layer (Layer 3), encrypting and authenticating IP packets themselves. It is the long-standing standard for site-to-site VPNs and is supported by essentially every firewall and router. IPsec runs in two modes — tunnel mode (the whole original packet is encrypted and wrapped in a new one; used for site-to-site) and transport mode (only the payload is encrypted; used host-to-host) — and uses the IKE (Internet Key Exchange) protocol to negotiate keys, much as TLS's handshake does. IPsec is powerful, interoperable, and battle-tested; it is also notoriously complex to configure correctly, with many knobs (encryption algorithm, integrity algorithm, Diffie–Hellman group, lifetimes) that must match on both ends and that, set wrong, silently weaken the tunnel.

WireGuard is a modern VPN protocol designed for simplicity, speed, and a small, auditable codebase (a few thousand lines, versus IPsec's sprawling implementations). It uses a fixed, opinionated set of modern cryptography — Curve25519 for key exchange, ChaCha20-Poly1305 for encryption, BLAKE2s for hashing — with no algorithm negotiation, which eliminates an entire class of downgrade and misconfiguration risks: there are no weak options to accidentally enable because there are no options. Each peer is identified by a public key (very much in the spirit of SSH keys), and the configuration is short enough to read at a glance. WireGuard has become popular for remote-access and cloud-to-cloud VPNs where its speed and simplicity shine; its main historical trade-offs were around large-enterprise features (its lean design omits some of the policy and identity-integration machinery that mature commercial IPsec/SSL-VPN products provide), which is why it is often paired with management layers in enterprise deployments.

There is also the family of TLS-based (SSL) VPNs — remote-access VPNs that tunnel traffic over TLS, which has the operational advantage of traversing firewalls and proxies easily (it looks like HTTPS) and integrating with browsers and identity systems. Many enterprise remote-access VPNs are TLS-based for exactly this reach. The line between "VPN" and "zero-trust network access" is blurring here, which is a thread we pick up much later in the book.

🛡️ Defender's Lens: A VPN concentrates risk as much as it reduces it. A remote-access VPN concentrator is, by design, an internet-facing box that, once you authenticate through it, grants broad access to the internal network — which makes it one of the highest-value targets you own. Real intrusions have begun with an unpatched VPN appliance or a VPN credential without multi-factor authentication. So the VPN's own security is paramount: patch the appliance relentlessly (VPN gateways are a frequent subject of CISA advisories), require phishing-resistant MFA (Chapter 16) for VPN logins, log and monitor VPN authentications for impossible-travel and brute-force patterns, and — the modern lesson — do not treat "on the VPN" as equivalent to "trusted," because a compromised laptop on the VPN is an attacker on your network. Network access earned through a VPN should still be least-privilege, which is the bridge to zero trust later in the book.

What a VPN does and does not protect is the single most misunderstood point, and worth stating bluntly. A VPN protects data in transit between the two tunnel endpoints. It does not encrypt data at rest, it does not protect data after it leaves the far end of the tunnel (traffic from the VPN concentrator onward to its destination is protected only by whatever protects it normally — e.g., TLS), and a consumer "VPN service" does not make you anonymous or secure against a malicious website; it merely moves the point at which your traffic emerges onto the internet. For a defender, the useful framing is: a VPN extends a trust boundary across an untrusted network. It is a transport control, peer to TLS, not a substitute for endpoint security, application security, or encryption at rest.

Choosing. For Meridian, a defensible split: IPsec for the established site-to-site tunnels between branches and the data center (interoperability with existing firewalls, mature management); WireGuard or a TLS-based VPN for remote access and cloud connectivity (speed, simplicity, easier MFA and identity integration). The decision rule is not "which protocol is best" in the abstract but "which fits this use case, this existing equipment, and this operations team" — with the non-negotiables being modern algorithms (which WireGuard enforces and IPsec must be configured for), MFA on user-facing VPNs, and a patching discipline for the gateways.

🔄 Check Your Understanding: 1. A remote analyst connects to Meridian over a VPN and then browses to an internal web app over HTTP (not HTTPS). Inside the corporate network, is that traffic encrypted? Explain. 2. Give one concrete security advantage WireGuard's lack of algorithm negotiation provides over a typical IPsec configuration.

Answers

1. Between the analyst's laptop and the VPN concentrator, yes — the VPN tunnel encrypts it. But after the concentrator, as the traffic crosses the internal network to the web app, it is plain HTTP and unencrypted, because the VPN only protects the tunnel segment. Internal traffic still needs its own protection (TLS), illustrating that "on the VPN" is not "encrypted everywhere." 2. With no negotiation, there are no weak algorithms to accidentally enable and no downgrade attack that forces a weaker option; IPsec, by contrast, can be (and often is) misconfigured with a weak Diffie–Hellman group or cipher because the options exist and must be explicitly restricted.

5.5 Disk and database encryption

We now cross from data in transit to data at rest. The threat changes: no attacker on the wire, but an attacker who gets the storage — a stolen laptop, a lifted drive, a copied database file, an exposed backup. The control is encryption of the storage, and the decisive question is never the algorithm (it is AES) but key management: where does the key live, and is it separated from the data so that stealing the data does not also steal the key?

Full-disk encryption (FDE) encrypts an entire volume so that, when the device is powered off, the data on the disk is ciphertext and unreadable without the key. The two you will meet constantly are BitLocker (Windows) and LUKS (Linux Unified Key Setup, the standard on Linux); macOS's equivalent is FileVault. FDE's value is precise and limited: it protects against physical loss of a powered-off device. A laptop stolen from a car trunk, a server drive pulled from a decommissioned rack, a disk sold on without wiping — FDE makes all of these a non-event, turning a reportable breach of customer data into the loss of an encrypted brick. This is exactly why Meridian mandates FDE on every laptop and every server: a lost endpoint is an inevitability, and FDE is what makes it survivable.

Where does the FDE key live? This is the crux. BitLocker and LUKS typically protect the disk-encryption key with a key derived from a passphrase and/or sealed into a TPM (Trusted Platform Module) — a hardware chip that releases the key only if the boot process is unaltered (and, ideally, only after a PIN). The TPM means the user does not have to type a long key, while still keeping the key out of the attacker's hands when the disk is removed from the machine. Enterprises also escrow a recovery key (BitLocker stores one in Entra ID or Active Directory) so a forgotten passphrase does not mean lost data.

⚠️ Common Pitfall: Full-disk encryption protects a powered-off device and almost nothing else. Once the machine is booted and the user logged in, the disk is transparently decrypted for every process — so FDE does not protect against malware running on the live system, a logged-in attacker, or an "evil maid" who tampers with a running-but-locked machine. New defenders sometimes treat "the laptop is encrypted" as a general-purpose security claim; it is specifically a device-loss control. Against a live, compromised host you need endpoint detection and response, access control, and application-layer protections — not FDE, which has already handed the plaintext to the operating system.

Database encryption comes in layers, and choosing among them is a real design decision driven by which threat you are defending against:

• Transparent Data Encryption (TDE) encrypts the database's files on disk, transparently to the application. Like FDE, it defends against theft of the files (a copied database file, a stolen backup, a lifted disk) but does nothing against an attacker who has valid access to the running database, because the database decrypts transparently for any authorized query. TDE satisfies "encrypt cardholder data at rest" for an auditor and protects against media theft — and that is its scope.
• Column-level or field-level encryption encrypts specific sensitive columns (e.g., the full card number, the Social Security number) with keys the database engine may not even hold, so that even a database administrator or an attacker with full query access sees only ciphertext in those fields. This defends against a much stronger threat — a compromised or malicious insider with database access — at the cost of complexity, performance, and the loss of the ability to query or index those columns normally.
• Application-layer encryption encrypts data in the application before it ever reaches the database, so the database stores only ciphertext and the keys live entirely outside it. This is the strongest separation and the most operationally demanding.

The pattern across all of these is the same lesson FDE taught: encryption at rest is only as strong as the separation of the key from the data. A database encrypted with TDE where the master key sits in a file on the same server, readable by the same account that can read the database, defends only against someone who steals the disk but not the file — a narrow win. The same TDE with its master key held in a key-management service or HSM (§5.6), released only to authorized processes, defends much more.

🔗 Connection: Meridian's obligation here is concrete and regulatory. PCI-DSS requires that stored cardholder data be rendered unreadable — through strong encryption with proper key management, truncation, or tokenization — and GLBA's Safeguards Rule requires protecting customer information at rest. These are not aspirations; they are audited controls, and "we use TDE" is only an acceptable answer if you can also show where the keys live and who can reach them. We return to the full PCI/GLBA mapping later in the book; for now, note that "encrypt the data at rest" is a control Meridian must not merely deploy but evidence.

Tokenization deserves its own definition because it is the bank's preferred move for card data and is often confused with encryption. Tokenization replaces a sensitive value (a primary account number) with a non-sensitive surrogate — a token — that has no mathematical relationship to the original and is useless if stolen; the real value is stored in a separate, heavily guarded token vault, and only that vault can map a token back to the real number. The power of tokenization is scope reduction: once Meridian's e-commerce and analytics systems handle only tokens, those systems fall largely out of PCI-DSS scope, because they no longer touch real cardholder data at all. Encryption protects the data while keeping it present and reversible everywhere the key reaches; tokenization removes the sensitive data from most of the environment and confines it to one vault. For card data, tokenization is frequently the better risk-reduction lever, and Meridian uses it precisely so that the blast radius of a breach in its sprawling application estate excludes real card numbers.

🔄 Check Your Understanding: 1. An attacker steals a powered-off, BitLocker-encrypted laptop and separately compromises the same user's live, logged-in desktop. Against which threat does full-disk encryption protect, and against which is it useless? 2. Meridian uses Transparent Data Encryption on its customer database, but a SQL-injection flaw lets an attacker run arbitrary queries as the application. Does TDE protect the data in this case? Why or why not? What kind of encryption would?

Answers

1. FDE protects the stolen powered-off laptop — its disk is ciphertext without the key. It is useless against the live logged-in desktop, where the OS has already decrypted the disk for every running process, including the attacker's. 2. No — TDE decrypts transparently for any authorized query, and the injection runs as the authorized application, so it reads plaintext just as the application would. Column-level or application-layer encryption (with keys outside the database) would protect the sensitive fields, because even an authorized query would return only ciphertext for them.

5.6 Certificate and key lifecycle, and HSMs

Everything in this chapter — TLS, mTLS, signed VPN configs, encrypted databases — depends on keys and certificates, and the single most common way these systems fail in practice is not a broken algorithm but a mismanaged lifecycle: a certificate nobody renewed, a private key nobody protected, a revocation nobody published. Managing that lifecycle is the unglamorous, outage-preventing discipline at the heart of applied cryptography.

The certificate lifecycle is the full set of stages an X.509 certificate moves through, and a mature program owns every one:

   1. KEY GENERATION   -> create a key pair (protect the private key from birth)
   2. CSR              -> create a Certificate Signing Request (public key + identity)
   3. VALIDATION       -> the CA verifies you control the name (domain validation, etc.)
   4. ISSUANCE         -> the CA signs and returns the certificate
   5. DEPLOYMENT       -> install cert + private key on the server / load balancer
   6. MONITORING       -> track expiry; watch for mis-issuance (CT logs)
   7. RENEWAL          -> reissue BEFORE expiry (automate this!)
   8. REVOCATION       -> if the key is compromised or the cert is wrong: revoke (CRL/OCSP)
   9. RETIREMENT       -> decommission cleanly; destroy the private key

Figure 5.2 — The certificate lifecycle. Steps 6 and 7 (monitoring and renewal) are where most real-world failures happen — an unrenewed certificate causes a self-inflicted outage — and step 8 (revocation) is where the system is weakest.

A few stages deserve emphasis because they are where defenders get hurt:

Renewal and the expiry outage. A certificate has a fixed validity period (industry maximums for public TLS certificates have been falling, now around a year and trending shorter). When it expires, clients reject it — and a forgotten renewal on a critical service is a self-inflicted outage that has taken down major companies' websites, payment systems, and even other security products. The defense is automation and inventory: maintain a complete inventory of every certificate and its expiry, alert well in advance, and automate renewal wherever possible (the ACME protocol, popularized by Let's Encrypt, automates issuance and renewal for public certificates). Meridian's program treats "days until certificate expiry" as a monitored metric with escalating alerts — the same instinct as a patch SLA. (This is the cert_days_left helper that the secrets.py module will formalize later in the book; the idea starts here.)

Revocation and its weakness. If a private key is compromised or a certificate was mis-issued, you need to revoke it — declare it invalid before its natural expiry. The mechanisms are CRLs (Certificate Revocation Lists) — signed lists of revoked certificate serial numbers — and OCSP (Online Certificate Status Protocol) — a service a client queries to ask "is this specific certificate still valid?" Both have real weaknesses: CRLs can grow huge and stale, and clients historically often failed open (treating an unreachable OCSP responder as "valid"), which means an attacker who blocks the revocation check can use a revoked certificate. OCSP stapling improves this by having the server attach a fresh, signed validity proof to its handshake. The honest defender's takeaway: revocation is the least reliable part of the PKI, which is a major reason the industry has pushed certificate lifetimes shorter — a short-lived certificate limits the damage window without depending on revocation working.

Mis-issuance and Certificate Transparency. A grave failure mode is a CA issuing a certificate for meridianbank.example to someone who is not Meridian — through a compromise, a fraud, or an error. This is what makes the whole "trusted CA" model fragile: your security depends on every CA your clients trust never making this mistake. Certificate Transparency (CT) is the industry's defense: CAs must publish every certificate they issue to public, append-only logs, so that Meridian can monitor those logs and detect a certificate issued for its domains that it never requested. CT turns a silent mis-issuance into something the rightful owner can catch. Meridian monitors CT logs for its names as a standing control.

Certificate pinning is an application-side defense against both mis-issuance and MITM. Certificate pinning is the practice of an application hard-coding (or otherwise constraining) which certificate or which public key it will accept for a given server, so that even a validly signed certificate from a trusted CA is rejected if it is not the expected one. Meridian's mobile banking app pins to the bank's own keys: an attacker who somehow obtains a mis-issued-but-trusted certificate for meridianbank.example, or who installs a malicious root CA on a customer's phone to MITM the app, still fails, because the pinned app refuses any certificate but the bank's own. Pinning is powerful but operationally sharp — pin the wrong thing, or rotate a key without updating the pins, and you brick your own app — so it is used deliberately, on high-value apps, with a careful key-rotation plan.

Mutual TLS (mTLS). Ordinary TLS authenticates the server to the client. Mutual TLS (mTLS) authenticates both directions: the client also presents a certificate, and the server verifies it, so each party cryptographically proves its identity to the other. mTLS is the workhorse of machine-to-machine authentication — service-to-service calls inside a microservices estate, an API client proving it is an authorized partner, a device authenticating to a backend — where there is no human to type a password and a shared secret would be a liability. Meridian uses mTLS between its internal services and for certain high-value API partners, so that "which service is calling" is established by a certificate rather than a guessable token. mTLS raises the bar for an attacker considerably — stealing a credential now means stealing a client certificate and its private key — but it also multiplies the certificate lifecycle problem by every client, which is exactly why automated certificate management matters at scale. (mTLS recurs as an applied pattern later in the book; here we introduce the concept.)

Key management and HSMs. Underneath all of this is key management — the full discipline of generating, distributing, storing, rotating, and destroying cryptographic keys throughout their lifecycle. It is the part of cryptography that most often fails, because the math is solved but the operations are hard: a perfect cipher with a key in a world-readable file protects nothing. The principles are consistent — generate keys with strong entropy (Chapter 4), store them separated from the data they protect, restrict who and what can use them, rotate them on a schedule and immediately on suspected compromise, and destroy them cleanly at end of life. At scale this is delegated to a key-management service (cloud KMS) or, for the highest-value keys, an HSM.

An HSM — Hardware Security Module — is a dedicated, tamper-resistant hardware device that generates, stores, and uses cryptographic keys such that the private key never leaves the device in plaintext. You ask the HSM to sign or decrypt; it performs the operation internally and returns the result, but it will not export the key, and it is built to destroy its keys if physically tampered with. For Meridian, HSMs guard the crown-jewel keys — the private key of an internal CA, the master keys for database and tokenization systems, the keys behind payment processing — precisely because for those keys, "the key was copied" must be made effectively impossible, not merely unlikely. (PCI-DSS in fact mandates HSM-grade protection for certain payment keys.) The HSM is where "separate the key from everything, including the people" reaches its hardware conclusion. We introduce the HSM here and apply it further when we reach machine identity and secrets management later in the book.

⚠️ Common Pitfall: The most expensive cryptographic failures are operational, not mathematical. The top three in practice: (1) a certificate expires unnoticed and takes down a critical service — a self-inflicted outage that is entirely preventable with inventory and automation; (2) a private key is stored carelessly — in a code repository, on a shared drive, in a backup — so that "the encryption" is undone by anyone who finds the key; (3) revocation is relied upon as a safety net when it frequently fails open. None of these is a weakness in AES or RSA. All of them are lifecycle and key-management failures, which is why this section, not the algorithm sections, is where a working engineer spends their time.

🔄 Check Your Understanding: 1. Why has the industry trend toward shorter certificate lifetimes been partly motivated by the weaknesses of revocation? 2. Meridian's mobile app pins to the bank's public key. An attacker installs a malicious root CA on a customer's phone and presents a certificate for meridianbank.example that the phone's OS now trusts. Does the attack succeed against the pinned app? Against the phone's browser?

Answers

1. Revocation (CRL/OCSP) is unreliable — it can be stale, slow, or fail open when an attacker blocks the check — so a compromised certificate may remain usable despite being revoked. A short lifetime caps the damage window automatically: the certificate expires on its own soon, limiting exposure without depending on revocation reaching every client. 2. The attack fails against the pinned app: pinning rejects any certificate that is not the bank's expected key, regardless of who signed it, so a trusted-but-wrong certificate is still refused. It would succeed against the browser, which trusts the OS root store and would accept the attacker's now-"trusted" certificate — illustrating exactly why high-value apps pin and why a malicious root CA on a device is so dangerous for everything that does not.

5.7 Finding weak TLS in the wild: defensive scanning

You cannot fix what you cannot see, and Meridian's forgotten marketing microsite from this chapter's opening proves the point: the weakness existed for three years because nobody was looking. Defensive TLS scanning is how a security team continuously inventories its own cryptographic posture and catches drift before an attacker does. This is a read-only, hardening-oriented activity — you are auditing your own configuration, not attacking anyone — and it is squarely a defender's tool.

What a TLS scan checks, against each endpoint you own:

• Protocol versions offered — flag any SSLv2/SSLv3/TLS 1.0/TLS 1.1; expect only TLS 1.2 and 1.3.
• Cipher suites offered — flag RC4, 3DES, export, static-RSA (no forward secrecy), CBC, MD5/SHA-1, anything off your allowlist (§5.3).
• Forward secrecy — confirm every supported suite uses ephemeral key exchange (ECDHE/DHE).
• Certificate validity — is it expired or near expiry? Is the name correct? Is the chain complete and trusted? Is the signature algorithm strong (not SHA-1)? Is the key long enough (e.g., RSA ≥ 2048 bits)?
• Configuration hygiene — is HSTS set? Is secure renegotiation enabled? Is the server vulnerable to any known protocol flaw the scanner tests for?

The tools are standard and free: testssl.sh (a thorough open-source command-line scanner), sslscan and nmap with its ssl-enum-ciphers script (quick cipher enumeration), and Qualys SSL Labs' online test for public endpoints. A read-only enumeration of your own server's supported protocols and ciphers looks like this:

# Defensive: enumerate the TLS protocols and ciphers our OWN server offers.
# Read-only; authorized assets only. Annotate every finding for the queue.
nmap --script ssl-enum-ciphers -p 443 banking.meridianbank.example

# testssl.sh gives a graded, detailed report (versions, ciphers, cert, vulns):
testssl.sh --quiet --color 0 https://banking.meridianbank.example

A scanner's output is a list of facts; grading it — turning "offers TLS 1.0 and a 3DES suite, certificate expires in 9 days" into an A/B/C/F and a prioritized action — is the defender's value-add, and it is exactly what this chapter's bluekit increment automates. The grading logic mirrors the checks above: any obsolete protocol or weak cipher is a serious downgrade in grade; a missing-forward-secrecy or expiring certificate is a finding; a clean TLS-1.3-only, AEAD-only, forward-secret, valid-certificate endpoint earns an A.

How this connects to attack. Everything the scanner flags is something an attacker's reconnaissance flags too — the same weak protocol an attacker would downgrade you to, the same expired certificate that signals an unmanaged service, the same missing forward secrecy that makes recorded traffic worth harvesting. The difference is that you are looking first, on a schedule, with the intent to fix. A defensive scanning program closes the window in which the gap between "configured years ago" and "still safe today" can be exploited.

🛡️ Defender's Lens: Make TLS scanning continuous, not annual. Configurations drift: a server is rebuilt from an old image, a load balancer's cipher policy is rolled back during an incident, a new service launches with defaults nobody reviewed, a certificate quietly approaches expiry. A once-a-year scan finds the problem up to a year late. Wire TLS posture into the same continuous-monitoring pipeline as vulnerability scanning, alert on any regression (a previously-A endpoint that drops to a B), and feed expiring certificates into the same queue as critical patches. The goal is that the gap between "drifted into weakness" and "detected" is measured in days, not audit cycles.

🔄 Check Your Understanding: 1. Why is TLS scanning of your own estate a defensive activity, and what makes it different from an attacker scanning the same servers? 2. A scan reports an endpoint offering TLS 1.2 and 1.3, only ECDHE-AEAD cipher suites, but with a certificate that expires in five days. Is the cryptographic configuration weak? What is the finding, and how urgent?

Answers

1. It is defensive because it is read-only auditing of assets you own, performed to find and fix weaknesses before they are exploited; it is identical in technique to attacker reconnaissance but opposite in intent and authorization — you scan to remediate, on a schedule, with permission. 2. The cryptographic configuration is strong (modern protocols, forward-secret AEAD suites). The finding is the certificate lifecycle: a five-day-to-expiry certificate is an imminent self-inflicted-outage risk and should be treated urgently — renew immediately. It is a reminder that "good crypto config" and "good certificate management" are separate checks, and the second one fails far more often.

Project Checkpoint

Meridian's program now has crypto fundamentals from Chapter 4 (an encryption standard naming approved algorithms and key sizes). This chapter turns that into an operational data-protection standard and adds the tool that lets the team enforce it.

Program increment — the data-protection standard (in-transit and at-rest). Sam Whitfield drafts the standard the auditors will eventually ask for, organized exactly by the two states from §5.1. In transit: TLS 1.2 and 1.3 only, everywhere; forward-secret AEAD cipher suites only; HSTS on all web properties; mTLS for internal service-to-service and high-value partner APIs; IPsec for site-to-site and WireGuard/TLS-VPN for remote access, all with MFA on user-facing gateways. At rest: full-disk encryption (BitLocker/LUKS, TPM-backed) on every laptop and server; Transparent Data Encryption on all databases, with master keys in the cloud KMS or HSM — never on the database host; column/application-layer encryption for the most sensitive fields; tokenization for card data to shrink PCI-DSS scope; crown-jewel keys (internal CA, payment, tokenization masters) in HSMs. Lifecycle: a complete certificate inventory with automated renewal and expiry alerting, CT-log monitoring for Meridian's domains, and a documented revocation procedure. This standard slots into the security program between the network architecture and the identity work, and it is the document that makes "we encrypt customer data" auditable rather than aspirational.

bluekit increment — extend cryptutil.py with tls_config_grade(params). We turn §5.3 and §5.7's judgment into code: given a parsed TLS configuration, return a letter grade and the reasons, so a scan of hundreds of Meridian endpoints produces a ranked remediation queue instead of a wall of text. As always, the code is illustrative and never executed during authoring — the expected output is hand-traced in a comment.

# bluekit/cryptutil.py  — Chapter 5 increment (extends the Chapter 4 module)
def tls_config_grade(params: dict) -> tuple[str, list[str]]:
    """Grade a TLS endpoint config. params keys:
       min_protocol (e.g. 'TLS1.0'..'TLS1.3'), forward_secrecy (bool),
       weak_ciphers (list[str]), cert_days_left (int).
    Returns (grade, findings)."""
    findings = []
    rank = {"SSLv3": 0, "TLS1.0": 1, "TLS1.1": 2, "TLS1.2": 3, "TLS1.3": 4}
    if rank.get(params["min_protocol"], 0) < rank["TLS1.2"]:
        findings.append(f"obsolete protocol allowed: {params['min_protocol']}")
    if not params["forward_secrecy"]:
        findings.append("no forward secrecy (non-ephemeral key exchange)")
    if params["weak_ciphers"]:
        findings.append("weak ciphers offered: " + ", ".join(params["weak_ciphers"]))
    if params["cert_days_left"] < 0:
        findings.append("certificate EXPIRED")
    elif params["cert_days_left"] < 14:
        findings.append(f"certificate expires in {params['cert_days_left']} days")
    # grade: F for obsolete proto or expired cert; else penalize each finding
    if any("obsolete protocol" in f or "EXPIRED" in f for f in findings):
        return "F", findings
    grade = "ABCDF"[min(len(findings), 4)]
    return grade, findings


if __name__ == "__main__":
    endpoints = {
        "banking (good)":   dict(min_protocol="TLS1.2", forward_secrecy=True,
                                 weak_ciphers=[], cert_days_left=200),
        "legacy microsite": dict(min_protocol="TLS1.0", forward_secrecy=False,
                                 weak_ciphers=["RC4", "3DES"], cert_days_left=-42),
        "api (expiring)":   dict(min_protocol="TLS1.3", forward_secrecy=True,
                                 weak_ciphers=[], cert_days_left=9),
    }
    for name, cfg in endpoints.items():
        grade, why = tls_config_grade(cfg)
        print(f"{grade}  {name}: {'; '.join(why) or 'clean'}")

# Expected output:
# A  banking (good): clean
# F  legacy microsite: obsolete protocol allowed: TLS1.0; no forward secrecy (non-ephemeral key exchange); weak ciphers offered: RC4, 3DES; certificate EXPIRED
# B  api (expiring): certificate expires in 9 days

The function does what a senior engineer does at a glance: an obsolete protocol or an expired certificate is an automatic F (the legacy microsite from our opening earns exactly that — and would have, three years earlier, had anyone scanned it); a single non-fatal issue like an expiring certificate drops a clean A to a B and lands on the queue; a modern, forward-secret, valid endpoint is an A. Run this across a TLS-scan export and Meridian gets a sorted worklist — the same move as riskcalc.py's bands, applied to cryptographic posture.

Summary

This chapter applied Chapter 4's primitives to the systems that carry a bank's data, organized around the two states of data.

• Data in transit vs. at rest is the organizing distinction. In transit, the threat is an attacker on the path; the control is a secure transport (TLS, IPsec, WireGuard). At rest, the threat is access to the storage; the control is encryption of the storage, where key management — separating the key from the data — is the decisive factor. A single datum passes through both states and needs protection in each.
• TLS 1.3 (RFC 8446) secures data in transit in one round trip: paired ephemeral Diffie–Hellman key shares establish a shared secret; the server's certificate and CertificateVerify authenticate it; Finished messages prove the handshake was untampered. It is attacked at the edges — downgrade, MITM via forged/mis-issued certificates, expired certs — and defended by disabling old protocols, strong cipher policy, HSTS, pinning, and monitoring.
• A cipher suite bundles key exchange, authentication, bulk cipher, and hash; TLS 1.3 removed the weak options so suites name only the AEAD cipher and hash. Forward secrecy (from ephemeral key exchange) ensures a future key theft cannot decrypt past sessions — the defense against harvest-now-decrypt-later. Disable RC4, 3DES, export, static-RSA, CBC, and MD5/SHA-1; offer only strong suites, not merely strong-among-weak.
• VPNs protect everything between two tunnel endpoints. IPsec (Layer 3, interoperable, complex) suits site-to-site; WireGuard (modern, simple, no negotiation) and TLS-based VPNs suit remote access. A VPN protects data in transit between endpoints only — not at rest, not past the far end — and its own gateway is a top-tier target requiring patching, MFA, and least privilege.
• Encryption at rest: full-disk encryption (BitLocker/LUKS, TPM-backed) protects powered-off devices and nothing more. Database encryption layers — TDE (file theft), column/field (insider with query access), application-layer (strongest separation) — defend different threats. Tokenization removes sensitive data (card numbers) from most of the environment into a guarded vault, reducing PCI-DSS scope.
• The certificate lifecycle (generation → CSR → validation → issuance → deployment → monitoring → renewal → revocation → retirement) is where real failures live: unrenewed certificates cause self-inflicted outages; revocation (CRL/OCSP) is unreliable and pushes lifetimes shorter; mis-issuance is caught by Certificate Transparency monitoring; certificate pinning and mTLS raise the bar against MITM and authenticate machines. HSMs guard crown-jewel keys so the private key never leaves the device in plaintext.
• Defensive TLS scanning (testssl.sh, sslscan, nmap ssl-enum-ciphers) continuously inventories your own cryptographic posture — protocols, ciphers, forward secrecy, certificate validity, hygiene — and feeds drift into remediation before an attacker finds it. tls_config_grade turns a scan into a ranked worklist.

Spaced Review

Retrieval practice over recent and older material. Answer before scrolling up.

1. (Ch.4) Chapter 4 distinguished symmetric from asymmetric encryption and described the key-distribution problem. In the TLS 1.3 handshake, which kind of cryptography establishes the shared session key, and which kind authenticates the server — and how does this solve the key-distribution problem over an untrusted network?
2. (Ch.4) A digital signature, from Chapter 4, proves authenticity and integrity. Where in the TLS handshake does a digital signature appear, and what specifically does it prove?
3. (Ch.1) Using the risk vocabulary from Chapter 1, classify the following for Meridian's forgotten microsite: the expired certificate and weak ciphers; an attacker on the path able to downgrade the connection; the customer data that would be exposed. Which is the vulnerability, which the threat, which the asset?
4. (Ch.5) State, in one sentence each, what full-disk encryption does and does not protect against.
5. (Ch.1) Theme 5 says compliance is the floor, not the ceiling. Give one example from this chapter where doing exactly what a compliance checkbox requires ("data is encrypted at rest") could still leave Meridian insecure.

What's Next

You can now protect data in transit and at rest and manage the keys and certificates that make it real — but cryptography secures the channel, not the network it runs on. Part II turns to the network itself: how TCP/IP actually works, where attacks live at each layer, and how to see and segment traffic. Chapter 6 builds the foundation — ports, protocols, the three-way handshake, segmentation, and the network attacks (spoofing, MITM, DoS) and defenses that every later chapter assumes. The TLS you just studied rides on top of that network, and the DNS, email, and web hardening of Chapter 9 — where SPF, DKIM, DMARC, and HSTS live — will lean directly on this chapter's transport security. Identity and machine credentials in Chapter 20 will pick up mTLS, certificate lifecycle, and HSMs as applied practice. First, though, you need to understand the wire your encrypted traffic travels on.