2.1.6. Encryption and PKI
💡 First Principle: Encryption protects data confidentiality in transit and at rest — but from an analyst's perspective, encrypted traffic is also a hiding place for attackers, which is why SSL inspection exists and why PKI trust chains matter for detecting impersonation.
PKI (Public Key Infrastructure) is the system of certificates, certificate authorities (CAs), and trust chains that enables encrypted communication and identity verification at scale. Every HTTPS connection relies on PKI: the server presents a certificate signed by a trusted CA, your browser verifies the chain of trust, and the certificate proves the server is who it claims to be.
Cryptography building blocks:
| Concept | How it works | Typical use |
|---|---|---|
| Symmetric encryption | One shared key encrypts and decrypts (AES) | Bulk data, disks, TLS session traffic |
| Asymmetric encryption | A linked public/private key pair (RSA, ECC) | Key exchange, certificates |
| Hashing | One-way, fixed-length digest: SHA-256 is 256 bits (MD5 is 128 bits and SHA-1 is 160 bits, both broken for collision resistance) | Integrity checks, file identification |
| Digital signature | A hash signed with the sender's private key | Proves origin and integrity |
Encryption by data state: at rest (disks, or databases via Transparent Data Encryption (TDE), which encrypts the database files on disk and protects against theft of storage media), in transit (TLS), and in use (data in memory, normally unencrypted).
From a security operations standpoint, PKI matters because:
- Compromised or misissued certificates enable man-in-the-middle attacks that look legitimate
- Internal PKI (enterprise CA) enables internal HTTPS inspection without browser warnings
- Certificate transparency logs allow detection of certificates issued for domains an organization owns
- Certificate pinning prevents MITM even if a rogue CA issues a certificate for your domain
SSL/TLS Inspection (also called SSL interception or HTTPS inspection) decrypts encrypted traffic at a proxy or firewall, inspects the content for threats, then re-encrypts and forwards it. This is essential for detecting malware C2 over HTTPS, data exfiltration in encrypted channels, and malicious payloads in encrypted downloads.
The mechanism: the inspection device acts as a man-in-the-middle. It presents its own certificate (signed by the enterprise's internal CA, trusted by managed endpoints) to the client, while establishing a separate TLS session with the destination server. The client sees a valid cert; the inspector sees plaintext.
Limitations:
- Certificate pinned applications (some banking apps, certain enterprise software) break under inspection
- Privacy concerns for personal devices on corporate networks
- Adds latency and processing overhead
- Encrypted traffic to cloud services may require special handling
- A packet capture of HTTPS shows only handshake metadata (SNI and cipher suite, plus the server certificate in TLS 1.2 and earlier, since TLS 1.3 encrypts it); the payload stays encrypted. To read it, decrypt at an SSL-inspection proxy in the path, or load the endpoint's TLS session keys (the
SSLKEYLOGFILElog) into Wireshark
⚠️ Exam Trap: SSL inspection and SSL termination are NOT the same. SSL termination ends the encrypted connection (e.g., at a load balancer) and passes plaintext to backend servers — it's a performance and architecture pattern. SSL inspection decrypts, inspects for security threats, and re-encrypts — it's a security control.
Reflection Question: An organization deploys SSL inspection on its web proxy. A user's banking app stops working. What is most likely happening, and what is the technical reason certificate pinning causes this behavior?
