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.
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.
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.
Now, with letsencrypt, what's left of the "can't afford group" is "I can't be arsed to update my config yet".
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.
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.
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.
- 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.
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.
Most apps work, but not everyone.
Often called certificate pinning.
The former enabled cert pinning (partially) as a response to a MITM[1] from the latter.
[1]: https://arstechnica.com/tech-policy/2024/03/facebook-secretl...
Or they could say "All apps that don't support custom certificates for https will be denied app store approval".
Banning certificate pinning... Do we really need mandated insecurity by prohibiting apps from doing better than trusting all Apple-trusted CAs around the world?
Where, in the latter case, the TLS establishment is opaque, but then the VPN is handed the data that would be going through the TLS logic, plus an (also-opaque) handle to the established TLS-session RSA key, that it can use to finish the encryption/decryption process of each stream-chunk on behalf of the app, after doing whatever filtering / transformation / etc. it wants to do.
(Anyone remember Privoxy, the “MITM that works for you” that presaged most of the in-client features of Tor Browser? Same idea; just now with OS support.)
Plenty of existing applications will refuse to connect to a self-signed certificate on the belief that allowing the end-user to confirm a certificate offers basically 0 protection against malicious actors.
SSH has TOFU and it works very well if you don’t want a key infrastructure.
Now if I were to provide this as a commercial service, sure, my customers may be worried.
What would happen if you connected to your mail client today and you got prompted "Trust this certificate?" showing a certificate with the same subject as the one you generated? Most people would click trust and get MITM'ed
Allowing self signed certificates significantly lowers the bar when it comes to generating a new certificate which can closely resemble an existing certificate
Beyond that, the management of multiple trusted certificates creates all sorts of room for confusion in an environment. Presumably most services that you run, run over TLS, do you really maintain every certificate both on it's application and on everything which needs to connect to it? That's a huge amount more effort than signing all your PKI with an internal CA, the configuring your connecting applications to trust that CA
So accept self signed on first connection with a detailed panel showing the certificate fingerprint. Then after that require a more involved process to accept a new certificate.
> do you really maintain every certificate both on it's application and on everything which needs to connect to it?
These are client certificates, and in some cases, they're actually pretty awesome.
> than signing all your PKI with an internal CA
That's a single layer of abstraction away from a self signed certificate, because, your CA _is_ a self signed certificate in this scenario. You've taken any defense in depth and thrown it right out the window.
The purpose of software is to make things possible not enforce random pedantry.
is both a mischaracterisation of the argument, and wrong. It's not lazy, it's a choice with pros and cons. Just because you don't like it does not mean it is lazy. Again, issuing your own certificates is a choice.
Allowing self signed certificates does not "significant lower the bar". Did you know that all root certificates are self signed?
The management of multiple trusted certificates is basic administration for large private networks. Yes, TLS and certificate management can be complex, but that is not a good argument for disallowing it, and the idea that managing your own certificate trust is against "best practices" is ludicrous.
I said that self-signed certs are a lazy choice
I also said "allowing the end-user to confirm a certificate offers basically 0 protection" If an average user get's prompted to trust a certificate they will do so blindly At most, someone might look at the subject, but it's 0 effort for a malicious actor to generate a self-signed cert with the same subject, which will be sufficient to fool a decent chunk of users
Pinned certificates do relieve the above issue, but it is still a lazy choice that creates increased long term complexity in the configuration of multi-system environments Presumably most services that you run, run over TLS, do you really maintain every certificate both on it's application and on everything which needs to connect to it? That's a huge amount more effort than signing all your PKI with an internal CA, the configuring your connecting applications to trust that CA Using a CA also allows for use of CRLs or OCPS. If you have 20 devices configured to trust a given self-signed certificate, and that certificate leaks, you now have to update all 20 devices to remove that trust. If you used a CA and implemented either a CRL or OCSP, then you only have to update the respective impelmentation and all of yoru clients will immediately stop trusting that certificate.
In Summary: Using an internal CA offers all the potential protections of pinned certificate, with a number of additional useful security options like OCSP or CRLs Using Self signed certificates creates more work when handling certificate leaks or certificate rotation Using a CA is the industry standard practice, I highly doubt there is a single outward facing project by a major company using a directly self-signed certificate. BUT A self signed certificate is lower effort on the initial setup
Lazy
So maybe we should ask ourselves why can't we just figure out a way to improve handling of CA? Thanks to Let's Encrypt https coverage dramatically improved, now is maybe the time for more people to switch to self CA.
I agree though that promoting adoption through good tooling and pedagogy would be a nicer approach than Apple slap on the wrist.
"Just use Letsencrypt" really is the correct answer for 99% of use cases, but good luck if you find yourself with one from the 1%. You'll get an army of people mindlessly parroting "best practices" and will assume you're incompetent/lazy if you can't find a way to make them work for you.
No non-sophisticated user is able to run their own local CA, and that's why their NAS, IoT setup etc. all run over HTTP only, which in turn has implications for available web APIs (thanks to "secure origin only" policies and no exemption for local IPs/zeroconf domains) and many other things.
It also doesn't work for at least modern Android apps, since Android no longer makes user-provided CA certificates available to (non-browser) apps anymore, I believe, unless they're compiled with a special debugging parameter. On iOS it's still possible, but I'm not sure how long it's going to stay that way.
"Openssl how to set up a CA" > First link fully explains it https://arminreiter.com/2022/01/create-your-own-certificate-...
"How to import CA into iPhone" > First link fully explains it https://www.ibm.com/docs/en/mpf/7.1.0?topic=certificates-ins...
"Android app customize trusted CAs" > First link fully explains it https://developer.android.com/privacy-and-security/security-...
The barrier to entry on PKI isn't that it's hard, it seems to be that people just can't be bothered, PKI is among the most google-able tech processes out there
You're completely out of touch with the majority of the userbase of these products if you think even one in 10 NAS users will set up their own CA using OpenSSL (in a secure way that doesn't expose themselves to being MITMed even on public sites such as that of their bank down the road).
In an ideal world they would load a letencrypt certificate and set up the tooling required to automatically pull down a new one when required.
A NAS company owned CA doesn't offer much of a benefit directly for the plug-n-play users, but it's still better than just a self signed cert, and for people who care about their security even a little bit it can significantly protection.
Most Plug-n-Play NAS solutions will integrate with a web api and/or an app, and it's more common than it should be that NAS'es are exposed to the internet.
Once you control both the NAS and it's clients, there's absolutely no reason not to preload a complete PKI implementation. Even just an installation app which loaded the chain onto any device you wanted to interact with the NAS would be sufficient.
If NAS'es are intended for non-technical people, then any NAS sold should be secure by default.
Requiring users to install a globally trusted CA is a disaster from a security point of view (now my NAS vendor or anyone that hacks them can pose as google.com!), and for this reason doesn’t even work with modern Android apps anymore, for example.
I'm a fan of having TLS on by default for everything on the Internet, but I'm seriously annoyed by the collateral damage to local self-hosted services the implementation of that has caused.
It shouldn't be this hard to e.g. host web server on my local network that browsers grace with "trusted website APIs", but it really is. Why on earth do I need to set up Letsencrypt (and by extension at least DNS) on a local website if I want to be able to use a game pad on it, for example!? https://developer.mozilla.org/en-US/docs/Web/Security/Secure...
We absolutely need a localhost and local domain exemption for both TLS/X.509 certificate validation and web APIs. For example, TOFU seems like a much better model for that use case than trying to bend the "public Internet" model until it fits. SSH has had considerable success in that model, for example.
How often do you think someone tries to connect their gamepad to a local server? Not never, but the total amount of users doing it is probably high tens or low hundreds at most
Compare that to how often gamepad users try to connect to a malicious website - probably hundreds or ever thousands of times a day.
Loosening certificate validation further expose the many less than competent users to risk, and the potential impact both on the customer base and on the product's reputation are significantly higher than the risks of making it cost a couple bucks a year to allow your gamepad to connect to a local server.
For something like a computer, there is a legitimate argument for allowing the user to bypass SSL/TLS restrictions (after some resistance) because laptops are used for development.
I can almost guarantee that the gamepad developers had an options for certificate validation bypass in it's developer options, but they're not gonna expose that needlessly when it offers no benefit, but exposes their customers to additional risk. Your gamepad is likely not a development device after all
What exactly is this restriction preventing me from, then? (And what does a malicious website do with my gamepad data anyway?)
> Not never, but the total amount of users doing it is probably high tens or low hundreds at most
Yes, I'm fully aware that local hosting is rare in the grand scheme of things, but I think you're vastly underestimating the potential. It's currently not even possible to do much better even as a commercial NAS provider, and these are somewhat popular.
A big part of that also seems like a chicken and egg problem: Fewer and fewer users do it because it's getting harder and harder, thanks to browser standards and OS defaults being largely driven by stakeholders that have no interest in it becoming easier.
Yes, none of this is an evil conspiracy; it's just a question of incentives and priorities in the end. I just find it so sad how willingly even a "hacker" audience here embraces the move towards more and more centralization, on more than one dimension. (Peer-to-peer vs. client-to-server, "trusted CA only" vs. trust on first use, cloud vs. self-hosting etc.)
If you control the local network it's trivial to redirect traffic intended for elsewhere, like "google.com", and trivial to have the server it redirects to present a certificate with "google.com" in it's subject or SAN.
What would happen on a laptop is you would be hit with a certificate validation error because it was self signed, and on the laptop you have the ability to bypass it, but that ability to bypass is very dangerous. Most users will not properly check a certificate before clicking to trust it.
As far as what could be done, "this is a low value device to an attacker" is not a security measure, but beyond that I'm sure that people have bought games on a gamepad, and anything which involves financial transactions has the potential for malicious behavior with severe consequences
Right now, .local is completely impossible to encrypt, as well as impossible to use “secure origin” APIs on, which is a shame.
localhost is already considered a secure origin.
Local networks are horribly insecure; easily the most likely place for a MITM attack.
And I generally agree on local networks being insecure. So how about making them more secure instead of marginalizing them even more?
TOFU for TLS certs on .local (for Zeroconf, and maybe something else/new for local DNS) would be a huge step forward from unencrypted and unauthenticated HTTP. Such sites could even still be displayed with a broken padlock or whatever HTTP gets these days to not create any false expectations by users.
I once did this, and besides being incredibly unergonomic, now I have to either securely destroy or safely store the signing key for the self-signed CA, or risk malware from performing an MITM against any app on my device, and not just e.g. the email client.
a) run your own private root CA
b) install the public part of the root CA on your device and trust it (basically the same as many major enterprise end users of android and ios devices need to do already, so this functionality is extremely unlikely to be removed from the operating system)
c) use the root CA to sign a cert for your mail server
Yes it's a bit more hassle than just trying to tell the mail client to trust your self-signed cert that was generated on the mail server and signed by nothing, but I can understand why apple (given the population of hundreds of millions of NON TECHNICAL end users) doesn't want people just blindly clicking through "yes/I accept/trust this server" self signed cert warnings.
hey lurking apple devs- can someone please escalate this?
Walled garden things will take over and something is going to happen to EOAs that make them nerfed or rare
but at the same time, that might take 40 years just like these web 1.0 problems so its fine for now
seems like the issue is specifically with IMAP- I can confirm that calendar syncing works fine with the self signed cert.
this is really disappointing.
It seems like these people are just struggling with how to properly set up their email server and clients when using a private CA. If you're going to use your own CA, then configure your client to trust it. The rest of us should be able to enjoy secure defaults and not have to worry about our less informed family members being tricked into bypassing basic security protections like TLS validation.
This is about making bad things harder for unskilled users at the cost of raising the standard for service providers. If you can set up an email server, you can use easyrsa or step-ca or some manual openssl to create your own root CA. Or, register your self-signed email server as a trusted root CA.
Personally, I use easyrsa for my internal CA (with domain path constraints because I'm paranoid) and letsencrypt for my mail server, but I require VPN access to the user ports on the mail server.