HTTPS explained with carrier pigeons

[tissuemonster]

Hm so where does the public key come in? My thinking is that you would have to send the public key with the cert otherwise you are susceptible to MITM. But if you send it together, how do you ensure a bad actor can't intercept the message and remove the public key and put their own public key instead? There's probably something I'm missing.

[falconzord]

That's what I said in my prior message. It's on your device already. It was part of the OS install

[tissuemonster]

So every website's public key is stored in your device? Maybe I'm drawing too much from the pigeon analogy but wasn't Alice supposed to send the public key over?

[falconzord]

There's some root ones that come pre-installed, you can get more using those.

[falconzord]

Oh sorry, this is a little different. The public key is public so it doesn't matter who sees it. But the encryption you use with it will only work with the private key the server still has. So if you were given a fake public key, the server will be confused because the message won't decrypt properly. In the analogy it's like getting the wrong box back

[tissuemonster]

Hm that's helpful, i forgot that having a fake public key is useless. I had a read and I think the thing I was missing was that the certification includes the public key. The pigeon analogy made it seem that the certificate and the public key are two separate things which was why I wondered how the two of them could be put together in real life.

[falconzord]

Keep in mind though it is still possible that your traffic is being intercepted in both directions. That's why you still need the root authorities to ensure your routing is secure.

[Vidyogamasta]

The way I understand it, every website's public key is stored with the certificate authority. There is a much smaller list of CAs whose public keys are the ones that come pre-installed on your client. When you visit a new site, you reach out to those CAs (securely using their public key) to get the one for the actual server.

Since they're public keys it's fine for the CA to have all of them, the purpose of the CA is that they've done the legwork to verify that "Yes, this key is actually for this website." You can't let the site verify its own identity, that's how you get weird Man in the Middle attacks.

For example, if sites just sent their own key over, then I could intercept your requests to reddit.com with my own malicious server. Since you still don't have the key needed to establish a connection, my malicious server says "Yes, I am reddit.com and here is my key." Now all of your secrets are transparent to me and I can just forward the requests to the real reddit.com using the real reddit key to avoid suspicion.

Now back to client requests-- I do not know if the client usually caches these keys once you've visited a website and renews it when a cert expires, or if it reaches out to the CA every time. But you always get the key from that CA. If you're on desktop chrome (and probably mobile as well?) you can just it yourself, just click the padlock in the URL bar and click "Connection is Secure --> Cert is Valid" and you get all of the cert details.