What Is HTTPS and TLS?

You have probably noticed the little padlock icon next to a website’s address, and you may already know it means the connection is “secure.” But what is actually happening behind that padlock? When you type a password into a login form and hit submit, something has to scramble that password so nobody between your laptop and the server can read it. That something is TLS, and HTTPS is just plain old HTTP riding on top of it.

This article goes one level deeper than the usual “HTTP vs HTTPS” explanation. We will look at what TLS really does, how the famous “handshake” works in plain terms, what a certificate is and who hands them out, and — importantly — exactly which parts of your traffic get encrypted and which parts do not. No cryptography math required.

HTTPS Is Just HTTP Plus a Lock

Let’s clear up the relationship first, because the names are confusing.

HTTP (HyperText Transfer Protocol) is the language your browser and a web server use to talk: “give me this page,” “here is the page,” “here is the form data,” and so on. By itself, HTTP sends everything as plain text. Anyone who can see the network traffic — someone on the same coffee-shop Wi-Fi, your internet provider, a malicious router along the way — can read every word.

HTTPS is the exact same HTTP conversation, but placed inside a secure, encrypted tunnel. The “S” stands for “Secure,” and that security is provided by a separate protocol called TLS.

So the layering looks like this:

+---------------------------------------+
|  HTTP   (the actual request/response) |
+---------------------------------------+
|  TLS    (encrypts + verifies it)      |
+---------------------------------------+
|  TCP/IP (delivers the bytes)          |
+---------------------------------------+

HTTP does not change at all. TLS simply wraps it. That is why you sometimes hear HTTPS described as “HTTP over TLS.”

What TLS Actually Promises

TLS is not one feature; it quietly delivers three guarantees at once. Keeping these straight makes everything else easier to understand.

That third one is the part people forget. Encryption alone is not enough — if you encrypt a conversation with an impostor, you have only kept your secrets safe while handing them to the wrong person. TLS solves this with certificates, which we will get to shortly.

The TLS Handshake, Step by Step

Before any web page or password is sent, the browser and server have a short setup conversation called the handshake. Its job is to agree on how to encrypt things and to confirm the server’s identity. Here is the conceptual flow — the real protocol has more detail, but the shape is this:

Browser (you)                              Server (example.com)
     |                                              |
     |  1. "Hello" — here are the cipher methods    |
     |     I support, and a random number.          |
     |--------------------------------------------->|
     |                                              |
     |  2. "Hello back" — I pick a method, here's   |
     |     my random number AND my certificate.     |
     |<---------------------------------------------|
     |                                              |
     |  3. I check the certificate is valid and     |
     |     trusted. Then we exchange keys so we     |
     |     both end up with the SAME secret key.    |
     |<-------------------------------------------->|
     |                                              |
     |  4. Done. From here on, everything is        |
     |     encrypted with that shared secret key.   |
     |=============== encrypted ====================|

Let’s unpack each step in human terms.

Step 1: Hello

The browser opens by introducing itself. It says, in effect, “Hi, I want a secure connection. Here are the encryption methods (called cipher suites) I know how to use, and here is a random number to help us generate keys later.”

Step 2: The Server Replies With Its Certificate

The server answers, picks one encryption method that both sides support, adds its own random number, and — crucially — sends its certificate. The certificate is a digital ID card that says “I am example.com, and here is proof.” We will look at what is inside it in the next section.

Step 3: Key Exchange

Now both sides need to end up holding the same secret key without ever sending that key across the network in the clear (because anyone watching could grab it). Modern TLS uses clever math (a key-exchange algorithm) that lets both parties combine their pieces and independently arrive at the identical shared key. An eavesdropper who sees every message exchanged still cannot compute that key.

This shared key is called a session key, and it is temporary — it exists only for this one connection.

Step 4: The Encrypted Channel

With the shared session key in hand and the certificate verified, the secure tunnel is open. Every HTTP request and response from this point forward is encrypted with that session key. The browser shows the padlock, and your actual browsing begins.

Certificates and Certificate Authorities

A certificate is the heart of the “authentication” promise. Think of it like a passport for a website. A passport is only trustworthy because a government you trust issued it and stamped it. A TLS certificate works the same way.

What’s Inside a Certificate

A certificate is a small file that contains, among other things:

• The domain name it is valid for (for example, acy-partner.com).
• The website’s public key (one half of a key pair; the matching private key stays secret on the server).
• An expiry date — certificates are only valid for a limited time.
• A digital signature from the organization that issued it.

That last item is what makes it trustworthy.

Who Issues Them: Certificate Authorities

A Certificate Authority (CA) is a trusted organization whose entire job is to verify that a website really controls a domain, and then to issue and sign a certificate for it. Your browser and operating system ship with a built-in list of CAs they trust — this is called the trust store.

The chain of trust looks like this:

Root CA (trusted by your browser)
   |
   |  signs
   v
Intermediate CA
   |
   |  signs
   v
example.com's certificate

When the server hands over its certificate during the handshake, your browser checks the signatures up this chain. If the chain leads back to a CA your browser already trusts, and the domain matches, and it hasn’t expired, the certificate is accepted. If anything is off — wrong domain, expired, or signed by nobody your browser trusts — you get that scary “Your connection is not private” warning.

This is also why you should never click past certificate warnings on a site where you enter sensitive data. A warning means TLS could not confirm you are talking to the real server.

What Gets Encrypted — and What Doesn’t

Here is a detail that surprises a lot of developers. TLS encrypts the contents of your HTTP traffic, but not every piece of information about the connection is hidden.

Encrypted (hidden from anyone in the middle):

• The full URL path and query string — for example, /account/settings?tab=billing.
• All HTTP headers, including cookies and authentication tokens.
• The request and response bodies — form data, passwords, JSON, the HTML of the page, images, everything.

Not encrypted (still visible to your network/ISP):

• The domain name you are connecting to (e.g. acy-partner.com). Historically this leaks through a part of the handshake and through DNS lookups.
• The server’s IP address, since the network needs it to route your packets.
• The rough size and timing of the traffic.

So an observer on your network can see that you visited acy-partner.com, but not which page you looked at, what you typed, or what came back. A useful mental model:

Visible to the network:   "Someone connected to acy-partner.com"
Hidden by TLS:            the page, the path, headers, cookies,
                          your password, and the response body

Why Developers Should Care

If you build anything for the web, TLS is no longer optional. Browsers mark plain HTTP pages as “Not Secure.” Many modern browser features (geolocation, service workers, the clipboard API, and more) simply refuse to run on non-HTTPS pages. Search engines also prefer secure sites.

The good news is that, as a developer, you rarely implement TLS yourself. Your web server, hosting platform, or a CDN handles the handshake and encryption for you. Your main job is to obtain and install a valid certificate and keep it from expiring — and these days, tools issue and renew certificates automatically and for free.

Recap

Let’s pull the pieces together:

• HTTPS is ordinary HTTP placed inside an encrypted tunnel. The tunnel is provided by TLS (the modern replacement for SSL).
• TLS delivers three things at once: encryption (privacy), integrity (tamper detection), and authentication (proof of identity).
• The handshake is a quick setup conversation: hello, the server presents its certificate, both sides agree on a shared session key, and then everything is encrypted.
• A certificate is a website’s digital ID, issued and signed by a trusted Certificate Authority. Your browser checks the chain of trust before it trusts the site.
• TLS hides the path, headers, cookies, and bodies, but the domain and IP you connect to are generally still visible.

Once this clicks, the natural next question is the practical one: how do you actually get a certificate onto your own site, what types exist, and how does renewal work? That is exactly the territory of SSL certificates and hosting — a great topic to explore next, now that you understand what the certificate is doing in the first place.