this post was submitted on 16 Dec 2024
362 points (97.9% liked)

Technology

60055 readers
2921 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 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 5 days ago (3 children)

So why can't I make my own cert? Give the caller my public key and on we go.

[–] [email protected] 5 points 5 days ago

You can distribute your public key, and have people manually add it to their trust stores.
But OSs and browsers ship with preloaded trusted certificates. This way, the owner of a preloaded trusted certificate can issue new certificates that are automatically trusted by people's OSs and browsers.
To become a preloaded trusted certificate owner, I imagine that there are stringent audits and security requirements. Part of that will be verifying the identity of the requester before issuing them a certificate.

With LetsEncrypt, they either need to talk to a server hosted at the domain to retrieve a token (generated when the request is initiated).
This proves the requester owns/controls the domain and the server (the requester has correctly set up DNS records, and placed the required token on the server). This is HTTP challenge mode.
The other method is by a DNS challenge. The requester adds a TXT record to their nameservers with the token value, letsencrypt then inspects the DNS records for the domain and will issue a cert when it sees the token. This proves the requester owns/controls the domain.

So, proving identity is required (otherwise anyone could generate a trusted cert for any domain). And trusted certificate issuers are required, so people don't have to constantly import (possibly dodgy) public keys

[–] [email protected] 5 points 5 days ago (1 children)

Give the caller my public key and on we go.

And how does the client validate that your public key is actually your public key and not some attacker's?

The idea of having a trusted 3rd party is to ensure that some impartial and trustworthy arbiter can confirm to the client that yes, this certificate is trustworthy, because they issued it to the correct party.

But you can absolutely self-sign a certificate. Works just fine, though not all clients accept self-signed certificates as trustworthy as anyone could have issued it.

[–] [email protected] 1 points 5 days ago (2 children)

Because they'll use it and it's I that verify by decrypting it with my private key? If someone makes him use a bad key then it just won't work.

[–] [email protected] 1 points 5 days ago (1 children)

How do they know you verified by decrypting?

The client has to be able to verify. They can't trust your result. Imagine a man-in-the-middle attack; if someone intercepted all traffic between you and the client, including the cert exchange, how would either party figure out that traffic was being intercepted?

Client connects to website, but gets intercepted. Attacker provides own self-signed certificate to client. Client asks you to verify the certificate, but attacker can intercept that too and just reply the certificate is "totes cool bro just trust me". You are none the wiser either, because the attacker can just decrypt client traffic and pretend they are the client by re-encrypting the data themselves.

With a Certificate Authority, the client can take the received cert and ask the CA "did you sign this?". The CA will then tell you they didn't, exposing the attacker's fake cert. This works, because the CA is already a trusted entity. That trust is being extended to your website's certificate validity and thus the website identity.

[–] [email protected] 1 points 5 days ago (1 children)

I see where you're getting at, or so I think:

A malevolent user takes over my website and installs his non-authorised certificate => danger!

But I mean he can use my certificate, it's already there, installed and set up to work?

[–] [email protected] 1 points 4 days ago* (last edited 4 days ago) (1 children)

If he fully takes over your website there's nothing you can do as a client to detect it. But that's not the point of the certificate. The certificate is there to ensure you are communicating with the website/server you think you're communicating with.

It ensures your communication is safe. In my example, the attacker doesn't take over your website, he takes over some part of the network infrastructure between your website and the client, thus intercepting all the traffic. There's a "man in the middle", e.g. the website is safe, the client is safe, but the communication between them is not. The certificate ensures nobody is impersonating the website by intercepting all the traffic, ensuring the communication.

If the website does get compromised, the CA has the option to invalidate the certificate at your request, via some verification procedure. Thus it also defends against compromised servers, though it's not the primary purpose for which they exist.

[–] [email protected] 1 points 4 days ago (1 children)

Okay, but (if the big ones didn't enforce it) a home made cert would also stop a man in the middle attack.

And if I figure it's compromised, I just deal with it through my hoster or on my home-lab server.

I just don't see why it should be a "trusted" entity in there at all. I know today it is how it works but I feel we could and should do away with it (in magic wonderland I guess :-)

[–] [email protected] 1 points 4 days ago (1 children)

Okay, but (if the big ones didn't enforce it) a home made cert would also stop a man in the middle attack.

It would not, because the "man in the middle" would simply provide their own, also self-signed certificate, to the client and the client would have no way of verifying that that certificate is not to be trusted. The client is unable to distinguish between your self-signed cert and the attacker's. That's why the CA is needed, to verify that the certificate is actually issued by whoever you think it is.

This is why browsers do not trust self-signed certificates. They can't verify who that "self" is. Doing away with it is a massive security vulnerability.

[–] [email protected] 2 points 4 days ago

Thanks for the explanation it does make sense.

[–] [email protected] 1 points 5 days ago (1 children)

Sure, but the first time the other person would have to accept your self signed cert. There is no knowing that the cert presented the first time was actually from you and not someone else.

[–] [email protected] 1 points 5 days ago (1 children)

How would that matter?

Say my website sends you my homemade cert, if you don't use it you cant communicate with me (or go unsecure).

Why myst some "trusted entity" emit tjose certificates? They are just a bunch of RSA keys!

[–] [email protected] 1 points 4 days ago* (last edited 4 days ago)

Because there is no difference from your homemade cert compared to anyone else's homemade cert.

So if someone else claims to be your website and uses a similar homemade cert there is no way to know that the site isn't yours.

[–] [email protected] 4 points 5 days ago

You can make your own cert. To make sure your cert belongs to you (your site) it is signed by authority and the client then may verify that authority (which cetificate is preinstalled in their system) in fact had verified ownership of your site and then signed your cert claims with their private key.