Live data from Hacker News

iOS 18 breaks IMAPS self-signed certs

forums.developer.apple.com

41–50 of 157 posts

Re: iOS 18 breaks IMAPS self-signed certs

#41

Earlier quoted context omitted.

Apple isn't doing certificate pinning, it's the apps verifying the certificate chain themselves by baking in public keys (or hashes/fingerprints). So there's not really a way for Apple to break this.

Apple could say "If you wanna talk HTTPS, you have to use our HTTPSClient class, and that only supports using the system certificate store and does not support pinning". Or they could say "All apps that don't support custom certificates for https will be denied app store approval".

While you're at it, make sure to have them prohibit any encryption on top of HTTPS, or apps might just be hiding things in application-level encryption schemes!

Banning certificate pinning... Do we really need mandated insecurity by prohibiting apps from doing better than trusting all Apple-trusted CAs around the world?

Re: iOS 18 breaks IMAPS self-signed certs

#42
I think the solution to this is to:

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.

Re: iOS 18 breaks IMAPS self-signed certs

#43
post #28
post #20

Earlier quoted context omitted.

Only thing required for this setup to work: client needs to be able to resolve domain to internal ip. 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.

how are you renewing the LE certificate if the domain is resolving to an internal ip? this seems like a big hoop to jump through.

LE doesn't need any A or AAAA record. The domain must exist in the DNS and you must be able to create records in the domain.

If you're using internet mail you have a domain, so you can do this. The time for self-signed certificates has passed.

Re: iOS 18 breaks IMAPS self-signed certs

#44

It's 2024, PKI best practices are well known and well documented, anybody still using a self-signed certs on their mail server (or anywhere) is either lazy or stupid. 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.

Or is operating a local-only mailserver not connected to the larger internet? I guess that's a lazy or stupid thing too, these days...

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.

Re: iOS 18 breaks IMAPS self-signed certs

#45
post #16

It's 2024, PKI best practices are well known and well documented, anybody still using a self-signed certs on their mail server (or anywhere) is either lazy or stupid. 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.

explain how a pinned self signed cert is insecure. i don't see it. it would seem to be more secure than one signed by a public CA that's not pinned.

I didn't say a "pinned self signed cert is insecure"

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

Re: iOS 18 breaks IMAPS self-signed certs

#46
post #16

It's 2024, PKI best practices are well known and well documented, anybody still using a self-signed certs on their mail server (or anywhere) is either lazy or stupid. 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.

explain how a pinned self signed cert is insecure. i don't see it. it would seem to be more secure than one signed by a public CA that's not pinned.

It really only is for bad practical reasons, that all coincidentally make it harder and harder to self-host stuff locally without paying a few dollars a month or year here and there to various rent seekers.

"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.

Re: iOS 18 breaks IMAPS self-signed certs

#47

Earlier quoted context omitted.

It's not that you're trusting your own certificate, it's that you're trusting any self-signed certificate, leaving you open to getting MITM'ed.

Can't you install trusted certificates by hand on iOS?

Yes, and you still can. That's not broken.

Re: iOS 18 breaks IMAPS self-signed certs

#48
post #9

Can you add your own CA cert to your device?

You can, but I find that much less secure than being able to TOFU a self-signed certificate:

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.

Re: iOS 18 breaks IMAPS self-signed certs

#49
post #23
post #10

Earlier quoted context omitted.

unfortunately none of that applies to my setup. my imap server lives in a dmz and doesn't have all that other jazz.

This can still work imap.mydomain.com resolving to your hardcoded private ip, put the cert on your imap server, connect by name, done.

This won't work on many home routers that filter out private/local IP A/AAAA records from DNS responses to protect against DNS rebinding.

Re: iOS 18 breaks IMAPS self-signed certs

#50
post #46
post #16

Earlier quoted context omitted.

explain how a pinned self signed cert is insecure. i don't see it. it would seem to be more secure than one signed by a public CA that's not pinned.

It really only is for bad practical reasons, that all coincidentally make it harder and harder to self-host stuff locally without paying a few dollars a month or year here and there to various rent seekers. "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…

Internal CAs and self signed certificates are different. You can still generate a CA, sign your certificates, import your own CA into your phone and have that verify your certificates. You don't need Letsencrypt. But you'll learn in time.
Post reply on HN