If you're looking for parts 1, 2 or 3 you can find them here, here and here. If you've already read through the three and are okay with your innocence being shattered, let's move on and understand...
What's the deal with TLS?
So you chose the red pill. Well you've been warned!
Remember everything I told you about Alice, Bob & Eve? This's the part where it all breaks down. Heartbreaking, I know. Just when it seemed like there might be a twist...
(Source: https://www.reddit.com/r/ProgrammerHumor/comments/8v3mqy/is_this_cryptography_meme_relatable_to_programmers/)
The ugly truth is that servers don't care about Alice, Bob or Eve; they just want to talk to their mail clients. When the mail client XYZ says realBob@xyzmail.com is Bob, the servers assume it's true. What the servers do question is if the mail client claiming to be XYZ is, in fact, XYZ.
So to answer question 3 from the last section (the one you conveniently forgot), Alice doesn't need to know Bob's public key. Instead, we operate with a chain of trust like the following:
Alice and her mail client ABC trust each other
Mail client ABC and server group S trust each other
Server group S and mail client XYZ trust each other
Mail client XYZ and Bob trust each other
And that's how Alice, mail client ABC, server group S, mail client XYZ and Bob all come to trust each other. And vice versa.
The mail clients trust Alice & Bob because they logged in with some authentication (password, biometrics etc.). Bob and Alice trust the mail application because of the URL address they came to (www.gmail.com, not www.fakegmail.com).
The trust between mail clients and server groups though, is enabled via third party agencies called Certificate Authorities and the Transport Layer Security (TLS) we'd mentioned earlier.
The idea behind TLS is to establish a secure connection between two parties, such as server group S and mail applications ABC or XYZ. Secure as in making sure:
Mail client ABC / XYZ is what it claims to be
Server S is what it claims to be
No one else can listen to a conversation between ABC / XYZ and S
A secure connection is established via a process called a TLS handshake. Once established, any following data exchange is assumed to be secure. The handshake works via a framework called Public Key Infrastructure (PKI), which's one word away and heavily reliant on Public Key Cryptography (PKC).
TLS Handshake
If I were to oversimplify the TLS handshake, it'd be something like this:
Client ABC initiates contact with server, establishes some rules of engagement for the conversation to follow.
Server S responds with its digital certificate and few other details. The certificate includes a public key K, is issued by a Certificate Authority (CA) and confirms that the public key K belongs to server S.
Client ABC checks if the certificate is valid (involves checking the digital signature with the CA's public key) to confirm that public key K belongs to server S.
But now client ABC, as paranoid as it is, needs to make sure it's talking to server S and not another server that got hold of S's certificate. To do so, it presents a challenge - it encrypts something using the public key K from the certificate and asks the server to decrypt using its private key.
If server S is able to decrypt the message, it means it has the private key corresponding to public key K. Which means it is... <drumroll> the real slim server S!
And that's just half of it. Server S is equally paranoid, so it mets out the same treatment to client ABC. By the end of it, both of them are sure they're who they claim to be (phew!)
To be more scary and precise, the exchange looks like this:
(Source: https://www.ibm.com/docs/en/ibm-mq/7.5?topic=ssl-overview-tls-handshake)
Now that client ABC and S can talk, ABC sends the mail to S.
Next, client XYZ goes through the same process while trying to fetch the mail from server S.
Sounds like an overkill doesn't it? But better safe than sorry...
(Source: https://medium.com/@agu3rra/tls-handshake-a-secretive-way-to-say-hello-9c72f8b97ca3)
You might have noticed that a lot of steps above bank on trusting CAs. Since we've been sufficiently paranoid to trust no one else so far, you might wonder...
What's so special about Certificate Authorities (CAs)?
Why do we trust a certificate from a Certificate Authority (CA)?
Well we don't really have a choice. I mean, you have to start somewhere and CA's act as the first link in the chain. CA's certify other entities (Intermediate CAs), which certify other entities (Servers). There are different validation levels and related (elaborate) certification processes, but that's a story for another time.
While we put our trust in CAs as a source, validating identity remains one of the biggest problems on the internet...
(Source: https://xkcd.com/1121/)
...in most situations.
And here ends the story. But with that epic conclusion, we also come to the most important question of them all:
Why did I tell you all this, really?
To get you warmed up for my next post on Verifiable Credentials (VCs). And because this's way too long to cover there.
Comments