this post was submitted on 21 May 2024
97 points (92.9% liked)

Technology

58012 readers
2962 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related content.
  3. Be excellent to each another!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, to ask if your bot can be added please contact us.
  9. Check for duplicates before posting, duplicates may be removed

Approved Bots


founded 1 year ago
MODERATORS
 

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.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 81 points 3 months ago* (last edited 3 months ago) (1 children)

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.

[–] [email protected] 59 points 3 months ago (5 children)

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.

[–] [email protected] 33 points 3 months ago* (last edited 3 months ago) (1 children)

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.)

[–] [email protected] 23 points 3 months ago

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.

[–] [email protected] 15 points 3 months ago (3 children)

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.

[–] [email protected] 6 points 3 months ago (1 children)

The certs are still valid.
They are just not implicitly trusted

[–] [email protected] 7 points 3 months ago

You are technically correct, best kind of correct

[–] [email protected] 2 points 3 months ago* (last edited 3 months ago) (1 children)

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.

[–] [email protected] 1 points 3 months ago

I agree, it’s far from perfect.

[–] [email protected] 1 points 3 months ago (2 children)

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?

[–] [email protected] 3 points 3 months ago

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.

[–] [email protected] 1 points 3 months ago

Not the browser companies. The parent CA would revoke Let's Encrypt's certs and publish that revocation in the certificate revocation list. When the browser (software, running on your system) downloads the new CRL, they will automatically stop trusting LE.

[–] [email protected] 2 points 3 months ago

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.