TLS offloading by a dummy

ILB stands for Life Boat

I mean, ofc not literally (duh). But I often like to imagine an LB as a lifeboat for my requests: to which island (i.e. server) it should be directed, whether the weather is stormy or not (health monitors), or if there is no island left after all (bad gateway).

In a nutshell, a load balancer balances load (genius). But there are some terms to keep in mind that helped me sound educated enough :p. They are as follows:

Octavia: Used for providing the load-balancing service.
Barbican: Stores secrets, i.e. keys.
Neutron: The networking service from OpenStack. Responsible for subnets and security groups.
Amphora: Octavia's default way of implementing a load balancer. It boots a small VM running HAProxy.
Keystone: Identity / auth token service.

A good thing to keep in mind is that a load balancer is a specific function that a proxy can perform. A reverse proxy is a role.

Now, these are mostly jargon. But then, jargon sells. The key idea that I kept in mind while building TLS offloading is that the LB is a lifeboat with desperate requests on it, trying to reach their server.

Now the question was: how would my lifeboat know where to lead these requests?

IIIf you know, you know

Before we actually get into TLS offloading, we need to understand a very pretty idea: the Diffie–Hellman algo. I have created a visualisation for it that you can find here. It has some really beautiful mathematics that allows us to telepathically agree on a key. A basic version of it is here:

Diffie–Hellman as paint: mixing is easy, un-mixing is not — so both sides end up with the same colour, and it never once crossed the wire.

The maths, gentlyp = 23, g = 5 — two strangers, one secret

public · everyone sees this

bothp = 23, g = 5a prime, and a base

private · never leaves home

alicepicks a = 4

bobpicks b = 3

exchange · sent in the open

aliceA = g^a mod p5⁴ mod 23 = 625 mod 234

bobB = g^b mod p5³ mod 23 = 125 mod 2310

shared secret · computed, never sent

alices = B^a mod p10⁴ mod 23 = 10000 mod 2318

bobs = A^b mod p4³ mod 23 = 64 mod 2318

Why they match: B^a = (g^b)^a = g^ab = (g^a)^b = A^b (mod p). An eavesdropper sees p, g, A and B — getting s means digging a or b back out (the discrete log problem). Trivial for 23. Hopeless for a 2048-bit p.

The key idea to keep in mind is that Diffie–Hellman solves the problem of encrypting data, and not identity. A person in the middle (called the man in the middle) can impersonate the server you are talking to. And just like any other situationship, there is no way to know what you mean to the person :p

DH will happily complete two handshakes — one with you, one with the server. It hands you a secret, not a name.

IIIRSA: Real Shit Algorithm

One of the most gratifying experiences I had was learning about the RSA algorithm (and no, its full form is not Real Shit. It's Rivest–Shamir–Adleman). It's an asymmetric encryption algorithm that allows our browser to verify the certificate and the certificate chain, and ultimately solves the problem of identity.

RSA relies on a very beautiful theorem by Euler:

You can check out the proof here. But this very idea — being able to decrypt a hash signed by a private key, and then individually compare and verify the hash — is the very foundation of TLS.

Hash it, sign the hash with the private key — and anyone holding the public key can check the two hashes match.

I have added a simple derivation of how RSA works below.

RSA, derived with tiny numbersp = 3, q = 11 — keys, encrypt, decrypt, sign

1 · make the keys

pickp = 3, q = 11two primes — kept secret

n = pqpublic33

φ(n) = (p − 1)(q − 1)= pq − p − q + 1 = 2 · 1020

publice: 1 < e < φ(n), gcd(e, φ(n)) = 1shares no factor with 207

privated: e·d ≡ 1 (mod φ(n))7 · 3 = 21 = 20 + 13

2 · encrypt & decrypt

encryptc = m^e mod nm = 4 → 4⁷ mod 33 = 16384 mod 3316

decryptm = c^d mod n16³ mod 33 = 4096 mod 334 ✓

3 · why it works

c^d = (m^e)^d = m^ed

ed = 1 + k·φ(n)that's exactly how d was picked

m^ed = m · (m^φ(n))^k ≡ m · 1^k = m (mod n)Euler: m^φ(n) ≡ 1

4 · flip it around → a signature

signsig = h^d mod nhash h = 5 → 5³ mod 33 = 125 mod 33 · only the private key can26

verifysig^e mod n26⁷ mod 33 · anyone with the public key can5 = h ✓

Toy numbers, obviously — real keys use primes hundreds of digits long, which is what makes factoring n back into p and q hopeless. (Strictly, Euler needs gcd(m, n) = 1; the result holds for every m anyway — that bit's in the proof.)

IVGive me a certificate

I think I deserve a certificate for writing this article and making the visualiser, if I'm being honest. And so thinks every domain on the internet. Think of a certificate as your Aadhaar card. And you only trust an Aadhaar card because it is signed by the Government of India (or whoever signs that white plastic). CA certs work the same way: a chain of trust and validity which, if broken at any point, is easily detectable (due to our beloved RSA), and moreover prevents the man-in-the-middle attack (and situationships and identity crises).

For a better visualisation of the chain, you can visit my visualiser (cool stuff onli).

Checking starts from the bottom up — each signature is verified with its issuer's public key, until you reach a root your browser already trusts.

VThe final rescue

Once the TLS handshake is done and the DH keys are exchanged, our humans (requests) are able to talk to the lifeboat (LB) and can inform it where they want to be headed. Finally, they have a common language, and voila — my requests are saved.

One round trip of handshake; after that the LB decrypts, picks a member, and forwards plain HTTP. That's the offloading.

Honestly, it was one of the more interesting pieces of work that I had the fortune of implementing, and more importantly, I got a much deeper understanding of how the S in HTTPS actually works. Super fun stuff. I highly recommend you check it out and play around with it on your own.

VIScratchpad

As usual with anything I make, a lot of pages were filled with ideation, proofs, and wrapping my head around stuff. A couple of pages from that.

Notebook outline for this article: LB as a lifeboat, if you know you know, why I don't have a certificate, RSA, my guides, photos. — From the notebook — the outline, paint mixing, Diffie–Hellman, the RSA derivation, and the certificate chain.

Paint-mixing sketch of the encryption technique (B+Y, Y+O, Y+O+B) and the Diffie–Hellman public values g^a mod p and g^b mod p. — From the notebook — the outline, paint mixing, Diffie–Hellman, the RSA derivation, and the certificate chain.