Live data from Hacker News

iOS 18 breaks IMAPS self-signed certs

forums.developer.apple.com

131–140 of 157 posts

Re: iOS 18 breaks IMAPS self-signed certs

#131
post #86

Earlier quoted context omitted.

why should I require some third party's permission to do encryption between one of my computers and another one of my computers?

There are many other questions to ask until you come to this question. One of them is; why iOS doesn't let me play my own mp3s?

You can, you just have to use iTunes from your computer like it’s 2003 to add it to your music library.

Re: iOS 18 breaks IMAPS self-signed certs

#132
post #98

Earlier quoted context omitted.

Pretty sure most people's threat model doesn't really care about the scenarios you mention. And for most people, that's fine.

A threat model which people using self-signed certificates especially care about. 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 t…

But if you distrust the entire PKI ecosystem, how are you intending to use your email server?

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.

Re: iOS 18 breaks IMAPS self-signed certs

#133
post #129

And the Apple fanboys are loose again... 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…

[dead]

Re: iOS 18 breaks IMAPS self-signed certs

#134
post #66

Earlier quoted context omitted.

My point is precisely that current browsers and OSes make it impossible to ship a secure-by-default device running a local web server, NAS or otherwise. 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.

Offering a layperson NAS buyer a self-signed cert is not "secure by default" even if browsers did accept it.

Would it be less secure than unencrypted HTTP?

Re: iOS 18 breaks IMAPS self-signed certs

#136
post #64

Earlier quoted context omitted.

Then only allow self-signed certificates for literal IPs or those on .local (and other private/reserved TLDs). Right now, .local is completely impossible to encrypt, as well as impossible to use “secure origin” APIs on, which is a shame.

.local also hasn't been best practice since 2005. Current recommendation, because of Certificates is to use internal only subdomain of domain you have control over.

What? .local is the dedicated TLD for Zeroconf/Bonjour/mDNS! How is that deprecated?

And you’re just reconfirming my point: All of these recommendations are great for publicly hosted sites or corporate environments, but largely impracticable for home users that don’t know how to, or don’t want to, have a second job as sysadmins.

Re: iOS 18 breaks IMAPS self-signed certs

#137
post #41

Earlier quoted context omitted.

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?

They already do that to some extent, actually. Not as you mention, but because of US export compliance laws.

Countless encrypted messenger apps, GPG implementations etc. beg to differ.

Re: iOS 18 breaks IMAPS self-signed certs

#138
post #129

And the Apple fanboys are loose again... 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…

I suspect it's worse than that.

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.

Re: iOS 18 breaks IMAPS self-signed certs

#139
post #136

Earlier quoted context omitted.

.local also hasn't been best practice since 2005. Current recommendation, because of Certificates is to use internal only subdomain of domain you have control over.

What? .local is the dedicated TLD for Zeroconf/Bonjour/mDNS! How is that deprecated? And you’re just reconfirming my point: All of these recommendations are great for publicly hosted sites or corporate environments, but largely impracticable for home users that don’t know how to, or don’t want to, have a second job as sysadmins.

Home users also don't have IMAP servers they run themselves. They are in public email service.

Re: iOS 18 breaks IMAPS self-signed certs

#140
post #132

Earlier quoted context omitted.

A threat model which people using self-signed certificates especially care about. 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 t…

But if you distrust the entire PKI ecosystem, how are you intending to use your email server? 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…

The answer to this is that anyone that’s thinking in this way is already so elbow deep in security fetishism that real-world implications have long stopped mattering.
Post reply on HN