What is the difference between SSL and TLS?

SSL (Secure Sockets Layer) was the original protocol, designed by Netscape in 1994. The IETF standardized a successor as TLS (Transport Layer Security) in 1999, and every version since has been TLS. SSL 3.0 was definitively broken by the POODLE attack in 2014; modern browsers refuse to negotiate anything below TLS 1.2 today. The phrase 'SSL certificate' lingered in marketing copy because changing the language was harder than upgrading the protocol — but everything you call 'SSL' in 2026 is really TLS.

Can someone on my Wi-Fi see what I am doing on an HTTPS site?

They can see which sites you are visiting (because SNI and IP addresses are visible on the wire), and they can see the size and timing of your packets, but they cannot read the content of your requests or the response data. That is enough for a coffee-shop snoop to know you spent half an hour on a banking site, but not enough to steal your password or read your messages.

Does HTTPS protect me against a malicious website?

Only partially. HTTPS proves the website is who its domain name says it is — that a fraudulent server cannot impersonate the bank's domain. It does not vouch for the trustworthiness of the operator. A phishing site can have a perfectly valid HTTPS certificate; the certificate authority verified that the attacker controls the lookalike domain, nothing more.

Why do I need to pay for an SSL certificate?

Mostly you do not. Let's Encrypt issues free domain-validated certificates that are cryptographically identical to the ones a paid CA would sell you. Paid certificates buy higher liability insurance, an Extended Validation badge (which browsers no longer display prominently), or warranty terms enterprises need for compliance. For typical websites the free option is the right call.

What is ECH and do I need it?

Encrypted Client Hello is a TLS extension that encrypts the Server Name Indication, so a passive observer on the wire cannot see which specific hostname you are reaching at a multi-tenant edge IP. Cloudflare rolled it out at scale in 2023; Firefox enabled it by default in 2024. You do not configure it yourself — if both your browser and the destination CDN support it, it just happens. It defeats casual SNI-based censorship and bulk site-fingerprinting.

TLS and HTTPS, in plain English — what the padlock icon actually means

The three jobs TLS does

Every secure HTTPS connection sits on top of the TLS protocol. TLS performs three functions, all at the same time, all during a brief negotiation at the start of the connection:

Authentication. The server presents a certificate signed by a Certificate Authority your browser already trusts. The browser verifies the chain back to a root CA stored in its trust store. If the chain doesn't verify (or the hostname doesn't match the certificate), the connection fails before any data is exchanged.
Confidentiality. Both sides derive a fresh symmetric key during the handshake. After that, every byte of HTTP traffic is encrypted under that key. An observer on the wire — your ISP, the coffee-shop router, a state-level firewall — sees only ciphertext.
Integrity. Every encrypted record carries an authentication tag (in modern AEAD ciphers like AES-GCM and ChaCha20-Poly1305, the tag is built into the encryption). If anyone modifies a single bit in transit, the tag fails to verify and the connection aborts. The receiver doesn't see corrupted data — they see no data and an error.

The TLS 1.3 handshake, step by step

TLS 1.3 (RFC 8446, finalized in 2018) is the version every modern browser and CDN now uses by default. Its biggest change over TLS 1.2: the handshake takes one round-trip instead of two, which alone takes about 50 ms off every cold connection across the Atlantic.

ClientHello. Your browser sends the server: a list of TLS versions it supports, a list of cipher suites it can use, key-share values for the elliptic curves most likely to be picked (so the key exchange can happen in this round-trip), and — in the SNI extension — the hostname it wants to talk to. SNI exists because many servers host multiple TLS sites on the same IP and need to know which certificate to present.
ServerHello + Certificate + Finished. The server picks one cipher suite, sends back its certificate chain, derives the same session keys from the client's key-share, and signs the handshake transcript to prove it owns the certificate's private key. All in one flight of packets.
Client Finished. Your browser verifies the certificate chain back to a trusted root, verifies the server's signature, and sends a final "Finished" message (also encrypted). From this point on, every byte is encrypted application data — the actual HTTP request can ride on the same flight of packets if the browser is feeling ambitious.

With 0-RTT (zero round-trip) session resumption, repeat visits skip the handshake entirely: the browser sends the first HTTP request encrypted under keys derived from a previous session ticket, before the server has acknowledged anything. The trade-off is slightly weaker replay protection — 0-RTT data is only safe for idempotent requests like GET.

What an attacker on the wire can and cannot see

People often assume HTTPS hides everything. It doesn't. The TLS handshake leaves several pieces of metadata visible by design:

The IP address you're talking to. The IP header is on the outside of the TLS envelope. An observer sees that you're connected to 104.16.x.x (Cloudflare) — they just don't know which of the millions of sites behind that IP you're using.
The hostname (via SNI). Until ECH ships everywhere, the SNI extension in ClientHello reveals the hostname in plain text — even though the rest of the handshake is private. An on-path observer can read example.com from your ClientHello before any encryption begins.
Packet sizes and timing. Even when the content is encrypted, the sequence and size of packets leaks structural information. A skilled adversary can tell that you're streaming video versus loading a static page, that you typed something into a form, or that you fetched a page of a specific length.
Connection metadata. The TCP three-way handshake, the QUIC handshake (for HTTP/3), the time of the connection — all of it is in plain view.

What an observer cannot see (assuming the cryptography holds): the URL path, the query string, the request headers, the request body, the response status, the response body, any cookies, any auth tokens. Everything inside the encrypted tunnel is opaque.

SNI, ECH, and the privacy frontier

SNI is the obvious leak. Encrypted Client Hello (ECH) — the successor to the earlier ESNI proposal — wraps the entire ClientHello (including SNI) in a second layer of encryption keyed to a public key the CDN publishes in DNS. The outer ClientHello says only "I'm talking to the Cloudflare front"; the inner ClientHello (which the CDN can decrypt) carries the real hostname.

Practical impact: an observer at your ISP sees that you connected to a Cloudflare IP and exchanged some HTTPS traffic, but they cannot tell which of the millions of sites behind that IP you reached. This defeats casual SNI-based censorship in countries that filter on hostname (Iran, Russia, China at varying levels of sophistication) and neutralizes a class of bulk site-fingerprinting tools at ISPs.

Cloudflare turned on ECH at scale in 2023, Firefox enabled it by default in 2024, and Chrome shipped experimental support through Origin Trials. As of 2026 it's the default for a significant fraction of the web, with the rest catching up.

Why the certificate authority system matters so much

The whole authentication story rests on Certificate Authorities. Your browser trusts a list of about 130 root CAs out of the box; any of them, if compromised, can issue a certificate that fraudulently identifies any domain. That happened in 2011 with DigiNotar (compromised, issued fake Google certs, the CA was removed from every browser within a month) and several times since at smaller scales. The infrastructure around the CAs is what keeps the system honest:

CAA records in DNS. You publish a CAA record that says "only Let's Encrypt and DigiCert can issue certificates for this domain." Every compliant CA must check the CAA record before issuance; if they issue against the policy, they have committed a logged misissuance. Check yours with our DNS tool.
Certificate Transparency. Every issued certificate must be logged to at least two append-only public logs. You can monitor your own domains (via tools like crt.sh) for any certificate ever issued naming them. If something unexpected appears, it's evidence of a misissuance and you can get the CA in trouble.
HSTS preloading. Browsers ship with a list of domains that have committed to HTTPS-only. For sites on the list, the browser refuses to connect over HTTP even on a first visit. Add your domain via hstspreload.org.

The cipher suite story

A cipher suite bundles together the choices the protocol makes: how to do key exchange, how to authenticate, how to encrypt. TLS 1.3 dramatically simplified this — there are only five standard suites, all using AEAD ciphers, all with forward secrecy:

TLS_AES_128_GCM_SHA256 — fast, good default.
TLS_AES_256_GCM_SHA384 — for the paranoid; not measurably more secure but the math goes to 11.
TLS_CHACHA20_POLY1305_SHA256 — preferred on mobile (faster without hardware AES support).

Compare to TLS 1.2's 37+ suites, many of which had subtle vulnerabilities (BEAST, Lucky 13, FREAK, Logjam, etc.). TLS 1.3 removed the bad options entirely. Use the TLS / SSL checker to see which suite a given site negotiates.

Common confusions, cleared up

SSL vs. TLS

SSL 3.0 was definitively broken by POODLE in 2014. TLS 1.0 followed in 2020. Modern browsers won't negotiate anything below TLS 1.2; TLS 1.3 is the current state of the art. "SSL certificate" is a marketing artifact — what you're buying is a TLS certificate.

Port 80 vs. 443

Port 80 is plain HTTP. Port 443 is HTTPS (HTTP over TLS). Modern sites redirect 80 → 443 and add HSTS so the browser remembers to use 443 directly on future visits. New protocols like HTTP/3 ride on top of UDP/443 instead of TCP/443 but still terminate TLS the same way.

Free vs. paid certificates

Cryptographically identical. Paid CAs buy you organization-validated or extended validation (which browsers no longer display prominently), warranty terms enterprises need for compliance, and (sometimes) better support. For the vast majority of websites, free Let's Encrypt certificates renewed automatically by Caddy or Certbot are the correct choice. IPFerret runs on exactly that setup.

How to inspect a site's TLS yourself

IPFerret's SSL / TLS checker — paste a hostname, get back the cert chain, protocol version, cipher, ALPN protocols, HSTS, and a grade.
Command line: openssl s_client -connect example.com:443 -servername example.com -showcerts prints the entire handshake including the certificate chain in PEM form.
DNS lookup for the CAA record — see which CAs the domain owner permits.
SSL Labs — the industry-standard exhaustive scan, slower but very thorough.

TLS / HTTPS, in plain English