Security Fundamentals: Cryptography and the CIA Triad

Why network security matters

Every security protocol in this course exists to defend some combination of three properties, known as the CIA triad: Confidentiality (only authorized parties can read the data), Integrity (the data wasn't altered in transit, whether by accident or by an attacker), and Availability (the service stays reachable to the people who legitimately need it). A plaintext protocol like Telnet or unencrypted HTTP provides none of these guarantees for the data it carries: anyone who can observe the wire can read it, silently modify it in flight, or replay a captured copy of it later. TLS, IPsec, SSH, and PKI — the next four lessons — are four different, RFC-standardized answers to how confidentiality and integrity are actually achieved on real networks.

Common threats and attacks

• Eavesdropping (sniffing): a passive attacker captures traffic off the wire or over the air without altering it, violating confidentiality.
• Man-in-the-middle (MITM): an active attacker secretly relays and can alter traffic between two parties who believe they're talking directly to each other.
• Spoofing: an attacker forges the source of traffic — a spoofed source IP, a spoofed ARP reply, or a spoofed DNS response — to impersonate a trusted host.
• Replay attacks: an attacker captures a legitimate message (such as an authentication exchange) and resends it later to repeat its effect without needing to break any encryption.
• Denial of service (DoS): an attacker floods a target with traffic or requests to exhaust its resources, attacking availability rather than confidentiality or integrity.

Symmetric and asymmetric cryptography

Symmetric cryptography uses a single shared key for both encryption and decryption (AES is the modern standard). It's fast enough to encrypt bulk data at line rate, but it has a distribution problem: both parties need the same secret key before they can communicate, and sending that key over the same untrusted network it's meant to protect defeats the purpose. Asymmetric cryptography (RSA and elliptic-curve algorithms) solves exactly this problem with a mathematically linked key pair: data encrypted with a public key can only be decrypted with its matching private key, and data signed with a private key can be verified by anyone holding the public key. The catch is that asymmetric operations are orders of magnitude slower than symmetric ones. Because of this, TLS, IPsec, and SSH all use a hybrid approach: asymmetric cryptography (or a Diffie-Hellman exchange, below) establishes a short-lived symmetric session key, and all the actual bulk data is then encrypted with fast symmetric cryptography using that key.

Hashing and integrity

A cryptographic hash function (SHA-256 is the modern standard) takes an input of any size and produces a fixed-length digest, with two properties that matter here: the same input always produces the same digest, and even a one-bit change to the input produces a completely different digest. A hash alone proves nothing about who sent a message, only that it matches a known digest. HMAC (Hash-based Message Authentication Code) fixes this by combining the hash function with a shared secret key, producing a digest that only someone holding that key could have generated — proving both integrity (the message wasn't altered) and authenticity (it came from a party who knows the key). This is exactly the mechanism IPsec's AH and ESP headers and TLS's record-layer MAC use to detect tampering.

Interactive Diffie-Hellman key exchange

Step through the classic Diffie-Hellman example: two parties agree on public parameters in the clear, each generates a private value they never transmit, and both independently derive the identical shared secret — one an eavesdropper who captured every public value still cannot feasibly compute, because doing so means solving the discrete logarithm problem.

Where these protocols fit

With these building blocks in place, the next four lessons each apply them at a different layer and for a different purpose:

• TLS (RFC 8446) encrypts and authenticates application data over TCP — the protocol behind HTTPS and most other secure application traffic.
• IPsec (RFC 4301) encrypts and authenticates at the network layer, most commonly for site-to-site and remote-access VPNs.
• SSH (RFC 4251) secures interactive remote administration and file transfer sessions.
• PKI (RFC 5280) is the trust infrastructure — certificates and certificate authorities — that lets TLS, IPsec, and SSH actually verify whose public key they're using in the first place, rather than just that a key exchange succeeded with someone.

Inspect security evidence

openssl s_client -connect host:443 opens a raw TLS connection and prints the negotiated protocol version, cipher suite, and the full certificate chain the server presented — the fastest way to see a real handshake's outcome without a packet capture. Reading the chain from the leaf certificate up to the root shows exactly which certificate authorities a client is being asked to trust.

Guided cryptography practice

Work through why hybrid encryption is universal, not just common. Alice wants to send Bob a 50 MB file confidentially. Encrypting the whole file directly with an asymmetric algorithm like RSA would be thousands of times slower than symmetric encryption and is not what any real protocol does. Instead: Alice generates a random symmetric session key, encrypts the 50 MB file with that key using AES (fast, regardless of size), and encrypts only the small session key itself with Bob's public RSA key (or, as in TLS 1.3, both sides derive the session key together via a Diffie-Hellman exchange, so no key ever needs to be encrypted and sent at all). Bob decrypts the session key with his private key, then uses it to decrypt the file.

Troubleshoot security basics

1. Check for clock skew first: certificate validity windows and several handshake protocols depend on roughly synchronized time (NTP), and a large clock skew produces confusing "not yet valid" or "expired" certificate errors on a certificate that is actually fine.
2. Confirm the client and server share at least one common cipher suite or key-exchange algorithm — a "handshake failure" with no application-layer error usually means negotiation failed, not that credentials were wrong.
3. Walk the certificate chain from leaf to root and confirm every intermediate certificate is present — a missing intermediate is one of the most common causes of "untrusted certificate" errors on an otherwise correctly issued certificate.
4. Check whether a deprecated or weak algorithm (RC4, DES, SSLv3) is still enabled for legacy compatibility, since its presence can itself be the finding during a security review even if nothing is actively "broken."
5. Distinguish "connection refused" (a network- or firewall-layer problem, before any cryptography is involved) from "handshake failure" (the connection reached the service, but cryptographic negotiation itself failed) — they point to completely different layers.
6. Consider whether a middlebox (a TLS-inspecting proxy or firewall) is intercepting the connection, which replaces the real server's certificate with one of its own and breaks certificate validation unless the proxy's certificate was explicitly trusted.

Knowledge check and summary

Pro deep dive