TLS/SSL — Secure Communication on the Web

TLS is the protocol that makes it possible to trust a website. Every time the browser shows the padlock in the address bar, TLS is working in the background to ensure that nobody can read or alter data in transit.

1. From SSL to TLS: History and Vulnerabilities

SSL versions (1994–1996)

Secure Sockets Layer (SSL) was created at Netscape to protect e-commerce transactions in the early 1990s.

• SSL 1.0: Never publicly released — it contained critical flaws discovered internally.
• SSL 2.0 (1995): First public version. It had serious structural weaknesses: the ability to perform downgrade attacks on the negotiated algorithms and no protection against connection truncation.
• SSL 3.0 (1996): A complete redesign. It remained in use for almost twenty years, but in 2014 the POODLE attack (Padding Oracle On Downgraded Legacy Encryption) exposed a fundamental flaw in how it handled padding in CBC mode. RFC 7568 prohibited its use in 2015.

The TLS era (1999–present)

In 1999 the IETF standardised the protocol as Transport Layer Security (TLS), maintaining structural compatibility with SSL 3.0 but correcting its weaknesses.

TLS 1.3 represents a clear break: it eliminated dozens of weak algorithms accumulated over the preceding twenty years and redesigned the handshake to reduce latency and improve privacy by default.

2. TLS Architecture

TLS sits between the application layer and the transport layer (TCP):

The protocol is organised into two superimposed layers.

TLS Record Protocol (lower layer)

This is the engine of the protocol: it handles everything that happens to data before it descends to TCP.

For each block of application data it performs in sequence:

1. Fragmentation into records of at most 16 KB.
2. Compression (removed in TLS 1.3 — it was exploited by the CRIME attack).
3. Encryption + authentication of the record with the negotiated session key.
4. Addition of the record header (type, version, length) and transmission over TCP.

Upper-layer sub-protocols

Four sub-protocols operate above the Record Protocol:

3. The Three Pillars: Confidentiality, Integrity, Authentication

HTTPS is simply HTTP carried inside a TLS tunnel. The fundamental difference from plain HTTP:

• Confidentiality: data is encrypted with symmetric cryptography (AES, ChaCha20). Even if someone intercepts the traffic, they see only ciphertext.
• Integrity: every record includes an authentication code. If even a single byte is altered in transit, the recipient detects it and closes the connection.
• Authentication: the server proves its identity via a digital certificate signed by a trusted CA. The client knows with certainty that it is talking to the correct server and not an impersonator (man-in-the-middle).

4. Message Authentication Code (MAC) and AEAD

The integrity problem

Encryption alone is not enough: an attacker who cannot read the data might still be able to modify it in a targeted way (bit-flipping attacks). MAC solves this.

How MAC works

$$\text{MAC} = \text{HMAC}(\text{secret_key},\ \text{message})$$

The sender computes the MAC of the message and appends it. The receiver recomputes the MAC on the received message and compares: if they do not match, the message was altered or the key is wrong. In TLS the MAC uses HMAC (Hash-based MAC) with functions such as SHA-256 or SHA-384.

AEAD in TLS 1.3

TLS 1.3 has abandoned the separate “encrypt-then-authenticate” model in favour of AEAD (Authenticated Encryption with Associated Data): a single algorithm that encrypts and authenticates in one step, eliminating an entire class of vulnerabilities related to the order of operations.

The two mandatory AEAD cipher suites in TLS 1.3:

• AES-128-GCM — hardware-accelerated (AES-NI) on modern CPUs
• ChaCha20-Poly1305 — optimal on devices without AES-NI (mobile, IoT)

5. X.509 Digital Certificates and the Chain of Trust

Structure of an X.509 certificate

A certificate is a digitally signed document that binds a public key to an identity. The main fields:

Certificate types

• DV (Domain Validated): verifies only that the applicant controls the domain. Issued in minutes (e.g. Let’s Encrypt). Sufficient for most websites.
• OV (Organization Validated): also verifies the legal existence of the organisation. More expensive and slower.
• EV (Extended Validation): in-depth identity verification. Used by banks and institutions.

The Certificate Chain

No browser trusts a website’s certificate directly. Trust propagates through a chain:

Root CAs (e.g. DigiCert, Sectigo, ISRG for Let’s Encrypt) are pre-installed in the operating system and browser — this is the Trust Store. The browser walks the chain from the leaf upwards until it finds a Root CA it recognises. If the chain is valid and no certificate is expired or revoked, the connection is considered secure.

Certificate revocation

If a private key is compromised, the certificate must be revoked before its expiry date. The two mechanisms:

• CRL (Certificate Revocation List): a periodic list of revoked certificates published by the CA. Effective but bulky.
• OCSP (Online Certificate Status Protocol): the browser queries the CA in real time for the status of a single certificate. OCSP Stapling shifts this verification to the server, which attaches the already-signed OCSP response to its certificate during the handshake, eliminating an additional round-trip.

6. Cipher Suites

A cipher suite is the combination of four algorithms that client and server agree to use for a session:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 │     │     │        │           │
 │     │     │        │           └── Hash for HMAC/PRF
 │     │     │        └────────────── Symmetric cipher + mode
 │     │     └─────────────────────── Authentication algorithm
 │     └───────────────────────────── Key exchange algorithm
 └─────────────────────────────────── Protocol

Forward Secrecy (FS)

Forward Secrecy (or Perfect Forward Secrecy, PFS) guarantees that compromising the server’s private key in the future does not allow an attacker to decrypt traffic recorded today.

Without FS (RSA key exchange): the pre-master secret is encrypted with the server’s public key. Anyone who records the traffic today and steals the private key tomorrow can retroactively decrypt everything.

With FS (ECDHE — Ephemeral Elliptic Curve Diffie-Hellman): session keys are generated fresh for every connection using ephemeral DH parameters that are destroyed immediately afterwards. There is no cryptographic material that enables post-session decryption.

TLS 1.3 has mandated Forward Secrecy by removing static RSA and DH from key exchange.

Cipher Suites in TLS 1.3

In TLS 1.3 the cipher suite specifies only the AEAD cipher and the hash function (key exchange is always ECDHE):

7. The TLS Handshake

TLS 1.2 — 2-RTT Handshake

Client                                          Server
  │                                               │
  │── ClientHello ────────────────────────────────▶│
  │   (TLS versions, cipher suites, Client Random) │
  │                                               │
  │◀─ ServerHello ─────────────────────────────────│
  │   (chosen version, cipher suite, Server Random)│
  │◀─ Certificate ─────────────────────────────────│
  │   (server's X.509 certificate)                 │
  │◀─ ServerKeyExchange ───────────────────────────│
  │   (ECDHE parameters)                           │
  │◀─ ServerHelloDone ─────────────────────────────│
  │                                               │
  │── ClientKeyExchange ──────────────────────────▶│
  │   (client's ephemeral ECDHE public key)        │
  │── ChangeCipherSpec ───────────────────────────▶│
  │── Finished (hash of all messages) ────────────▶│
  │                                               │
  │◀─ ChangeCipherSpec ─────────────────────────────│
  │◀─ Finished ─────────────────────────────────────│
  │                                               │
  │◀══════════ Encrypted Application Data ═════════▶│

This scheme requires 2 round-trips (2-RTT) before data can flow. Both sides independently compute the pre-master secret via ECDH, from which they derive symmetric session keys using a pseudo-random function (PRF).

TLS 1.3 — 1-RTT Handshake

TLS 1.3 has optimised the handshake by removing redundant messages and bringing the ECDH exchange forward:

Client                                          Server
  │                                               │
  │── ClientHello ────────────────────────────────▶│
  │   (versions, cipher suites, key_share ECDHE)   │
  │                                               │
  │◀─ ServerHello ─────────────────────────────────│
  │   (cipher suite, server's key_share ECDHE)     │
  │◀─ {Certificate} ───────────────────────────────│  ← already encrypted
  │◀─ {CertificateVerify} ─────────────────────────│
  │◀─ {Finished} ──────────────────────────────────│
  │                                               │
  │── {Finished} ─────────────────────────────────▶│
  │                                               │
  │◀══════════ Encrypted Application Data ═════════▶│

Key differences from TLS 1.2:

• The client sends ECDH parameters already in the ClientHello: the server can derive session keys and encrypt its response before the second round-trip.
• The certificate and Finished travel already encrypted — a passive attacker cannot even see which certificate the server is using.
• 0-RTT (Early Data): if client and server have connected before, TLS 1.3 allows sending application data in the very first message, eliminating handshake latency. It has limitations however: it is not protected against replay attacks, so it should only be used for idempotent operations (e.g. HTTP GET).

8. Practical Tools

Inspect a certificate with OpenSSL

# Connect and view the certificate
openssl s_client -connect example.com:443 -showcerts

# Decode a .pem certificate
openssl x509 -in certificate.pem -text -noout

# Check the negotiated cipher suite and TLS version
openssl s_client -connect example.com:443 -tls1_3

Test a server’s TLS configuration

# Show the TLS version and cipher suite in use
curl -vI https://example.com 2>&1 | grep -E "TLS|cipher|issuer"

# Force TLS 1.2 to check compatibility
curl --tlsv1.2 https://example.com

What to look for in the browser

In any modern browser: open DevTools (F12) → Security tab (Chrome) or Privacy & Security → click “View Certificate” to see:

• The negotiated TLS version
• The cipher suite in use
• The full certificate chain
• Validity dates and fingerprint

Conclusions

TLS is transparent to the end user, but its correctness depends on configuration decisions made by the server administrator. The critical points to keep in mind:

• Use TLS 1.3 wherever possible; retain TLS 1.2 only for compatibility with legacy clients.
• Enable only cipher suites with Forward Secrecy (ECDHE).
• Keep certificates up to date — Let’s Encrypt provides free certificates with automatic renewal via ACME.
• Periodically verify the configuration with tools such as SSL Labs (assigns an A/B/F grade to a public server’s TLS configuration).