Most people know the feeling, even if they do not know the protocol. You type a URL, hit Enter, and within a fraction of a second the browser shows a page with a padlock and a secure connection. It feels simple.

It is not simple.

Before the first real page bytes arrive, your browser and a server it has never met before have to agree on cryptographic parameters, derive fresh shared keys, decide which application protocol comes next, and give the browser enough proof that it is talking to the right machine. They do all of that fast enough that most people never notice it happened.

Most people also call all of this "SSL." The web does not run on SSL anymore. It runs on TLS.

This is the no-code version of the story. If you want the message-by-message breakdown after this, read Inside a TLS 1.3 Handshake: From ClientHello to Encrypted HTTP.

First, untangle the names

The easiest way to get lost in this topic is to start with the names, because the internet still uses old ones.

SSL was the older family of secure transport protocols. It is obsolete. When people say "SSL certificate" or "SSL termination," they almost always mean the certificate or termination point used by TLS.

TLS is the protocol the web actually uses now. It is the successor to SSL and the thing that protects most web traffic in transit.

HTTPS is not a different application protocol from HTTP. It is ordinary HTTP carried over a TLS connection.

That is the first mental model worth keeping:

HTTP is still the language of the request and response.
TLS is the security layer underneath it.
HTTPS is just those two things together.

What standard matters today

If you want the short answer first, here it is:

• TLS 1.3 is the modern standard
• TLS 1.2 is still widely supported for compatibility
• TLS 1.0, TLS 1.1, and every version of SSL are obsolete

That means most modern systems prefer TLS 1.3 and fall back to TLS 1.2 only when they need to talk to something older.

Why did TLS 1.3 become the default? Not because it is newer for the sake of being newer. It became the default because it is faster, simpler, and less willing to carry old baggage. It removed a lot of features that made earlier versions harder to reason about and easier to misuse.

What TLS is actually trying to prevent

Imagine a normal network path between your browser and a server. There are routers, proxies, Wi-Fi networks, load balancers, maybe a corporate firewall, and plenty of points where traffic can be observed or tampered with.

Without TLS, three bad things are possible:

• someone can read the traffic
• someone can modify the traffic
• someone can pretend to be the server

TLS exists to stop those three things. That maps directly to the three properties engineers care about:

• Confidentiality: outsiders should not be able to read the data
• Integrity: outsiders should not be able to change the data without detection
• Authentication: the client should be able to verify the server's identity

That is the whole job. Everything else in TLS is detail in service of those goals.

The handshake, without the ceremony

The cleanest way to understand TLS 1.3 is to think of the handshake as a short negotiation with five jobs:

1. agree on which protocol details to use
2. derive fresh shared secrets
3. prove the server's identity
4. confirm the handshake was not tampered with
5. start sending normal HTTP through an encrypted channel

That sounds abstract, so here is the plain-English version.

1. The client says what it supports

The browser starts with a ClientHello.

This is the browser saying: here are the TLS versions I understand, here are the algorithms I support, here is the hostname I want, here is the application protocol I would like next, and here is my key agreement material so we can move quickly.

That last part is important. In TLS 1.3, the client sends key agreement material immediately. That is one reason the protocol can complete a new connection in one round trip.

2. The server picks the connection parameters

The server responds with ServerHello.

This is the server saying: here is the version we are actually using, here is the cipher suite we are actually using, and here is my side of the key agreement.

At that point, both sides have enough information to derive shared secret material locally.

That is a subtle but important point. The connection secrets are not shipped across the network as a final blob. They are derived independently by both sides from exchanged public material and their own private values.

3. The connection starts getting protected before the handshake is over

This is where many explanations become misleading.

TLS 1.3 does not leave the whole handshake in the clear and then turn on encryption at the very end. Once the early negotiation is done, the rest of the handshake moves under encryption.

So the handshake has two phases:

• a small early plaintext phase
• a later encrypted phase

That design makes the protocol feel both faster and cleaner than older mental models suggest.

4. The server proves who it is

Once the later part of the handshake is protected, the server sends its certificate chain and proves it controls the private key behind that certificate.

This is the part many people flatten into "the certificate makes it secure," but that is not quite right.

The certificate is about identity. It tells the browser which public key belongs to which hostname according to a trust chain. The server then has to prove it actually holds the matching private key.

So the browser checks things like:

• does this certificate match the hostname I asked for?
• does the trust chain lead to a root I trust?
• is the certificate currently valid?
• did the server prove possession of the corresponding private key?

If those checks fail, the browser should not trust the connection.

5. The handshake finishes and HTTP begins

After both sides confirm they derived the same state and saw the same handshake transcript, the connection is ready for application data.

For the web, that means something very ordinary happens next: normal HTTP starts flowing.

That is the part people often miss. HTTPS is not "a special kind of web request." It is just normal HTTP carried inside a channel TLS has already secured.

What certificates do, and what they do not do

One of the most persistent misunderstandings in this area is the role of certificates.

A certificate does not create the secrecy of your session by itself.

What it actually does is bind a public key to an identity. In the web case, that usually means binding a public key to a hostname, with a certificate authority acting as part of the trust chain.

The secrecy of the session comes from the handshake's key agreement and the traffic keys derived from it.

The certificate answers:

"Who is this server supposed to be?"

The key agreement answers:

"How do we derive fresh secrets for this connection without sending them directly?"

Those are different jobs. TLS works because it keeps them separate and composes them carefully.

What TLS hides, and what it does not

TLS gives people a strong sense of privacy, which is justified, but it is easy to overstate what it hides.

Once the secure channel is established, TLS protects the contents of the application data in transit. For HTTPS, that means it protects things like:

• request paths after the hostname
• headers
• cookies
• form data
• API payloads
• HTML, JSON, images, and other response bodies

But TLS does not make the connection invisible.

An observer can still usually learn things like:

• the client IP address
• the server IP address
• the destination port
• connection timing and duration
• rough traffic volume and packet sizes
• often the hostname via SNI, unless newer protections such as ECH are in use

That is the second mental model worth keeping:

TLS protects the contents of the conversation. It does not fully hide the existence or broad shape of the conversation.

Why TLS 1.3 won

TLS 1.3 became the standard because it made several good engineering decisions at once.

It reduced latency

A full new handshake can complete in one round trip, which matters on real networks because every extra round trip shows up in user-facing latency.

It made forward secrecy the default

Modern TLS uses ephemeral key exchange, which means that if a server's long-term private key is stolen later, that alone should not let an attacker go back and decrypt old recorded sessions.

That property matters much more than most people realize.

It removed old complexity

Older TLS versions accumulated too many legacy features, negotiation branches, and risky options. TLS 1.3 got better partly by saying "no" to more of that history.

That is often what good systems design looks like in practice: not adding more knobs, but removing the dangerous ones.

The mental model worth keeping

If you only want the version you can carry around in your head, keep this one:

The client starts by describing what it supports and sending key agreement material.
The server chooses the parameters, sends its own key agreement material, and proves its identity.
Both sides derive fresh shared keys.
They confirm the handshake transcript.
Then normal HTTP flows inside an encrypted TLS channel.

That is what happens before a browser shows a secure page.

A few takeaways worth remembering

• SSL is dead terminology for a live problem space
• TLS is the protocol the web actually uses
• HTTPS is just HTTP over TLS
• TLS 1.3 is the modern default; TLS 1.2 is still the compatibility layer
• certificates prove identity, not secrecy
• the session keys are derived during the handshake, not transmitted directly
• TLS protects application data well, but some network metadata is still visible

If you want the next layer down, the deeper article walks through the TLS 1.3 handshake message by message and explains why the protocol is shaped the way it is.

SSL, TLS, and HTTPS: What the Web Actually Uses

People still say "SSL," browsers talk about secure connections, and websites advertise HTTPS. Those terms get blurred together, so the most useful place to start is with a correction:

• SSL is obsolete
• TLS is the protocol the web uses now
• HTTPS is just HTTP carried inside TLS

When you open an HTTPS page, your browser and a server it has never met before need to agree on cryptographic parameters, derive fresh shared keys, and establish trust quickly enough that the whole thing feels invisible.

This write-up is a no-code explanation of how that works. The goal is not to implement TLS, but to give you the mental model that makes the modern web click.

If you want the next layer down after this primer, read tls-13-handshake-deep-dive.md.

If you remember one sentence, remember this:

TLS 1.3 lets a client and server agree on fresh shared keys, lets the server prove its identity, and then carries ordinary HTTP inside an encrypted and authenticated channel.

SSL, TLS, and HTTPS

SSL

SSL was the older family of secure transport protocols. It is dead.

SSL 2.0 and SSL 3.0 are obsolete and should never be used. When people say "SSL certificate" or "SSL termination," they usually mean the certificate or termination point used by TLS. The name stuck, even though the protocol did not.

TLS

TLS is the successor to SSL and the protocol that secures web traffic today.

The versions that matter are:

• TLS 1.3: the modern standard and the preferred choice
• TLS 1.2: still widely supported for compatibility
• TLS 1.0 and TLS 1.1: obsolete

So when someone asks what the standard is now, the short answer is: TLS 1.3 is the current standard, and TLS 1.2 is the compatibility fallback.

HTTPS

HTTPS is not a different application protocol from HTTP.

It is plain HTTP sent over a TLS connection. The methods, headers, status codes, cookies, and body formats are still HTTP. TLS sits underneath and protects those bytes while they move across the network.

That means the mental stack is simple:

HTTP handles the web request and response.
TLS secures the connection carrying that request and response.

Why TLS exists

Without TLS, anyone between the client and the server can do three dangerous things:

• read the traffic
• modify the traffic
• pretend to be the server

TLS exists to stop those three things. That maps to three core properties:

• Confidentiality: other people should not be able to read the data
• Integrity: other people should not be able to change the data without detection
• Authentication: the client should know it is really talking to the intended server

That is the whole job. Every handshake message exists to establish one or more of those properties.

What standard matters now

If you want the shortest useful answer, it is this:

The web runs on TLS 1.3 when both sides support it. TLS 1.2 is still common because the internet has a lot of old software and hardware.

TLS 1.3 became the standard because it is:

• faster, by reducing the full handshake to one round trip
• safer, by removing older features and weak negotiation paths
• cleaner, by making the protocol smaller and easier to reason about
• more modern, by making forward secrecy the default

Older versions accumulated too much historical baggage. TLS 1.3 is the result of years of learning from what went wrong before.

The handshake in plain English

The best way to understand TLS is to treat the handshake as a short conversation with a few specific goals:

1. agree on how to talk
2. derive fresh shared secrets
3. prove the server's identity
4. confirm the handshake was not tampered with
5. start encrypted HTTP

That is what a modern TLS 1.3 handshake does.

How TLS 1.3 actually works

1. The client starts with ClientHello

The client opens by saying what it supports.

This message includes things like:

• the TLS versions it can speak
• the cipher suites it supports
• the hostname it wants to reach
• the application protocol it wants, such as HTTP/1.1 or HTTP/2
• an ephemeral key share for key agreement

That last part matters a lot. In TLS 1.3, the client sends key agreement material immediately. This is one reason the protocol is faster than older TLS handshakes.

At this stage, the connection is not encrypted yet. An observer can still see that a handshake is happening and can still learn some connection metadata.

2. The server replies with ServerHello

The server responds by choosing the parameters for the connection.

This message says, in effect:

• here is the TLS version we will use
• here is the cipher suite we will use
• here is the server's key share

Now both sides have enough information to derive shared secrets.

The important point is that the session secret is not sent over the network as a blob for the other side to read. Each side computes it locally using its own private value and the other side's public value.

That is one of the key ideas behind TLS: the connection keys are derived, not transmitted.

3. Encryption starts before the handshake is fully finished

After ServerHello, TLS 1.3 derives handshake keys.

From this point onward, the rest of the handshake is encrypted. That means the later server messages are already protected even though the client has not started sending normal HTTP yet.

This is a useful detail because many people imagine the entire handshake as a long public introduction. In reality, only the early hello messages are plaintext. A substantial part of the handshake is already under encryption in TLS 1.3.

4. The server proves identity

Once encryption is in place for the rest of the handshake, the server sends its certificate chain and proves it controls the private key behind that certificate.

This is what certificates are for: identity.

The certificate does not perform the encryption for your web session. It tells the client, "this public key belongs to this name," and the server then proves it holds the matching private key.

The client checks several things:

• does the hostname match the certificate?
• is the certificate chain anchored in a trusted certificate authority?
• is the certificate currently valid?
• does the server's cryptographic proof verify?

If these checks fail, the connection should not be trusted.

5. The client confirms with Finished

The client then sends its own Finished message.

This confirms that it derived the same keys, saw the same handshake transcript, and agrees the secure connection is established.

At that point, both sides are ready to exchange application data.

For HTTPS, that means normal HTTP starts flowing through the encrypted TLS channel.

What is actually encrypted, and when

One of the most useful questions to ask about TLS is not just "is it encrypted?" but "what is encrypted at each stage?"

In TLS 1.3:

• the initial ClientHello is plaintext
• the initial ServerHello is plaintext
• the later handshake messages are encrypted
• the HTTP request and response are encrypted once the secure channel is established

So TLS does not make the existence of a connection disappear. It protects the application data and part of the handshake, not the fact that a handshake is happening.

Why TLS 1.3 won

TLS 1.3 is not important just because it is the newest version. It matters because it intentionally removed a lot of older complexity.

The protocol got better in a few important ways.

It is faster

A full handshake can complete in one round trip, which reduces latency for new connections.

It makes forward secrecy the default

Modern TLS uses ephemeral key exchange, which means a stolen long-term server key should not let an attacker go back and decrypt old recorded sessions.

That property matters a lot on the public internet.

It removes risky legacy behavior

Older TLS versions accumulated too many options, old cipher modes, fallback paths, and sharp edges.

TLS 1.3 reduced that surface area. That makes implementations simpler and leaves less room for old classes of mistakes.

It is easier to reason about

A smaller protocol with fewer moving parts is easier to implement correctly and easier for engineers to understand operationally.

That is a big part of why TLS 1.3 became the standard rather than just another version number.

The most common misunderstanding

The easiest way to misunderstand TLS is to blur together identity and secrecy.

These are separate jobs:

• the certificate answers: "Who is the server?"
• the key exchange answers: "How do we derive fresh secrets safely?"
• the record protection answers: "How do we encrypt and authenticate the data?"

TLS works because it keeps those jobs separate and composes them carefully.

That is also why this statement is so important:

A certificate proves identity. It does not create the session's secrecy by itself.

What TLS protects and what it does not

TLS protects the contents of the application data in transit.

For HTTPS, that means it protects things like:

• URLs after the hostname
• headers
• cookies
• form data
• API payloads
• HTML, JSON, images, and other response bodies

But TLS does not make network traffic invisible.

An observer can still usually learn:

• the client IP address
• the server IP address
• the port number
• connection timing and duration
• approximate traffic volume and packet sizes
• often the destination hostname via SNI, unless newer protections like ECH are used

So TLS gives you confidentiality and integrity for the application data, not perfect anonymity.

The whole picture in one mental model

If you want a compact explanation you can keep in your head, use this:

The client begins by saying what it supports and sending key agreement material.
The server chooses the parameters, sends its own key agreement material, and proves its identity with a certificate and signature.
Both sides derive fresh shared keys.
They confirm the handshake transcript.
Then ordinary HTTP flows inside an encrypted TLS channel.

That is what happens before the padlock appears in the browser.

What to remember

• SSL is obsolete terminology; the live protocol is TLS
• HTTPS is HTTP over TLS
• TLS 1.3 is the modern standard
• TLS 1.2 still exists mainly for compatibility
• the certificate proves identity, not secrecy
• the session keys are derived during the handshake, not sent directly
• after the handshake, the HTTP traffic is normal HTTP carried inside encrypted TLS records

If the goal is simply to understand the modern web, that is enough. Everything else in TLS is detail built on top of this core model.