I switched to letsencrypt certs for my imap server. Works well, IMO better than the self-signed ones I used before.
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.
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.
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.
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?
Now, with letsencrypt, what's left of the "can't afford group" is "I can't be arsed to update my config yet".
[0] https://acmeclients.com/certificate-authorities/ [1] https://github.com/acmesh-official/acme.sh/wiki/Change-defau...
IOS does allow you to install private signer certs, right? (right?)
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.
Not enough? Account binding.
https://community.letsencrypt.org/t/enabling-acme-caa-accoun...
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.
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.
Running away from defects doesn't get them fixed.
OP wants support for the special case where only the cert issuer trusts the cert (he has his own self-signed cert). Apple and others do support that: You make a private CA, trust that CA in the device, and then use that CA to sign certs for your IMAP server. IIRC (and this is from vague memory) you may need to configure yourself to be a company that manages employees' devices.
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.
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.
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.
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.
Seems to be a safe assumption you have a domain since you're receiving mail.
Go run something like certbot[0] on your mail server. It has plugins to integrate with various DNS providers. (This is who is hosting the zone where you map domains to IPs, not necessarily where you registered the domain.) If they don't have a plugin for your host, you could look at moving the zone (e.g., CloudFlare is free for something like this, Route53 is <$1/mo) or finding another tool that does support it[1].
No external IPs involved anywhere and you can get valid, trusted SSL certificates for your domain. Set up the auto-renewal (in essentially all cases, add something to crontab), and it'll periodically dump new certificates to disk for you so you never need to think about the certificates again.
If you don't even want anyone to know that there's a "imap.mmd45.com" in existence _somewhere_ in the world, you can issue a certificate for `*.mmd45.com` and it will cover any direct subdomains.
Now you actually need to _connect_ to your mailserver with some sort of hostname rather than IP. For desktop devices and stuff, you could just throw this in /etc/hosts if you wanted. Some VPN/VPN-adjacent tools have ways to push mappings like that. Basically all of them have a way to override the DNS server in use if you were willing to run your own DNS server on the same host that has your mailserver. You can also just create a public record mapping imap.mmd45.com to 10.1.2.3.
[0] https://eff-certbot.readthedocs.io/en/latest/ [1] https://letsencrypt.org/docs/client-options/
I have wireguard mesh with a bunch of services that use LE for TLS that have no access to interwebs and not accessible from interwebs.
It does not. Use DNS validation, that way you can issue LE certs for individual domains as well as wildcard certificates without needing to expose anything anywhere other than a CNAME record for the validation.
- You manage the mmd45.me domain (through a dns provider, say dnsimple)
- You ask LE for a cert for imap.lan.mmd45.me (an address that doesn’t exist, but you use in /etc/hosts or something internally. Or maybe an internal dns server like a pihole or something. The rest of the internet doesn’t see this address)
- LE says “prove you own lan.mmd45.me by creating a TXT record containing <random-nonce> inside _acme-challenge.lan.mmd45.me”
- Certbot integrates with your DNS provider to create said TXT record
- LE sees the TXT record and determines you are the owner, and signs your cert. At this point certbot can just delete _acme-challenge.lan.mmd45.me because it did its job.
At no point does mail.lan.mmd45.me need to be externally resolvable to any address for this to work.
If you're using internet mail you have a domain, so you can do this. The time for self-signed certificates has passed.
> The time for self-signed certificates has passed.
This is bad blanket advice and very much depends on use-case.
The few people who understand the niceties of certs can create a private CA, trust that, and use that CA to sign a regular cert. Doing that is nontrivial, but it doesn't put other people at risk.
My internal DNS names are served from my router and I'd imagine a lot of the people who would care about this in a home environment are running either open-source or business-class commercial devices that can do the same.