So this video explains how https works. What I don’t get is what if a hacker in the middle pretended to be the server and provided me with the box and the public key. wouldn’t he be able to decrypt the message with his private key? I’m not a tech expert, but just curious and trying to learn.
All TLS/HTTPS clients have a set of Certificate Authority keys which they trust. Your client will only accept a public key which is signed by a trusted CA’s key. A proper CA will not sign a key for a domain when it has not verified that the entity that wants it’s key signed actually controls the domain.
Most browsers trust many certificate authorities from all over the world.
Any of them could…
…and yes, it has happened already.
HTTPS as most of us use it today is useful, but far from foolproof. This is why various additional measures, like certificate pinning, private CAs, and consensus validation are sometimes used.
This is slightly off-topic but I was thinking about it and all of thoes isues can be solved by utilizing blockchain. Imagine a world where instead of CAs, decentralized domain (unstoppable domains, ENS etc.) owners publish their pub keys to the blockchain, the client can than query multiple nodes or store the chainstate locally. When establishing a connection client sends a secret handshake message + clients’ pub key encrypted with domains’ pub key. To complete the handshake server responds with the same secret message encrypted with clients’ pub key.
How are you ensuring the public key retrieved from the blockchain is legitimate?
You’re just removing the semi trustworthy CA and replacing it with the less trustworthy blockchain. Unless you’re proposing encrypting the blockchain connection, maybe they could use TLS?
It seems to me like a MITM hacker can just redirect all requests to a Blockchain node towards their malicious node.
I urge everybody to read up on CA records in DNS and add them to your domains. They basically say what CA the certs for that domain are supposed to come from. Even if another CA issues valid certs for the domain they would be rejected if they don’t match the CA în DNS. It takes 5 minutes.
They mean CAA records:
https://developers.cloudflare.com/ssl/edge-certificates/caa-records/
Right, I’ll fix it.
Thats why we now have certificate transparency reports and CA-records.
Sure not perfect, but at least with a compliant CA it wont just happen in the dark.
At some point you have to trust someone.
Many years ago I manually removed all CAs from my trust store and only added those I needed. Turned out that from roughly 160 trusted root CAs I needed about 10 to 12. I stopped because it often was very difficult to figure out which CA signed the cert for an app that was failing. The final nail in the coffin was when I was late for a business meeting and the only way to get a parking space close enough to my destination was by paying with an app I’d never used before and finding the right root CA under pressure was too much. I really wish we had more and easier control over who we trust.
It is indeed true that some CAs have seriously misbehaved; however, browser builders are rather strict on the presence of the CAs they trust. Misbehaving or even simple errors are reasons for getting kicked out, after which certificates signed by those CAs are now no longer valid.
The certs are still valid.
They are just not implicitly trusted
You are technically correct, best kind of correct
That can be helpful if a transgression is noticed, and if it’s not orchestrated by a higher authority (e.g. government), and if the damage isn’t already done.
Of course, browser builders are vulnerable to influence, attack, accidents, and blind spots just as certificate authorities are.
I’m somewhat skeptical. What if LetsEncrypt decided to misbehave tomorrow? Would the browsers have the guts to shut it down and break all sites using it?
Yes, they will. We’ve seen it before in mostly less serious cases: Diginotar, Türktrust, Symantec, etc. As brittle as the CA system can be, when there is real enough trouble, CAs do get revoked.