Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iOS 18 breaks IMAPS self-signed certs

forums.developer.apple.com

Post reply on HN
Print view View original

71–80 of 157 posts

Re: iOS 18 breaks IMAPS self-signed certs

#71

Post by [deleted] »

stephenmac98 wrote: post #65
lxgr wrote: post #56

Earlier quoted context omitted.

Setting up a NAS means buying one on Amazon and plugging it in. 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 that case the NAS company should, at a minimum, be loading their NAS with a certificate signed by a CA owned by the NAS company, where the trust chain for their NAS's certificates are easily available for users to grab and install. 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…

[deleted]

Re: iOS 18 breaks IMAPS self-signed certs

#72

Post by derefr »

londons_explore wrote: post #31
tadfisher wrote: post #30

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

Or you could ignore the self-signed aspect altogether, and instead give the OS VPN framework (where all network introspection stuff lives on iOS) a hook into the forced-choice HTTPS client — a hook that allows the active system VPN to say either “show me that before you encrypt it / after you decrypt it” or “don’t bother encrypting/decrypting that; I’ll handle it.”

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

Re: iOS 18 breaks IMAPS self-signed certs

#74

Post by hedora »

Arnt wrote: post #3

I switched to letsencrypt certs for my imap server. Works well, IMO better than the self-signed ones I used before.

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.

Re: iOS 18 breaks IMAPS self-signed certs

#75

Post by ninkendo »

mmd45 wrote: post #28
0x457 wrote: 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 can use DNS itself as the challenge. It works something like:

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

Re: iOS 18 breaks IMAPS self-signed certs

#76

Post by snapetom »

techbrovanguard wrote: post #73

tangent, but you can’t send mail on ios with an idn because “the sender address was invalid”, despite it working in macos. i’ve read this is caused by a broken regex check. if any apple employees are reading please take a look

There are so many quirks between the way Mail behaves on iOS vs Mac, its infuriating. At the core of it, if you are manually adding IMAP/SMTP/POP, both just need to get out of the way and stop trying to help. Very typical of Apple to think it knows better than you.

Re: iOS 18 breaks IMAPS self-signed certs

#77

Post by schoen »

techbrovanguard wrote: post #73

tangent, but you can’t send mail on ios with an idn because “the sender address was invalid”, despite it working in macos. i’ve read this is caused by a broken regex check. if any apple employees are reading please take a look

Does some other software (like the MUA) need to convert the IDN to punycode before submitting it to the OS?

Re: iOS 18 breaks IMAPS self-signed certs

#78

Post by commandersaki »

hedora wrote: post #74
Arnt wrote: post #3

I switched to letsencrypt certs for my imap server. Works well, IMO better than the self-signed ones I used before.

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.

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.

Re: iOS 18 breaks IMAPS self-signed certs

#79

Post by wolrah »

lxgr wrote: post #49
Spivak wrote: post #23

Earlier quoted context omitted.

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.

How many people care about setting up secure connectivity to an internal server but are unable to either disable this behavior or configure their own internal DNS service?

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.

Re: iOS 18 breaks IMAPS self-signed certs

#80

Post by yieldcrv »

I feel like this going to happen to the permissionless side of crypto assets just like whats happened to most of the web 1.0 stuff

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

Post reply on HN