Comment by Arnt
Comment by Arnt 2 days ago
I switched to letsencrypt certs for my imap server. Works well, IMO better than the self-signed ones I used before.
Comment by Arnt 2 days ago
I switched to letsencrypt certs for my imap server. Works well, IMO better than the self-signed ones I used before.
Pretty sure most people's threat model doesn't really care about the scenarios you mention. And for most people, that's fine.
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.
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.
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".
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?)
iOS never supported this configuration regardless, a change in SSL certificate does not cause any kind of notification to the user.
Also, you're basically objecting to the entire idea of PKI for use in IMAP which is incredibly hard to justify. Perhaps you wish to use a different model for your own personal reasons but the default being PKI should not be controversial, and if you want to use your own model you should use a different mail client.
It supported using self signed certs, but if the server suddenly switched from a self signed to a trusted CA-signed certificate, no prompt would be given. So the idea that self signed certificates are somehow more secure for this specific purpose is incorrect.
How does a self signed cert protect you from MITm if the iPhone will accept any signed certificate thereafter? There’s no cert pinning AFAIK in imaps.
Uh what is a mitm cert? You're the custodian of the private key associated with the certificate, not LetsEncrypt.
And any CA can generate a certificate to MITM anything. That's why it's pretty much a requirement to submit all certs issued to Certificate Transparency, and if you're found to be misbehaving expect to receive ire from CA/B.
The whole system and everything built on it that underlies trust in encryption on the modern Internet is designed in a way that requires parties called certificate authorities. That's just the design, since it was largely designed for two unrelated people to establish secure communication.
Clearly, it is not required to use a third party. First of all, you can sign your own cert using itself, then verify it manually. However, this is not the trust model that most Internet software uses. That model is closer to what SSH does, sometimes called TOFU (Trust On First Use). The model that is intended is for the certificate chain to be verified back to a trust root (ignoring other wrinkles.) There's really no particular reason why self-signed certificates must be supported.
Note that I don't think this makes the bug report invalid. It seems like a regression that is not intentional. However, the important point is that a third party still isn't needed to use the system as intended. You can, in fact, issue your own CA certificates, trust them on your devices, and then use those to sign your own certificates, making yourself the authority. This will work even on iOS as far as I know, and it follows the typical trust model so software should handle it as expected (though apps that use certificate pinning or bundle the Mozilla CA certificates statically instead of using the operating system's trust store may not work, but by and large it works.)
Personally, I just use Let's Encrypt. That way other people can establish a "secure" connection to my devices, too.
You can, you just have to use iTunes from your computer like it’s 2003 to add it to your music library.
It's not being required. just that the thread is about Let's Encrypt which ostensibly easier than setting up your own CA and distributing the root certificates to your devices. Which isn't too difficult but given how many people apparently use self-signed certificates, it's a bit high a bar.
> Uh what is a mitm cert? You're the custodian of the private key associated with the certificate, not LetsEncrypt.
Don’t be obtuse. Letsencrypt and every other trusted CA has the ability to issue new certs for any domain at any time without you knowing.
There is absolutely no requirement to submit these to Certificate Transparency. That’s a thing some browsers do, but not most mail clients.
If you don’t trust the root CAs at all and only trust your self signed cert or only trust another signing cert you control, then a mitm isn’t possible without getting your private signing cert keys.
Not that it removes you entirely from the PKI ecosystem as you seem to desire, but in case you’re not aware since 2017 CAs are required to check and honour the CAA DNS records you set. These specify which CAs are allowed to issue certificates for your domain.
If any CA issues a certificate anyway, they’re in violation of requirement 3.2.2.8. Don’t know what you’re up to, but I have to imagine it would have to be pretty interesting to someone for one of those companies to face down an existential threat and misissue a certificate for your domain.
> Don’t be obtuse. Letsencrypt and every other trusted CA has the ability to issue new certs for any domain at any time without you knowing.
You shouldn't use words you don't understand. I already pointed this out.
> There is absolutely no requirement to submit these to Certificate Transparency. That’s a thing some browsers do, but not most mail clients.
If you want to be in Chrome bundle or Safari/Mac bundle you need to submit to at least one approved CT log. If you're found misbehaving or issuing non compliant certificates, expect ire from CA/B and potential ejection from certificate trust stores. This has happened quite a number of times, and CAs in the WebPKI trust are highly unlikely to issue a MITM certificate.
https://letsencrypt.org/docs/caa/
Not enough? Account binding.
https://community.letsencrypt.org/t/enabling-acme-caa-accoun...
I'm using a private ip over a vpn so I don't think that workaround will work for me. I don't really want a public dns record.
LE will issue you a wildcard certificate and it's usable for mail.
i'm just using a hardcoded private ip to connect to the imap server. are you saying i can get a certificate with a hostname of "*" that will match ANY ip address?
No, but you could use DNS for that internal IP. And then you'd have a hostname. Since your IMAP server likely has some way of getting external mail, it is likely that you have a DNS zone and MX records, so adding an A record for your internal IMAP access isn't that much of an effort compared to what you already would have.
If you have mmd45.com as a domain and have MX records pointing to your mail server, adding imap.mmd45.com pointing to your IMAP server should be fairly simple. Getting a Let's Encrypt certificate for *.mmd45.com is all that remains for the TLS part with a valid CA chain. As a bonus you can then also use encrypted SMTP.
That adds a lot of attack surface vs. issuing a self-signed cert and confirming it was securely verified by your imap client.
Not only could let’s encrypt issue a mitm cert for your imap connections, so could other CAs, and any cloud providers / dns providers you use.