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.
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…
- be compelled by authority
- be compelled by threat
- be hacked
- have a lapse in ethics
- have a rogue employee
- etc.
…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.
I urge everybody to read up on CAA 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 CAA în DNS. It takes 5 minutes.
You can specify the valid CA in the form of its representative domain, for example to allow Let’s Encrypt you’d add 0 issue "letsencrypt.org". If you want to allow multiple CA you add multiple CAA records. They enter into effect if at least one CAA record is present. You can also restrict the challenge type, for example 0 issue "letsencrypt.org;validationmethods=dns-01".
Please note that this is worth adding a CAA record even if you don’t use your domain for HTTP and you don’t issue any certs for it, because a rogue CA can do it for you. You can add a blank CAA record (0 issue ";") which basically forbids any CA.
(And yes, this also applies to email. It’s worth adding restrictive records even if you don’t use your domain for email.)
They mean CAA records:
https://developers.cloudflare.com/ssl/edge-certificates/caa-records/
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.
Misbehaving or even simple errors are reasons for getting kicked out,
That can be helpful if a transgression is noticed, and it’s not orchestrated by a higher authority (e.g. government), and the damage isn’t already done.
browser builders are rather strict on the presence of the CAs they trust.
Of course, browser builders are vulnerable to influence, attack, accidents, questionable judgment, 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?
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.
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.
It is possible and it has been done.
You need to get your “hacker” key signed/certified by an official CA. Which is not that difficult with some of them because they are doing it for money.
You don’t really ‘need to’ in a world where a good proportion of people will happily click ‘continue anyway’ when they get any sort of certificate error
Thats why we have HSTS and HSTS preloading, so the browser refuses to allow this (and disabling it is usually alot deeper to find than a simple button to “continue anyways”)
people will happily click ‘continue anyway’
Not possible without a certificate. There will be no TLS connection, only an error message. No ‘click continue’.
It is trivial for an attacker to make self-signed TLS certs, and you can absolutely just click “continue” on sites that use them when you get a warning from the browser
As others have mentioned, a trusted 3rd party signs the correct key so your browser can check the key itself.
However, it should also be noted that your browser must have a list of trusted 3rd parties and their certificates used for signing in order to perform this check. It’s entirely possible to modify this list yourself. Some examples include:
- executing your own MITM style “*attack” in order to intercept and analyze local https traffic
- corporate network inspection and monitoring, where a gateway does the above for all devices on the network which have a CA cert pre-installed through some policy
So while it’s possible for trusted 3rd parties to issue valid certificates to bad actors, it’s also possible to add anyone (you, your employer, or some bad actors) to the trusted parties list.
So there are two things that certificates are for. You already understand the first one, which is the cryptography itself. You can use them to encrypt your traffic so that information sent over the connection is not in plain text.
The second thing certificates do, is the answer to your dilemma. Identification. For your browser to trust a website’s certificate, the certificate has to be valid for that website. What makes a certificate valid? The certificate has to have been signed by a trusted Certificate Authority, and the name on the certificate must match the website you’re visiting. If you were to ask “What makes a certificate authority trusted?” The answer is that your web browser and/or operating system come preloaded with certificates for trusted certificate authorities. These special certificates were used to sign the certificate of the website you’re visiting, which is another thing your browser checks for. A malicious third party can’t (easily) obtain a valid certificate/key pair for a domain that they don’t own. If your browser was presented with a fake certificate from the malicious third party, it would not connect and would warn you that your connection isn’t secure and would explain why.
Now if more specifically, you’re wondering that if a malicious third party takes any given website’s public certificate, can it use that to decrypt your session? After all, that public cert is signed and trusted. The answer to that, is that when a certificate is created, so too is a private key file created. This private key is never presented to the public, and it’s the only thing that can decrypt sessions that were encrypted by its paired public certificate. So that third party could install that certificate on a web server theoretically, but they wouldn’t actually be able to decrypt anything because they don’t have the private key for the legitimate certificate.
So in order for a man in the middle attack like this to work, they’d have to obtain not only a legit websites public certificate, but also the corresponding private key. OR, the third party would need to get access to your PC, and install its own certificate authority signing cert, so that it’s fake, self signed certificates are trusted by your browser. Both of these are possible, but at that point you’re not talking about an unknown man in the middle, the man would have to compromise one of the two ends.
It should also be mentioned that you can get a CA to sign your certificate just before your domain expires, so you can attack whatever website is going to buy your domain next
