Hashing, Certificates, and TLS: Trust on the Internet

Encryption keeps secrets. But security needs more than secrecy. You also need:

• Integrity: Has the data been tampered with?
• Authentication: Am I talking to who I think I’m talking to?

Hashing solves the first. Certificates and TLS solve the second. Together with encryption, they form the three pillars that make secure communication on the internet possible.

Hashing: One-Way Fingerprints

A hash function takes input of any size and produces a fixed-size output (the hash or digest). It’s a one-way operation - you can’t reverse it back to the input.

"hello"         → SHA-256 → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
"hello!"        → SHA-256 → ce06092fb948d9ffac7d1a376e404b26b7575bcc11ee05a4615fef4fec3a308b
"hello"         → SHA-256 → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Three critical properties:

1. Deterministic: Same input always produces the same hash
2. Avalanche effect: A tiny change in input completely changes the output (“hello” vs “hello!” are totally different)
3. One-way: Given a hash, you can’t compute the original input

Hash Functions You Should Know

Algorithm	Output Size	Status	Use Case
MD5	128-bit	Broken	Checksums only (not security)
SHA-1	160-bit	Broken	Legacy, being phased out
SHA-256	256-bit	Secure	General purpose, file integrity
SHA-3	Variable	Secure	Alternative to SHA-2 family
bcrypt	184-bit	Secure	Password hashing
Argon2	Variable	Secure	Password hashing (modern best)

“Broken” means someone has found a way to create collisions - two different inputs that produce the same hash. For MD5 and SHA-1, this has been demonstrated practically.

Where Hashing Is Used

File integrity verification:

# Check if a downloaded file matches the expected hash
sha256sum downloaded-file.iso
# Compare output to the hash published on the website

If the hashes match, the file hasn’t been corrupted or tampered with.

Password storage:

# Store this (hash), not the actual password
import bcrypt
hashed = bcrypt.hashpw(b"password123", bcrypt.gensalt())
# Result: $2b$12$LJ3m4ys.Gx7jHkpYMfKC0e...

As we covered in the authentication post, passwords should be hashed with bcrypt, scrypt, or Argon2 - algorithms designed to be slow, making brute force impractical.

Data integrity in protocols:

TLS uses hashing to verify that messages haven’t been modified in transit. Every TLS message includes a Message Authentication Code (MAC) - a hash of the message combined with the session key. If a single bit is altered, the MAC doesn’t match and the message is rejected.

Git commits:

Every Git commit is identified by its SHA-1 hash. The hash covers the commit content, parent commit, author, and timestamp. Changing any part of history changes all downstream hashes.

Digital Signatures: Proof of Identity

Digital signatures combine hashing and asymmetric encryption to prove two things:

1. Who created or approved a piece of data
2. That the data hasn’t been modified since it was signed

How Signing Works

Signing (by Alice):
1. Hash the document → produces a digest
2. Encrypt the digest with Alice's PRIVATE key → this is the signature
3. Send the document + signature

Verification (by anyone):
1. Hash the document → produces a digest
2. Decrypt the signature with Alice's PUBLIC key → produces the original digest
3. Compare: if they match, the signature is valid

Why this works:

• Only Alice has her private key, so only she could have created the signature
• If the document is modified, the hash changes and the verification fails
• Anyone with Alice’s public key can verify, but nobody can forge

Where Digital Signatures Are Used

• Software updates: OS and package managers verify update signatures before installing
• Email: S/MIME and PGP sign emails to prove sender identity
• Code signing: Executables signed by the developer prove they haven’t been tampered with
• TLS certificates: Signed by Certificate Authorities to prove server identity
• Legal documents: Some jurisdictions accept digital signatures on contracts

Certificates: Identity Cards for Servers

When you connect to https://bank.com, how do you know you’re actually talking to your bank and not an impostor?

Certificates. They’re digital identity cards for servers, issued by trusted authorities.

What’s in a Certificate

A TLS certificate contains:

Field	Purpose
Subject	Who the certificate is for (e.g., bank.com)
Issuer	Who issued it (Certificate Authority)
Public Key	The server’s public key
Validity Period	Start and expiration dates
Serial Number	Unique identifier
Signature	CA’s digital signature over all the above

How Certificate Trust Works

1. Your browser connects to bank.com
2. Bank.com presents its certificate
3. Your browser checks:
   a. Is the certificate for bank.com? (domain match)
   b. Has it expired? (validity period)
   c. Who signed it? (issuer)
   d. Is the issuer trusted? (check against browser's trust store)
   e. Is the signature valid? (verify with CA's public key)
4. If all checks pass → connection proceeds
5. If any check fails → "Your connection is not private" warning

Certificate Authorities (CAs)

CAs are organizations trusted to verify identity and issue certificates. Your browser and OS ship with a list of trusted CAs (the trust store).

Root CAs (trusted by browsers)
├── DigiCert
├── Let's Encrypt (ISRG Root)
├── GlobalSign
├── Sectigo
└── ... (~100 trusted roots

The chain of trust:

Root CA (in browser trust store)
└── signs → Intermediate CA certificate
              └── signs → Your server's certificate

The browser trusts the root CA. The root CA vouches for the intermediate CA. The intermediate CA vouches for your server. Trust flows down the chain.

Certificate Types

Type	Validation	What CA Verifies
DV (Domain Validation)	Minimal	You control the domain (DNS or HTTP challenge)
OV (Organization Validation)	Moderate	Legal organization exists
EV (Extended Validation)	Extensive	Legal entity, physical address, operational existence

Let’s Encrypt issues free DV certificates automatically. This made HTTPS accessible to everyone and is why the “HTTPS = safe” assumption no longer holds - phishing sites can have valid certificates too.

When Certificates Go Wrong

Problem	What Happens
Expired certificate	Browser shows warning
Wrong domain	Certificate for example.com used on other.com - warning
Self-signed	No CA vouches for it - warning (common in internal/dev environments)
Revoked	CA has revoked the certificate (compromised key, fraud)
CA compromised	All certificates from that CA are suspect (DigiNotar incident, 2011)

Certificate Pinning

Some applications go beyond CA trust by pinning - they expect a specific certificate or public key, not just any valid certificate.

Normal TLS:     "Is the certificate valid and signed by any trusted CA?"
Pinning:        "Is this the EXACT certificate/key I expect for this server?"

Pinning prevents attacks where someone has a valid certificate from a different CA (e.g., a government CA that was compromised). However, it’s fallen out of favor in browsers because it’s difficult to manage and can cause outages.

TLS: Putting It All Together

TLS (Transport Layer Security) combines everything we’ve covered:

• Asymmetric encryption for key exchange
• Symmetric encryption for data confidentiality
• Hashing for data integrity
• Certificates for server authentication
• Digital signatures for verification

The TLS 1.3 Handshake

TLS 1.3 (the current version) is simpler and faster than older versions:

Client                                    Server
  │                                         │
  │──── ClientHello ─────────────────────▶  │
  │     (supported ciphers, key share)      │
  │                                         │
  │  ◀── ServerHello ──────────────────────│
  │      (chosen cipher, key share,         │
  │       certificate, signature)           │
  │                                         │
  │     [Both compute shared secret]        │
  │     [Encrypted communication begins]    │
  │                                         │
  │──── Finished ────────────────────────▶  │
  │  ◀── Finished ─────────────────────────│
  │                                         │
  │◀════ Encrypted Application Data ══════▶│

Step by step:

1. ClientHello: Browser sends supported cipher suites and its key share (Diffie-Hellman public value)
2. ServerHello: Server picks a cipher suite, sends its key share, certificate, and a signature proving it owns the private key
3. Key derivation: Both sides compute the shared secret from the key exchange
4. Finished: Both confirm the handshake completed without tampering
5. Application data: Everything from here is encrypted with the shared symmetric key

TLS 1.3 completes in one round trip (1-RTT), compared to two in TLS 1.2. There’s even a 0-RTT mode for resumed connections.

Cipher Suites

A cipher suite defines the algorithms used for each component:

TLS_AES_256_GCM_SHA384
│    │        │    │
│    │        │    └── Hash function for key derivation
│    │        └── Encryption mode (authenticated)
│    └── Symmetric encryption algorithm + key size
└── Protocol

TLS 1.3 only allows strong cipher suites. Older suites with known weaknesses (RC4, DES, export-grade) are removed entirely.

TLS Version History

Version	Year	Status
SSL 2.0	1995	Broken, disabled everywhere
SSL 3.0	1996	Broken (POODLE), disabled
TLS 1.0	1999	Deprecated (BEAST, CRIME)
TLS 1.1	2006	Deprecated
TLS 1.2	2008	Secure, widely used
TLS 1.3	2018	Best, recommended

If you encounter a server still using TLS 1.0 or 1.1, that’s a finding in a security assessment.

Attacks on Cryptographic Systems

Man-in-the-Middle (MitM)

Without TLS, an attacker between client and server can read and modify traffic:

Client ──plaintext──▶ Attacker ──plaintext──▶ Server
       ◀──plaintext──          ◀──plaintext──

With TLS, the attacker can’t read the encrypted traffic. But if they can present a fake certificate that the client trusts (compromised CA, installed root certificate), they can intercept:

Client ──TLS (fake cert)──▶ Attacker ──TLS (real cert)──▶ Server

Corporate networks sometimes do this intentionally (TLS inspection) by installing their CA certificate on all company machines.

Downgrade Attacks

Force a connection to use an older, weaker protocol or cipher suite:

Attacker intercepts ClientHello, modifies supported ciphers to only include weak options
Server picks a weak cipher (if it still supports one)
Attacker exploits the weak cipher

TLS 1.3 prevents this by signing the entire handshake, including the cipher negotiation.

Padding Oracle Attacks

Exploit error messages from CBC-mode decryption to decrypt ciphertext without the key. The POODLE attack against SSL 3.0 used this technique.

Defense: Use AEAD modes (AES-GCM) which don’t have padding oracle vulnerabilities.

Side-Channel Attacks

Extract key information through observable side effects:

Side Channel	What Leaks
Timing	Operations take different time based on key bits
Power consumption	Different operations draw different power
Cache behavior	Memory access patterns reveal information
Electromagnetic	EM emissions from the processor

These attacks target the implementation, not the algorithm. Constant-time implementations mitigate timing attacks.

Practical Verification

Commands to inspect real TLS connections:

# Check a website's certificate
openssl s_client -connect example.com:443 -brief

# Show full certificate details
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -text -noout

# Check TLS version and cipher
echo | openssl s_client -connect example.com:443 2>/dev/null | grep -E "Protocol|Cipher"

# Verify a file's hash
sha256sum file.txt

# Generate a hash of a string
echo -n "hello" | sha256sum

# Compare two files by hash
sha256sum file1.txt file2.txt

Online tools:

• SSL Labs - Test any server’s TLS configuration
• crt.sh - Search certificate transparency logs

The Mental Model

Here’s how all the pieces fit together:

Problem                     Solution              Tool
───────────────────────────────────────────────────────
Keep data secret        →   Encryption        →   AES-GCM, ChaCha20
Verify data unchanged   →   Hashing           →   SHA-256, HMAC
Prove who sent it       →   Digital Signatures →   RSA, ECDSA
Verify server identity  →   Certificates      →   X.509, PKI
Secure communication    →   TLS               →   All of the above
Store passwords safely  →   Password Hashing  →   bcrypt, Argon2

Each piece solves one problem. TLS combines them all into a practical protocol that secures every HTTPS connection.

What’s Next

The cryptography module is complete. You now understand:

• How symmetric and asymmetric encryption work and why we use both
• What hashing does and where it’s used (integrity, passwords, signatures)
• How certificates and CAs establish trust
• How TLS puts it all together

Up next is Module 5: The Attacker’s Playbook - the kill chain, reconnaissance, reverse shells, privilege escalation, and social engineering. You’ve already read the reverse shell posts; now we’ll fill in the rest of the attack chain.

References

• Cloudflare - What is TLS?
• SSL Labs - SSL/TLS Deployment Best Practices
• Let’s Encrypt - How It Works
• Certificate Transparency

---

The math behind cryptography is elegant. But what matters in practice isn’t the algorithm - it’s whether the key is stored securely, the certificate is verified, and the protocol version isn’t from 2006. Crypto fails at the seams, not the center.