Chapter 1.3 Cryptography in Network Security

Module 1: Foundations & Threat Landscape Level: Intermediate to Advanced | Estimated reading time: 55-70 min

Cryptographic Primitives The Building Blocks
Symmetric Encryption
Asymmetric Encryption & Key Exchange
Hashing & Message Authentication
TLS How the Internet Actually Encrypts Traffic
PKI Public Key Infrastructure
Cryptographic Attacks & Common Misconfigurations
Practical Cryptography on the Command Line
Architecture Diagram

1. Cryptographic Primitives

Cryptography in network security rests on a small set of mathematical primitives. Every protocol TLS, SSH, IPSec, PGP is built from combinations of these primitives. Understanding what each one guarantees (and what it does not) is essential for evaluating security designs and identifying weaknesses.

The Core Security Properties

Property	Definition	Cryptographic Tool
Confidentiality	Data is readable only by intended parties	Symmetric/Asymmetric Encryption
Integrity	Data has not been modified in transit	Hash functions, MAC, AEAD
Authentication	Communicating party is who they claim to be	Digital signatures, certificates, HMAC
Non-repudiation	Sender cannot deny sending the message	Digital signatures (asymmetric)
Forward Secrecy	Past sessions remain secure if long-term key is compromised	Ephemeral key exchange (ECDHE, DHE)

Kerckhoffs's Principle

"A cryptosystem should be secure even if everything about the system, except the key, is public knowledge."

This is foundational. Security through obscurity hiding the algorithm is not cryptographic security. All production cryptographic algorithms (AES, RSA, ChaCha20) are fully public. Their security comes entirely from key secrecy.

Implication for defenders: If you are evaluating a product that claims its encryption algorithm is "proprietary" for security reasons, treat it as a red flag. Proprietary crypto cannot be audited and almost always contains weaknesses.

2. Symmetric Encryption

Symmetric encryption uses the same key for both encryption and decryption. It is fast (hardware-accelerated on modern CPUs) and suitable for bulk data encryption.

2.1 AES Advanced Encryption Standard

AES is the dominant symmetric cipher in use today. It operates as a block cipher (processes fixed-size 128-bit blocks) with key sizes of 128, 192, or 256 bits.

AES Modes of Operation the mode determines how multiple blocks are chained and whether the cipher provides authentication:

Mode	Full Name	Auth?	IV Required?	Notes
ECB	Electronic Codebook	No	No	Never use identical plaintext → identical ciphertext, leaks patterns
CBC	Cipher Block Chaining	No	Yes	Widely used, vulnerable to padding oracle if not authenticated
CTR	Counter Mode	No	Yes (nonce)	Converts block cipher to stream cipher, parallelizable
GCM	Galois/Counter Mode	Yes (AEAD)	Yes (nonce)	Standard for TLS 1.3, SSH provides confidentiality + integrity in one
CCM	Counter with CBC-MAC	Yes (AEAD)	Yes (nonce)	Used in 802.11i (WPA2), IoT
ChaCha20-Poly1305		Yes (AEAD)	Yes (nonce)	Alternative to AES-GCM, no hardware acceleration needed, used in TLS 1.3

Why ECB is broken the ECB Penguin:

ECB encrypts each block independently. Because the same plaintext block always produces the same ciphertext block, large uniform regions (like a flat-colored image background) produce visually identical ciphertext patterns. The encrypted Linux Tux penguin image is the canonical example the shape of the penguin is fully visible in the ciphertext.

Plaintext:   [BLOCK_A][BLOCK_A][BLOCK_B][BLOCK_A]
ECB Cipher:  [ENC_A  ][ENC_A  ][ENC_B  ][ENC_A  ]  ← patterns preserved
CBC Cipher:  [OUT_1  ][OUT_2  ][OUT_3  ][OUT_4  ]  ← each block depends on prior

2.2 AES-GCM in Practice

# Encrypt a file with AES-256-GCM using OpenSSL
openssl enc -aes-256-gcm \
  -in plaintext.txt \
  -out encrypted.bin \
  -K $(openssl rand -hex 32) \
  -iv $(openssl rand -hex 12)

# More robust: derive key from passphrase using PBKDF2
openssl enc -aes-256-cbc \
  -in secret.txt \
  -out secret.enc \
  -pbkdf2 \
  -iter 600000 \
  -salt

# Decrypt
openssl enc -d -aes-256-cbc \
  -in secret.enc \
  -out secret_decrypted.txt \
  -pbkdf2 \
  -iter 600000

# Generate a cryptographically secure random AES key
openssl rand -hex 32           # 256-bit key (hex)
openssl rand -base64 32        # 256-bit key (base64)

# Python: AES-GCM with PyCryptodome
python3 -c "
from Crypto.Cipher import AES
from Crypto.Random import get_random_bytes
import base64

key = get_random_bytes(32)          # AES-256
nonce = get_random_bytes(12)        # 96-bit nonce for GCM

cipher = AES.new(key, AES.MODE_GCM, nonce=nonce)
ciphertext, tag = cipher.encrypt_and_digest(b'Secret message')

print('Key:        ', base64.b64encode(key).decode())
print('Nonce:      ', base64.b64encode(nonce).decode())
print('Ciphertext: ', base64.b64encode(ciphertext).decode())
print('Auth Tag:   ', base64.b64encode(tag).decode())
# The auth tag proves integrity  if ciphertext is tampered, tag verification fails
"

2.3 The Key Distribution Problem

Symmetric encryption's fundamental weakness is key distribution. If Alice and Bob want to communicate securely:

They need to share a secret key before they can encrypt anything
If they share it over an insecure channel, an attacker intercepts it
If they share it in person, it doesn't scale to millions of TLS connections

Solution: Asymmetric encryption (next section) solves key distribution. In practice, asymmetric crypto is used to securely exchange a symmetric key, then symmetric crypto encrypts the actual data (hybrid cryptography what TLS does).

3. Asymmetric Encryption & Key Exchange

Asymmetric cryptography uses a mathematically linked key pair: a public key (shareable with anyone) and a private key (kept secret). What the public key encrypts, only the private key can decrypt and vice versa.

3.1 RSA

RSA is the most widely deployed asymmetric algorithm. Its security relies on the difficulty of factoring the product of two large prime numbers.

Key sizes and security equivalence:

RSA Key Size	Symmetric Equivalent	Status
1024-bit	~80-bit symmetric	Broken NIST deprecated 2010
2048-bit	~112-bit symmetric	Minimum acceptable, sunset by 2030
3072-bit	~128-bit symmetric	Recommended current
4096-bit	~140-bit symmetric	High security, slower

RSA operations:

# Generate RSA-4096 key pair
openssl genrsa -out private.pem 4096

# Extract public key from private key
openssl rsa -in private.pem -pubout -out public.pem

# Encrypt a file using RSA public key (for small data only  e.g., symmetric key)
openssl rsautl -encrypt \
  -inkey public.pem \
  -pubin \
  -in symmetric_key.bin \
  -out symmetric_key.enc \
  -oaep    # Use OAEP padding  never use PKCS#1 v1.5 (padding oracle attacks)

# Decrypt
openssl rsautl -decrypt \
  -inkey private.pem \
  -in symmetric_key.enc \
  -out symmetric_key_decrypted.bin \
  -oaep

# Sign a file with private key (creates signature)
openssl dgst -sha256 -sign private.pem -out signature.bin document.pdf

# Verify signature with public key
openssl dgst -sha256 -verify public.pem -signature signature.bin document.pdf
# Output: "Verified OK" or "Verification Failure"

# Inspect RSA key
openssl rsa -in private.pem -text -noout | head -20

RSA weaknesses to know:

PKCS#1 v1.5 padding vulnerable to Bleichenbacher padding oracle attack (1998, still exploited in ROBOT attack 2017). Always use OAEP.
Small exponent attacks using e=3 with unpadded messages enables cube-root attacks
No forward secrecy if the server's private key is compromised, all past sessions are decryptable (solved by ephemeral key exchange)

3.2 Elliptic Curve Cryptography (ECC)

ECC provides equivalent security to RSA at dramatically shorter key lengths, by exploiting the difficulty of the elliptic curve discrete logarithm problem (ECDLP).

Size comparison:

Security Level	RSA Key Size	ECC Key Size
128-bit	3072-bit	256-bit (P-256 / secp256r1)
192-bit	7680-bit	384-bit (P-384 / secp384r1)
256-bit	15360-bit	521-bit (P-521 / secp521r1)

ECC's smaller keys mean faster handshakes, less bandwidth, and lower CPU usage critical for TLS performance at scale and IoT/embedded systems.

# Generate EC key pair (P-256 curve  common for TLS)
openssl ecparam -name prime256v1 -genkey -noout -out ec_private.pem

# Extract public key
openssl ec -in ec_private.pem -pubout -out ec_public.pem

# View key parameters
openssl ec -in ec_private.pem -text -noout

# List available curves
openssl ecparam -list_curves | grep -E "prime|secp|brainpool"

Curve security notes:

P-256 (secp256r1 / prime256v1): NIST curve, widely deployed, concerns about NIST backdoor (unproven)
Curve25519: Bernstein's curve, designed to be immune to several classes of attacks, used in modern TLS/SSH (X25519 for key exchange, Ed25519 for signatures)
secp256k1: Bitcoin's curve not recommended for general TLS

3.3 Diffie-Hellman Key Exchange & ECDHE

DH allows two parties to establish a shared secret over an insecure channel without transmitting the secret. ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) is the modern standard.

ECDHE Conceptual Flow:

Alice                              Bob
─────                              ────
Generate ephemeral EC key pair     Generate ephemeral EC key pair
(a_priv, a_pub)                    (b_priv, b_pub)

Send a_pub ──────────────────────→ Receive a_pub
Receive b_pub ←────────────────── Send b_pub

Compute shared = a_priv * b_pub    Compute shared = b_priv * a_pub
                                   [Same result due to EC math]

Derive session keys from shared secret
Both sides have identical session keys without ever transmitting them

"Ephemeral" means a new key pair is generated for each session. Even if the server's long-term private key is later stolen, past sessions cannot be decrypted this is forward secrecy (PFS).

4. Hashing & Message Authentication

4.1 Cryptographic Hash Functions

A cryptographic hash function produces a fixed-size digest from arbitrary input. Properties required:

Deterministic: Same input always → same output
One-way (preimage resistance): Given H(x), infeasible to find x
Collision resistance: Infeasible to find x ≠ y where H(x) = H(y)
Avalanche effect: Tiny change in input → completely different output

Algorithm	Output Size	Status	Use
MD5	128-bit	Broken collisions trivial	Legacy only, never for security
SHA-1	160-bit	Broken SHAttered 2017	Deprecated in TLS/code signing
SHA-256	256-bit	Secure	TLS, code signing, git commits
SHA-384	384-bit	Secure	NSA Suite B, government use
SHA-512	512-bit	Secure	High-security hashing
SHA-3 (Keccak)	Variable	Secure	NIST standard, different design
BLAKE2	Variable	Secure	Faster than SHA-2, used in WireGuard
bcrypt	184-bit	Secure	Password hashing (slow by design)
Argon2	Variable	Secure	Password hashing, PHC winner

# Hash a file with multiple algorithms for comparison
sha256sum /bin/ls
sha512sum /bin/ls
md5sum /bin/ls        # Only for legacy compatibility verification

# Python: demonstrate avalanche effect
python3 -c "
import hashlib
msg1 = b'Hello, World!'
msg2 = b'Hello, World.'   # Only the '!' changed to '.'

h1 = hashlib.sha256(msg1).hexdigest()
h2 = hashlib.sha256(msg2).hexdigest()

print(f'Message 1 hash: {h1}')
print(f'Message 2 hash: {h2}')

# Count differing bits
diff = bin(int(h1, 16) ^ int(h2, 16)).count('1')
print(f'Differing bits: {diff}/256 ({diff/256*100:.1f}%)')
# Expected: ~50% of bits differ despite 1-character change
"

# Verify file integrity using checksum
sha256sum -c checksums.sha256

# Create checksums for a directory
find /opt/app -type f -exec sha256sum {} \; > app_checksums.sha256

4.2 HMAC Hash-based Message Authentication Code

A plain hash does not authenticate the sender anyone can hash a message. HMAC uses a shared secret key combined with the hash function to produce a Message Authentication Code that proves both integrity and authenticity.

HMAC(key, message) = Hash((key XOR opad) || Hash((key XOR ipad) || message))

import hmac, hashlib, os

# Generate shared secret (would be exchanged securely in practice)
secret_key = os.urandom(32)    # 256-bit key
message = b"Transfer $10,000 to account 12345"

# Compute HMAC-SHA256
mac = hmac.new(secret_key, message, hashlib.sha256).hexdigest()
print(f"HMAC: {mac}")

# Verify (constant-time comparison prevents timing attacks)
def verify_hmac(key, message, received_mac):
    computed = hmac.new(key, message, hashlib.sha256).hexdigest()
    # hmac.compare_digest is timing-safe  prevents timing oracle attacks
    return hmac.compare_digest(computed, received_mac)

# If attacker modifies message, HMAC verification fails
tampered = b"Transfer $10,000 to account 99999"
print(verify_hmac(secret_key, tampered, mac))   # False
print(verify_hmac(secret_key, message, mac))    # True

Critical: Never use == to compare HMACs use hmac.compare_digest(). A simple string comparison leaks timing information: it returns faster when the first bytes match, allowing an attacker to brute-force the HMAC byte by byte.

4.3 Password Hashing

Storing passwords requires slow hash functions with salting. Fast hashes (SHA-256) can be brute-forced at billions of hashes/second on modern GPUs.

# Generate bcrypt hash (Python)
python3 -c "
import bcrypt
password = b'SecurePassword123!'

# Hash with bcrypt (work factor 12 = 2^12 iterations)
hashed = bcrypt.hashpw(password, bcrypt.gensalt(rounds=12))
print(f'bcrypt hash: {hashed.decode()}')

# Verify
print(bcrypt.checkpw(password, hashed))     # True
print(bcrypt.checkpw(b'WrongPassword', hashed))  # False
"

# Argon2 (PHC winner, recommended for new systems)
python3 -c "
from argon2 import PasswordHasher
ph = PasswordHasher(
    time_cost=3,          # Number of iterations
    memory_cost=65536,    # 64MB memory (makes GPU attacks expensive)
    parallelism=2         # Threads
)
hash = ph.hash('SecurePassword123!')
print(f'Argon2 hash: {hash}')

try:
    ph.verify(hash, 'SecurePassword123!')
    print('Valid password')
except:
    print('Invalid password')
"

# Check password hashing speed (lower = better for defenders)
# bcrypt at cost 12: ~250ms per hash → 4 guesses/sec
# SHA-256: ~0.00001ms per hash → 10 billion guesses/sec (GPU)
# The 10-billion-to-4 ratio is why bcrypt/Argon2 matters

5. TLS How the Internet Actually Encrypts Traffic

TLS (Transport Layer Security) is the protocol that encrypts the vast majority of internet traffic. Understanding its internals is essential for identifying misconfigurations, intercepting traffic in authorized contexts, and understanding exactly what it does and doesn't protect.

5.1 TLS 1.3 Handshake (Modern Standard)

TLS 1.3 (RFC 8446, 2018) reduced the handshake from 2 round trips (TLS 1.2) to 1 round trip, removed all legacy cipher suites, and mandated forward secrecy.

Client                                          Server
──────                                          ──────

1. ClientHello
   ├── TLS version: 1.3
   ├── Random nonce (32 bytes)
   ├── Supported cipher suites:
   │     TLS_AES_256_GCM_SHA384
   │     TLS_CHACHA20_POLY1305_SHA256
   │     TLS_AES_128_GCM_SHA256
   └── Key Share (ECDHE public key, e.g., X25519)
   ─────────────────────────────────────────────────────────→

                                          2. ServerHello
                                             ├── Selected cipher suite
                                             ├── Server's ECDHE public key
                                             └── [Both sides now compute shared secret]
                                             ├── {EncryptedExtensions}
                                             ├── {Certificate}
                                             ├── {CertificateVerify} ← signed with server private key
                                             └── {Finished} ← HMAC of handshake transcript
   ←─────────────────────────────────────────────────────────

3. Client verifies certificate chain
   Client sends {Finished}
   ─────────────────────────────────────────────────────────→

[Application data encrypted with AES-256-GCM or ChaCha20-Poly1305]

Key improvements in TLS 1.3 vs 1.2:

Mandatory forward secrecy only ECDHE/DHE key exchange allowed (static RSA removed)
Fewer cipher suites legacy algorithms removed (RC4, 3DES, CBC mode, MD5)
0-RTT resumption for repeat connections (with replay attack caveats)
Encrypted more of handshake certificate is encrypted in TLS 1.3 (was cleartext in 1.2)

5.2 Cipher Suite Anatomy

A cipher suite specifies which algorithms are used for each cryptographic function in TLS:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 │    │      │       │    │    │   │
 │    │      │       │    │    │   └── PRF/HMAC hash: SHA-384
 │    │      │       │    │    └────── Mode: GCM (AEAD)
 │    │      │       │    └─────────── Key size: 256-bit
 │    │      │       └──────────────── Symmetric cipher: AES
 │    │      └──────────────────────── Auth/Signing: RSA cert
 │    └─────────────────────────────── Key exchange: ECDHE (ephemeral)
 └──────────────────────────────────── Protocol: TLS

TLS 1.3 simplified form (key exchange always ephemeral, implicit):
TLS_AES_256_GCM_SHA384
     │    │    │   │
     │    │    │   └── Hash for HKDF key derivation
     │    │    └────── Mode: GCM (AEAD)
     │    └─────────── Key size: 256-bit
     └──────────────── Symmetric cipher: AES

5.3 Inspecting TLS Configuration

# Full TLS inspection with OpenSSL
openssl s_client -connect target.com:443 \
  -tls1_3 \
  -showcerts \
  -servername target.com

# Check what cipher suites a server supports (using nmap)
nmap --script ssl-enum-ciphers -p 443 target.com

# Check for weak cipher suites with testssl.sh (comprehensive)
./testssl.sh --severity HIGH --color 3 https://target.com

# Check certificate expiry
echo | openssl s_client -connect target.com:443 2>/dev/null | \
  openssl x509 -noout -dates

# Check for deprecated TLS 1.0/1.1 support (should return error on hardened servers)
openssl s_client -connect target.com:443 -tls1    # TLS 1.0
openssl s_client -connect target.com:443 -tls1_1  # TLS 1.1

# Extract and inspect the server certificate
echo | openssl s_client -connect target.com:443 2>/dev/null | \
  openssl x509 -noout -text | grep -A5 "Subject:\|Issuer:\|Validity\|Subject Alternative"

# Check HSTS header (HTTP Strict Transport Security)
curl -sI https://target.com | grep -i strict-transport

# Check OCSP stapling
openssl s_client -connect target.com:443 -status 2>/dev/null | grep -A5 "OCSP response"

5.4 TLS Security Configuration (Nginx / Apache)

# Nginx: hardened TLS configuration
server {
    listen 443 ssl http2;
    server_name target.com;

    ssl_certificate     /etc/ssl/certs/target.com.crt;
    ssl_certificate_key /etc/ssl/private/target.com.key;

    # TLS versions: disable 1.0 and 1.1
    ssl_protocols TLSv1.2 TLSv1.3;

    # Cipher suites: TLS 1.3 suites are automatic; these apply to TLS 1.2
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
    ssl_prefer_server_ciphers off;

    # ECDHE curve preference
    ssl_ecdh_curve X25519:prime256v1:secp384r1;

    # Session resumption (performance, with forward secrecy caveats)
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    # HSTS: force HTTPS for 1 year, include subdomains, allow preloading
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # OCSP Stapling  server fetches and caches OCSP response
    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 1.1.1.1 8.8.8.8 valid=300s;

    # Certificate Transparency
    add_header Expect-CT "max-age=86400, enforce";
}

6. PKI Public Key Infrastructure

PKI is the system of trust that makes TLS work at internet scale. It answers the question: how do I know this public key actually belongs to google.com?

6.1 The Certificate Chain of Trust

Root CA (self-signed, in OS/browser trust store)
   │  Signs ↓
Intermediate CA (issued by Root CA)
   │  Signs ↓
Server Certificate (issued by Intermediate CA, contains server public key)
   │
   └── Subject: CN=target.com
       SubjectAltName: DNS:target.com, DNS:www.target.com
       Public Key: [server's public key]
       Signature: [signed by Intermediate CA's private key]

Why intermediates? Root CA private keys are stored offline in HSMs (Hardware Security Modules) in physical vaults. They sign intermediate CAs, then go offline. If an intermediate CA is compromised, it can be revoked without replacing the Root CA embedded in all OS/browser trust stores.

6.2 Certificate Fields Critical for Security

# Inspect certificate in detail
openssl x509 -in cert.pem -text -noout

# Key fields to examine:
# Subject  who the cert was issued to
# Issuer  who signed the cert
# Validity  NotBefore, NotAfter (check for expiry)
# SubjectAltName (SAN)  all hostnames this cert is valid for
# KeyUsage  what operations are allowed (Digital Signature, Key Encipherment)
# ExtendedKeyUsage  TLS Web Server Authentication
# BasicConstraints  CA:TRUE means it can sign other certs (dangerous if unexpected)
# CRL Distribution Points  where to check if cert is revoked
# OCSP (AuthorityInfoAccess)  real-time revocation checking

# Example: find all SANs on a certificate
echo | openssl s_client -connect target.com:443 2>/dev/null | \
  openssl x509 -noout -text | grep -A1 "Subject Alternative"

6.3 Certificate Transparency (CT)

CT is a public, append-only log of all certificates ever issued. Any certificate not in a CT log is rejected by Chrome/Firefox. This enables detection of:

Misissued certificates (CA compromise, BGP hijack + fraudulent cert request)
Unauthorized certificates for your domain
Shadow IT certificates issued for subdomains you didn't know existed

# Monitor CT logs for your domain using crt.sh
curl -s 'https://crt.sh/?q=%.yourdomain.com&output=json' | \
  python3 -c "
import sys, json
certs = json.load(sys.stdin)
for c in certs:
    print(f\"{c['not_before'][:10]}  {c['name_value']}\")
" | sort -u

# Automated monitoring: certspotter (open source)
go install software.sslmate.com/src/certspotter/cmd/certspotter@latest
certspotter -watchlist domains.txt -script alert.sh

6.4 Certificate Revocation

If a private key is compromised, the certificate must be revoked. Two mechanisms exist:

Mechanism	How It Works	Weakness
CRL (Certificate Revocation List)	CA publishes a list of revoked serial numbers	Huge files, cached for days delayed revocation
OCSP (Online Certificate Status Protocol)	Real-time query to CA's OCSP responder	Privacy (CA sees every site you visit), OCSP responder can be DoS'd
OCSP Stapling	Server fetches and staples OCSP response to TLS handshake	Solves privacy, server must refresh periodically

The soft-fail problem: Most browsers implement OCSP with "soft fail" if the OCSP responder is unreachable, the browser accepts the certificate anyway. An attacker who steals a private key can block the OCSP responder to prevent revocation enforcement.

7. Cryptographic Attacks & Common Misconfigurations

7.1 SSL Stripping

SSL stripping downgrades an HTTPS connection to HTTP by intercepting the initial HTTP request before the redirect to HTTPS occurs.

Normal flow:
  User types: http://bank.com
  Browser → HTTP GET / → Server → 301 Redirect to https://bank.com
  Browser → HTTPS connection established

SSL Stripping (Moxie Marlinspike, 2009):
  User types: http://bank.com
  Browser → HTTP GET / → [Attacker intercepts]
  Attacker → HTTPS connection → bank.com (attacker sees plaintext)
  Attacker → HTTP response → Browser (victim thinks they're on HTTP)
  All traffic: Bank <HTTPS> Attacker <HTTP> Victim

# SSL stripping with mitmproxy (authorized testing only)
mitmproxy --mode transparent --ssl-insecure

# Detection: check if site sends HSTS header
curl -sI http://bank.com | grep -i "strict-transport"
# Without HSTS: vulnerable to SSL stripping
# With HSTS max-age=31536000: browser refuses HTTP for 1 year

# HSTS Preload: ultimate protection
# Domains submitted to https://hstspreload.org are hardcoded into browsers
# Browser will NEVER attempt HTTP, even on first visit

7.2 Certificate Pinning & Bypass

Certificate pinning embeds a specific certificate or public key hash in an application, rejecting any other cert even if it's signed by a trusted CA.

# Pin verification: HPKP header (deprecated in browsers, still used in mobile apps)
# Public-Key-Pins: pin-sha256="base64hash"; max-age=5184000; includeSubDomains

# Bypass attempts in mobile app testing:
# 1. Frida hook (dynamic instrumentation)
# Patch SSLContext.checkServerTrusted() at runtime
frida -U -l ssl_pinning_bypass.js com.target.app

# 2. objection (builds on Frida)
objection -g com.target.app explore
# ios sslpinning disable
# android sslpinning disable

# 3. Check certificate pins in APK
apktool d target.apk
grep -r "sha256\|pin\|certificate" target/res/xml/network_security_config.xml

7.3 POODLE, BEAST, CRIME, BREACH, ROBOT

These are all cryptographic attacks against TLS:

Attack	Year	Target	Mechanism	Mitigation
BEAST	2011	TLS 1.0 CBC	IV prediction in CBC mode	Disable TLS 1.0
CRIME	2012	TLS compression	Compression oracle leaks secrets	Disable TLS compression
BREACH	2013	HTTP compression	Similar to CRIME but HTTP-level	Disable HTTP compression for secret data
POODLE	2014	SSLv3 CBC	Padding oracle via SSLv3 downgrade	Disable SSLv3/TLS 1.0/1.1
FREAK	2015	RSA export cipher	Downgrade to 512-bit RSA	Remove export cipher suites
Logjam	2015	DHE key exchange	Downgrade to 512-bit DH	Use DHE 2048-bit or ECDHE
DROWN	2016	SSLv2 cross-protocol	SSLv2 oracle on shared keys	Disable SSLv2, don't reuse keys
ROBOT	2017	RSA PKCS#1 v1.5	Bleichenbacher oracle resurface	Use RSA-OAEP or prefer ECDHE
RACCOON	2020	DHE timing	Timing oracle in DH premaster	Disable DHE, use ECDHE only

7.4 Common Cryptographic Misconfigurations

# 1. Weak cipher suites check
nmap --script ssl-enum-ciphers -p 443 target.com | grep -E "WEAK|DES|RC4|export|anon"

# 2. Self-signed certificate detection
echo | openssl s_client -connect target.com:443 2>/dev/null | \
  openssl x509 -noout -issuer -subject | \
  awk '{if($0 ~ /issuer/ && $0 ~ /subject/) print "SELF-SIGNED"}'

# 3. Expired certificate check
openssl x509 -enddate -noout -in cert.pem | \
  python3 -c "
import sys, datetime
line = sys.stdin.read().strip()
date_str = line.split('=')[1]
expiry = datetime.datetime.strptime(date_str, '%b %d %H:%M:%S %Y %Z')
days_left = (expiry - datetime.datetime.utcnow()).days
print(f'Expires: {expiry} ({days_left} days remaining)')
if days_left < 30:
    print('WARNING: Certificate expiring soon!')
if days_left < 0:
    print('CRITICAL: Certificate EXPIRED!')
"

# 4. Weak DH parameters check (Logjam)
openssl s_client -connect target.com:443 2>/dev/null | grep "Server Temp Key"
# Look for: "Server Temp Key: DH, 1024 bits" = VULNERABLE
# Good:      "Server Temp Key: X25519, 253 bits" or "ECDH, P-256, 256 bits"

# 5. TLS 1.0/1.1 enabled check
for v in tls1 tls1_1; do
  result=$(echo | openssl s_client -connect target.com:443 -$v 2>&1)
  if echo "$result" | grep -q "Cipher is"; then
    echo "$v: ENABLED (should be disabled)"
  else
    echo "$v: Disabled (good)"
  fi
done

8. Practical Cryptography on the Command Line

8.1 GPG for File Encryption & Signing

# Generate GPG key pair
gpg --full-generate-key
# Choose: RSA and RSA, 4096 bits, expiry, name/email

# List keys
gpg --list-keys
gpg --list-secret-keys

# Export public key (share with others)
gpg --export --armor analyst@company.com > analyst_public.asc

# Import someone else's public key
gpg --import their_public.asc

# Encrypt file for a recipient
gpg --encrypt --armor --recipient recipient@company.com secret.txt
# Produces: secret.txt.asc (encrypted, only recipient can decrypt)

# Decrypt
gpg --decrypt secret.txt.asc > secret_decrypted.txt

# Sign a file (proves authenticity)
gpg --detach-sign --armor document.pdf
# Produces: document.pdf.asc (signature file)

# Verify signature
gpg --verify document.pdf.asc document.pdf

# Encrypt AND sign in one step
gpg --encrypt --sign --armor \
  --recipient recipient@company.com \
  --local-user analyst@company.com \
  sensitive_report.pdf

8.2 OpenSSL Swiss Army Knife

# Generate a Certificate Signing Request (CSR) for a new certificate
openssl req -new -newkey rsa:4096 -nodes \
  -keyout server.key \
  -out server.csr \
  -subj "/C=US/ST=California/O=Company/CN=target.com" \
  -addext "subjectAltName=DNS:target.com,DNS:www.target.com,DNS:api.target.com"

# Create a self-signed cert (for testing only)
openssl req -x509 -newkey rsa:4096 -days 365 -nodes \
  -keyout self_signed.key \
  -out self_signed.crt \
  -subj "/CN=localhost"

# Convert PEM to PKCS#12 (for importing into Windows/Java keystores)
openssl pkcs12 -export \
  -out certificate.p12 \
  -inkey server.key \
  -in server.crt \
  -certfile ca_chain.crt

# Convert PKCS#12 back to PEM
openssl pkcs12 -in certificate.p12 -out server.pem -nodes

# Test a TLS handshake and measure latency
time echo | openssl s_client -connect target.com:443 -tls1_3 2>/dev/null | grep "Protocol\|Cipher"

# Decode a base64 JWT token to inspect claims (not verify)
echo "eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiJ1c2VyMTIzIn0.SIGNATURE" | \
  cut -d. -f2 | \
  base64 -d 2>/dev/null | python3 -m json.tool

8.3 WireShark / tcpdump Validating Encryption

# Capture TLS traffic and verify it's encrypted
tcpdump -i eth0 -w capture.pcap 'tcp port 443' &
curl -s https://target.com > /dev/null
pkill tcpdump

# Inspect with tshark  should see encrypted Application Data, not plaintext
tshark -r capture.pcap -Y "tls" -T fields \
  -e tls.record.content_type \
  -e tls.handshake.type \
  -e tls.app_data

# Decrypt TLS with SSLKEYLOGFILE (browser/curl pre-master secret export)
# In your shell before running curl:
export SSLKEYLOGFILE=/tmp/tls_keys.log
curl https://target.com > /dev/null

# Now Wireshark can decrypt: Edit → Preferences → TLS → (Pre)-Master-Secret log
# tshark decrypt:
tshark -r capture.pcap \
  -o "tls.keylog_file:/tmp/tls_keys.log" \
  -Y "http" \
  -T fields -e http.request.uri

# This is how enterprise TLS inspection / break-and-inspect works at scale

Table of Contents​

1. Cryptographic Primitives​

The Core Security Properties​

Kerckhoffs's Principle​

2. Symmetric Encryption​

2.1 AES Advanced Encryption Standard​

2.2 AES-GCM in Practice​

2.3 The Key Distribution Problem​

3. Asymmetric Encryption & Key Exchange​

3.1 RSA​

3.2 Elliptic Curve Cryptography (ECC)​

3.3 Diffie-Hellman Key Exchange & ECDHE​

4. Hashing & Message Authentication​

4.1 Cryptographic Hash Functions​

4.2 HMAC Hash-based Message Authentication Code​

4.3 Password Hashing​

5. TLS How the Internet Actually Encrypts Traffic​

5.1 TLS 1.3 Handshake (Modern Standard)​

5.2 Cipher Suite Anatomy​

5.3 Inspecting TLS Configuration​

5.4 TLS Security Configuration (Nginx / Apache)​

6. PKI Public Key Infrastructure​

6.1 The Certificate Chain of Trust​

6.2 Certificate Fields Critical for Security​

6.3 Certificate Transparency (CT)​

6.4 Certificate Revocation​

7. Cryptographic Attacks & Common Misconfigurations​

7.1 SSL Stripping​

7.2 Certificate Pinning & Bypass​

7.3 POODLE, BEAST, CRIME, BREACH, ROBOT​

7.4 Common Cryptographic Misconfigurations​

8. Practical Cryptography on the Command Line​

8.1 GPG for File Encryption & Signing​

8.2 OpenSSL Swiss Army Knife​

8.3 WireShark / tcpdump Validating Encryption​

9. Architecture Diagram​

Table of Contents