Transport Layer Security

When you see the padlock and 'https' in your browser, the thing doing the work is TLS. Picture it as a sealed, tamper-proof pipe laid between your device and a server, on top of the ordinary (and wide-open) Internet connection. Everything you send through the pipe is encrypted so eavesdroppers see gibberish, protected so any tampering is detected, and delivered to a server whose identity has been verified. TLS — the successor to the older SSL, whose name still lingers — is the protocol that builds that pipe.

It works in two phases. First the handshake: the client and server negotiate which cryptographic algorithms to use, the server presents its digital certificate (which the client verifies through PKI, confirming the server's identity and defeating a man-in-the-middle), and they use public-key cryptography to securely agree on a fresh shared symmetric session key — without ever sending it in the clear. Then the data phase: all application data (your HTTP requests, the web pages, form submissions) is encrypted with that fast symmetric key and protected with a MAC or authenticated-encryption, with sequence numbers to stop replay. The handshake gives confidentiality, integrity, and server authentication for the whole session.

Why it matters and what it does NOT promise: TLS sits between the application and TCP, so almost any protocol can run securely 'over TLS' — HTTPS is just HTTP over TLS, and there's secure email and more. It's the workhorse of Internet confidentiality. But be precise about its guarantees. TLS authenticates the server (and optionally the client) and secures the channel between the two endpoints — it does not vouch that the server is honest, that the website's content is safe, or that your data is protected once it arrives and is decrypted at the other end. A valid TLS connection to a phishing site is still a phishing site. TLS protects the pipe, not the people at its ends.