Comment by kelnos
Comment by kelnos a day ago
Pretty sure most people's threat model doesn't really care about the scenarios you mention. And for most people, that's fine.
Comment by kelnos a day ago
Pretty sure most people's threat model doesn't really care about the scenarios you mention. And for most people, that's fine.
But if you distrust the entire PKI ecosystem, how are you intending to use your email server?
If someone is trying to send you an email, their admin definitely isn't going to set up an in-person meeting with you to exchange certificate signatures. Their server is either going to accept any certificate (which means MitM is trivial), or they're going to verify it against PKI (which you don't use because you don't trust it) and abort the connection upon seeing a self-signed certificate.
It's the same if you're sending a reply back: if you're not willing to trust PKI, your server has no way of verifying the recipient's server's identity. You don't trust PKI, and they are not going to manually exchange signatures, so your options are either not sending email at all, or accepting that it is MitMed.
So you're left with a threat model where your adversary is able to fake PKI certificates (so they are nation-state sized) and they are able to MitM the connection from your server to your client - but they are not able to MitM the connection from your server to a third party's server. Call me naive, but I highly doubt such an attacker exists.
The answer to this is that anyone that’s thinking in this way is already so elbow deep in security fetishism that real-world implications have long stopped mattering.
Of course, but all emails you could read have been sent at one point or another. Unless you only care about local email delivery, you're going to have to get involved with PKI.
And if your threat model is bad enough that PKI isn't good enough for IMAP, why aren't you using a VPN in the first place? Or even an airgapped network? Or PGP?
There are or were two kinds of people using self-signed certificates. The vast majority used to be "I don't know how or can't afford to get a certificate chain cert."
Now, with letsencrypt, what's left of the "can't afford group" is "I can't be arsed to update my config yet".
Just because many people using self-signed certs are at the "don't know" stage isn't a reason to invalidate them.
It’s not. There’s LetsEncrypt, ZeroSSL, BuyPass, SSL.com, and Google Trust Services[0]. The ACME protocol is standardized and you can point your client at any of these at any time, and other providers can begin providing certificates at any time. Some tooling[1] even uses other providers by default.
[0] https://acmeclients.com/certificate-authorities/ [1] https://github.com/acmesh-official/acme.sh/wiki/Change-defau...
why use a self signed certificate, why not create your own signer cert install that into IOS and then its no longer a "self signed" cert, but just a private cert org.
IOS does allow you to install private signer certs, right? (right?)
A threat model which people using self-signed certificates especially care about.
The idea of certificate authorities, certificate chains and intermediary certificates is common - and based on top down security. That is the reason why it is so dangerous. There is a “lock” and people believe everything is “good” but actually DigiNotar, TurkTrust or the bad government issued a certificate. Google tried more than once to improve the situation but I think they just told Chrome only to accept their actual certificates for their services?
Messenger apps like Signal show how it should be done, the user itself checks and accept. Cameras and QR-codes made it easy. SSHs ASCII fingerprints are a nice thing, too.
PS: Yep. You shall look at the fingerprint of your chat partners in any messenger app.