Password Attacks & Cryptography · intermediate · ~12 min

TLS, certificates, and digital signatures

Explain how TLS uses certificates and signatures to establish trusted, encrypted channels.

Overview

TLS combines digital signatures (hash signed with a private key, verified with the public key → authenticity + integrity), certificates (a CA-signed binding of public key to hostname, validated up a trust chain), and a handshake that authenticates the server and derives a symmetric session key. Testers flag weak versions/ciphers and bad certs.

Why it matters

TLS is the backbone of secure communication, and its building blocks (signatures, certificate chains) recur in code signing and JWTs. TLS/cert misconfigurations (weak ciphers, expired/mismatched certs, missing HSTS) are routine findings.

Core concepts

Signature. Hash signed by private key, verified by public → authenticity+integrity. Certificate. CA-signed public-key↔hostname binding; validate chain/expiry/hostname/revocation. Handshake. Authenticate server → derive symmetric session key. Findings. Weak versions/ciphers, bad certs, no HSTS.

Lesson

TLS secures most network traffic by combining the crypto primitives into a trusted channel.

Digital signatures (the trust primitive)

Signing = encrypting a hash of data with a private key; anyone verifies with the matching public key. A valid signature proves authenticity (it came from the key holder) and integrity (unchanged). This is how software updates, JWTs, and certificates are trusted.

Certificates and the PKI chain

How do you trust a server's public key? A certificate binds a public key to an identity (a hostname), signed by a Certificate Authority (CA). Your system trusts a set of root CAs; a server's cert chains up to one. The browser checks: signature valid, not expired, hostname matches, not revoked. Certificate Transparency logs every issued cert publicly (useful for recon, as covered earlier).

The TLS handshake (simplified)

  1. Negotiate parameters; server presents its certificate.
  2. Client validates the cert chain (authenticity).
  3. Key exchange (asymmetric / Diffie-Hellman) derives a shared session key.
  4. Bulk traffic uses fast symmetric encryption with that key. So TLS gives confidentiality + integrity + server authentication — the three guarantees from the networking track.

What testers check

Weak protocol versions (SSLv3/TLS 1.0), weak ciphers, expired/self-signed/hostname-mismatched certs, and missing HSTS. These are standard, real findings.

Summary

TLS layers signatures and CA-issued certificates over a handshake to deliver confidentiality, integrity, and server authentication, then uses symmetric crypto for speed. Weak protocol/cipher/certificate configurations are common, reportable weaknesses.

Practice with these exercises