Why TLS matters

Why it matters

The padlock in the address bar is one of the most misunderstood symbols on the internet. People read it as "this site is safe". It actually means something narrower and very important: the connection between you and this server is private and has not been tampered with, and the server proved it owns this name. Knowing exactly what TLS (Transport Layer Security) does and does not promise is basic knowledge for anyone defending systems.

What TLS protects

TLS sits between TCP and the application protocol (HTTP, SMTP, IMAP and many others). It provides three things for data in transit:

1. Confidentiality. After the handshake, traffic is encrypted with a symmetric key that only the two ends know. Someone on the same café Wi-Fi sees scrambled bytes.
2. Integrity. Every record carries an authentication tag. If anyone changes a single bit on the way, the receiver detects it and drops the connection.
3. Server authentication. The server presents a certificate: its public key plus its domain name, signed by a certificate authority (CA) that your browser or operating system already trusts. The server proves it holds the matching private key during the handshake.

How certificate trust works

A certificate is checked as a chain:

Root CA (preinstalled in your OS or browser trust store)
  └── Intermediate CA (signed by the root)
        └── www.example.com certificate (signed by the intermediate)

The client checks that each signature is valid, that the chain ends at a trusted root, that the certificate has not expired, and that the name in the certificate matches the name you typed. If any check fails, the browser shows a full-page warning. That warning is TLS doing its job.

You can look at a certificate yourself:

openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null \
  | openssl x509 -noout -subject -issuer -dates

The output shows who the certificate is for (subject), who signed it (issuer) and when it is valid (notBefore, notAfter). In a browser, clicking the padlock shows the same details.

The attack TLS stops: on-path interception

In an on-path attack (often called man-in-the-middle), the attacker sits between the victim and the server, for example with a fake Wi-Fi hotspot or by poisoning ARP or DNS on a local network. Without TLS they can read and change everything: passwords, session cookies, the downloaded file.

With TLS, the attacker can still intercept the traffic, but:

• They cannot read it, because they do not have the session keys.
• They cannot change it without detection, because of the integrity tags.
• They cannot pretend to be the server, because no trusted CA will sign a certificate for bank.example to them. Their only option is to present a fake certificate, and the browser warns loudly.

This is why clicking through certificate warnings is dangerous, and why disabling certificate checks in code is one of the most common serious mistakes:

# Never do this in real code: it turns off server authentication.
requests.get("https://api.example.com", verify=False)

With verify=False the encryption is still there, but you no longer know who you are encrypting to, so an on-path attacker can simply present their own certificate.

A related trick is SSL stripping: the attacker keeps the victim on plain HTTP and talks HTTPS to the server themselves. The defence is HSTS (Strict-Transport-Security header), which tells the browser to use HTTPS for that site every time, and the HSTS preload list built into browsers.

What TLS does not protect

Versions and settings

Use TLS 1.2 or 1.3 only. SSL 2.0/3.0 and TLS 1.0/1.1 are deprecated because of known weaknesses. TLS 1.3 removed old, weak options and made the handshake faster. Free certificate authorities such as Let's Encrypt, with automatic renewal, have removed most excuses for running sites without TLS. Expired certificates still cause many outages, so monitor expiry dates.

Organisations sometimes run TLS inspection proxies that decrypt and re-encrypt traffic to scan it, using a company root certificate installed on managed devices. It is a legitimate security tool on company equipment with clear policy, but it also concentrates risk in the proxy.

Common mistakes

• Reading the padlock as "trustworthy site". It means "private connection to the owner of this name".
• verify=False or "accept any certificate" in code, often added to silence an error during testing and never removed.
• Mixed content: an HTTPS page loading scripts over HTTP, which lets an attacker change those scripts.
• Forgetting internal services. Traffic between your own servers crosses networks too; encrypt it.

Quick recap

• TLS gives confidentiality, integrity and server authentication for data in transit.
• Trust comes from certificate chains ending at a CA in your trust store, plus a name match and a valid date.
• TLS defeats on-path attackers only if certificate checks stay on; HSTS stops downgrade to HTTP.
• It does not stop phishing, compromised endpoints, application bugs, or exposure of data at rest and metadata.