Skip to content
SteveTechArcSteveTechArc Courses

How Strangers Agree on a Key

Module 5 of 7 in the shared chapter Keys, Certificates and Trust, chapter 3 of Securing Salesforce: Identity and Access and chapter 12 of Integration Architect. Each module stands on its own.

The question this module answers: How do a browser and a server that have never met agree on a secret key, in plain sight of the bandits, in a fraction of a second?

Everything comes together

Section titled “Everything comes together”

Every time you click a link that starts with https, your browser and the server do a quick dance together before a single page arrives. It’s called the TLS handshake, and it’s the plumbing of the internet. It happens everywhere, all day, and it takes a fraction of a second.

It also uses everything from this chapter so far:

  • A shared key (module 1): one key, both sides, for fast encryption. The problem was getting it to the other side.
  • Two keys (module 2): a public key anyone can have and a private key that never leaves home.
  • A signature (module 3): proof of who sent something, and that nobody changed it.
  • A certificate and its chain (module 4): proof of whose public key it is.

The handshake puts them in order. Let’s watch your browser meet Steve’s Plumbing.

The two hellos

Section titled “The two hellos”

The browser goes first. It says hello, and with it sends:

  • the versions of TLS it can speak, and the algorithms it can use;
  • a random number it just made up;
  • its half of a key, called a key share. More on that in a moment.

Steve’s Plumbing answers with its own hello:

  • the version and algorithm it picked from the browser’s list;
  • its own random number;
  • its own key share.

Two messages, one each way. Back and forth, like a tennis match.

The same key, made on both sides

Section titled “The same key, made on both sides”

Here’s the part that surprises people. The browser and Steve’s Plumbing now each make the same session key, and neither of them ever sends it.

How? The experts found mathematics for this, too. Each side keeps a secret number to itself, and sends only a public half made from it: the key share. Each side then combines its own secret with the other side’s public half. Both arrive at exactly the same key. And someone who sees both public halves, but neither secret, can’t work it out. It’s called a Diffie-Hellman key exchange, after two of the people who published it. You don’t need the mathematics; you need to know what it gives you.

Now think about the bandits. They’re on the road, copying everything, as always. They copy both hellos, both random numbers, both key shares. And they still don’t have the key, because the key was never on the road.

That’s module 1’s problem, solved. Both sides have the key, and nobody else does.

The TLS 1.3 handshake Three areas from left to right: the browser, the network (the road) and Steve's Plumbing. In the first frame, both sides say hello: the browser sends the versions and algorithms it can use, a random number and its key share; Steve's Plumbing sends its choice, its own random number and its key share. Both hellos cross the network in the open. In the second frame, each side makes the session key from its own secret and the other side's key share, and both get the same key; the bandits copy both key shares but still can't make the key, because it never crossed the road. In the third frame, Steve's Plumbing proves who it is: it sends its certificate and signs the handshake with its private key; the certificate, the intermediate and the signed handshake cross the network; the browser checks the chain up to its root store and the signature with the certificate's public key, and the check passes. In the last frame, the conversation begins, locked with the session key: fast, one key, for this conversation only. Underneath: the session key is made on both sides and never sent; the certificate and the signature prove who the server is; then the conversation uses that key, once. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-05", "id": "DGM-IAM-TR-08", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "cells 0.5.0", "theme": "stevetecharc 1.4.0"} THE BROWSER THE NETWORK: THE ROAD STEVE'S PLUMBING 1. Hello the versions and algorithms it can use · a random number · its key share 1. Hello its choice · its own random number · its key share The two hellos random numbers and key shares, in the open 2. Makes the session key its own secret + Steve's Plumbing's key share 2. Makes the session key its own secret + the browser's key share: the same key The bandits copy both key shares, and still can't make the key: it never crossed the road 3. Proves who it is sends its certificate · signs the handshake with its private key Certificate and signature the certificate, the intermediate, and the signed handshake 3. Checks the chain, up to its root store · the signature, with the certificate's public key 4. The conversation locked with the session key · fast, one key, this conversation only sends sends sends arrives The session key is made on both sides and never sent. The certificate and the signature prove who the server is. Then the conversation uses that key, once. HOW TO READ IT the two ends the same session key, made on both sides the bandits the check passes the conversation: locked with the session key © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

Proving it’s really Steve’s Plumbing

Section titled “Proving it’s really Steve’s Plumbing”

Wait. The browser now shares a key with someone. But is it really Steve’s Plumbing, or a bandit pretending to be?

So Steve’s Plumbing does two more things, and you know both of them already:

  1. It sends its certificate, with the intermediate certificate (module 4).
  2. It signs the handshake so far with its private key (module 3): everything both sides have said, hashed and locked with the gold key.

The browser checks the certificate’s chain up to a root in its own list. Then it checks the signature with the public key inside that certificate. If both pass, only the real Steve’s Plumbing could have taken part in this handshake, because only Steve’s Plumbing holds that private key.

Then each side sends a short finished message, locked with the new key. It’s both sides saying: I’m good, let’s switch over.

Switch to the session key

Section titled “Switch to the session key”

From here on, every message in the conversation is locked with the session key and a fast, one-key algorithm, AES or ChaCha20 from module 1’s table. The slow two-key mathematics did its job in the handshake and steps aside.

And that session key is used for this one conversation only. It’s never been used before, and it will never be used again. The next time your browser visits Steve’s Plumbing, they shake hands again and make a brand-new one.

In TLS 1.3, the version you want today, all of this takes a single round trip: one message out, one message back, and the conversation can start.

Why the old handshake was retired

Section titled “Why the old handshake was retired”

If you’ve seen this explained before, you may have seen it a different way, with the browser making a secret and sending it to the server locked with the server’s public key. That was the older RSA key exchange, and for years most of the web used it. It works. So why change?

Go back to module 1 and the bandits’ pile of copies. They keep everything, for years. With the old exchange, the secret behind every conversation crossed the road, locked with the server’s public key. So if the server’s private key is ever stolen, even years later, the bandits can open every secret in the pile, and with it every conversation they ever recorded.

With TLS 1.3, the session key never crosses the road at all. Stealing the private key later lets someone pretend to be the server from then on, which is bad, but it opens nothing from the past. That property has a name: forward secrecy. Yesterday’s conversations stay locked even if tomorrow’s key is stolen.

That’s why TLS 1.3 removed the old exchange entirely. In the words of the TLS 1.3 standard, “all public-key based key exchange mechanisms now provide forward secrecy.”

The names changed along the way, too. SSL is the old name; TLS is the new one. You’ll still hear people say “SSL certificate” and “SSL connection”. TLS 1.0 and 1.1 are now formally retired as well. Every protocol, like every algorithm, has a date it leaves.

On Salesforce

Section titled “On Salesforce”

Salesforce has said where it stands, in its own words. It “strongly recommends transitioning to TLS 1.3.” TLS 1.2 “will remain supported, as it meets the requirements for Perfect Forward Secrecy.” And it will “still support RSA key exchanges for all incoming TLS connections”, while noting they “can affect the security and efficiency” of your connections.

So, as an architect, look at the systems on both sides of every integration: the ones calling into Salesforce, and the ones Salesforce calls out to. Can they use TLS 1.3? If not, are they on TLS 1.2 with a forward-secret key exchange? Or are they still on the old RSA exchange, and if so, what’s the plan to move?

A safe road: trust at the channel level

Section titled “A safe road: trust at the channel level”

At this point, it’s tempting to say trust only goes one way. That’s not quite right. Look at what the handshake has given us. Your browser knows it’s really talking to Steve’s Plumbing. Steve’s Plumbing knows someone is at the other end, sharing a session key nobody else has, with forward secrecy. That’s trust at the channel level.

I like to picture it as a road. The handshake builds a safe freeway between the two ends, and nothing that travels on it can be read or changed on the way. What the road doesn’t tell you is who’s driving.

That’s the next layer’s job. Once you’re on the freeway, the application asks who you are. You sign in: a password and a second factor through the front door (the Front Door chapter), single sign-on, or an OAuth flow when an app is acting for you. So Steve’s Plumbing does learn who you are. It learns it at the application level, inside the channel, not in the handshake. Ordinary TLS is one-way only at the transport level. Once you sign in, each side knows who the other is.

Most of the time, that’s how it works, and it’s enough. But the freeway can lead to two kinds of places. It can be an open road, where any browser, anywhere, can arrive and then sign in. Or it can be a private road between two partners who already know each other, where the server wants to know which machine is calling before it shows anything at all: before a sign-in page, a username or a password. For that, the client has to prove who it is in the handshake itself. That’s two-way TLS, and it’s module 6.

What an architect decides here

Section titled “What an architect decides here”
  • TLS 1.3 by default; TLS 1.2 with forward secrecy at the least. Plan to move anything still on the old RSA exchange.
  • The session key is never sent, and never reused. That’s what keeps yesterday’s conversations safe.
  • The channel and the sign-in are two layers. TLS makes the road safe; the sign-in, or an OAuth flow, says who’s on it. Decide whether the road must also prove the client before anyone signs in (module 6).
  • The handshake depends on the certificate. An expired or untrusted certificate stops it cold (module 7).
  • Know every connection’s version, on both sides. Old protocols retire on a date, and the systems that use them have to move.

Explore

Section titled “Explore”

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.