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.
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
The self-signed certificate has no link to a trust anchor. So it’s easy for Mallory to replace it with her own malicious certificate. It’s much harder for Mallory to replace a certificate that is tied to a CA.
SSH has TOFU and it works very well if you don’t want a key infrastructure.
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
"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.
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
localhost is already considered a secure origin.
Local networks are horribly insecure; easily the most likely place for a MITM attack.
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.
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.
Most apps work, but not everyone.
Often called certificate pinning.
Or they could say "All apps that don't support custom certificates for https will be denied app store approval".
Any apps that set up certificate pinning this way could be bypassed by Apple, though obviously there would be little value in them doing it since that'd just lead to app developers doing what you're describing instead.
Though if I'm understanding this correctly, jailbroken phones could probably bypass it by modifying an app's Info.plist and running the app despite the broken signature.
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...
The biggest pain is Flutter apps, which come with their own native TLS stack.
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.
hey lurking apple devs- can someone please escalate this?
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.
Does this break in iOS 18 or does this affect only self-signed (untrusted) certificates?
Regardless how your opinion on PKI and self-signed certificates is, shouldn't we at least be bothered by the fact that Apple just switched off this feature without any communication whatsoever? The community was literally in the dark about whether this is an official policy change or a bug.
Google, in situations like this, at least made some corpospeak press release officially "sunsetting" the feature and provided an official deprecation timeline so users have time to adapt.
Apple is apparently just leaving their users stranded and unable to access their email.
Since the UK's Investigatory Powers Act 2016, I've noted that every web browser is necessarily an end-to-end encrypted communication system.
This isn't compatible with what all the spy agencies want. The US can kinda get past that with the reporting obligation for anyone publishing on an app store controlled by a US company. (As a British citizen living in Berlin, the corresponding checkbox when publishing apps is mildly infuriating).
Now that Apple is obligated to allow competitors, that doesn't work. Or perhaps the agencies finally noticed that this problem applies to websites and not just apps (perhaps web apps are finally good enough?)
So the agencies find another way — and this time it comes with an obligation to not report what they're doing.
This smells like that other way.
Might not be correct, but intelligence agencies' long-standing history means it's not paranoia.
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.
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
Using dovecot 2.3/Ubuntu on the server.
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.
