TLS
Transport Layer SecurityTLS is the envelope the web travels in. Before any data flows, client and server run a handshake to agree on keys and check the server’s certificate, and from then on every byte is encrypted, tamper-evident and bound to who they’re talking to — it is the S in HTTPS.
TLS turns a plain connection into a private, verified channel — agree on keys once, then encrypt everything after.
Open the HTTPS lab →
Send a password over port 80 and read it off the wire. Then send the same request over TLS 1.3: its content turns opaque while IPs, size, timing and sometimes the hostname remain visible.
How it works
Both sides mix their key shares into the same secret without ever sending it. The certificate proves the server is who it claims — then every record after is sealed.
What TLS does, step by step
Over an open TCP connection, both sides agree a TLS version and cipher suite and trade random values.
The server sends a certificate chain; the client checks it against a trusted CA and the hostname.
An ephemeral (ECDHE) key exchange lets both compute the same secret — giving forward secrecy.
Application data flows as authenticated, encrypted records — sessions can resume to skip the full handshake.
In cybersecurity
TLS is the web’s baseline defence — but its security rests on the certificate chain being validated, and old versions and weak ciphers quietly undo the whole guarantee.
Skip the chain, expiry or hostname check and an attacker’s certificate sails through unnoticed.
A meddler forces the connection onto an old version or weak cipher it can break — disable them.
Ephemeral keys mean a stolen server key can’t decrypt yesterday’s recorded traffic.
Corporate proxies and attackers alike intercept TLS — certificate pinning narrows who’s trusted.
Lapsed or wrongly issued certificates break trust; automation (ACME) and CT logs keep them honest.
TLS hides traffic in transit — it says nothing about whether the server itself is malicious.