Live data from Hacker News

iOS 18 breaks IMAPS self-signed certs

forums.developer.apple.com

91–100 of 157 posts

Re: iOS 18 breaks IMAPS self-signed certs

#91

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

Why they would do that? They can't care less about what end user want, particularly in context we are discussing

Re: iOS 18 breaks IMAPS self-signed certs

#92
post #74

Earlier quoted context omitted.

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.

> Uh what is a mitm cert? You're the custodian of the private key associated with the certificate, not LetsEncrypt.

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.

Re: iOS 18 breaks IMAPS self-signed certs

#93
post #43
post #28

Earlier quoted context omitted.

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.

A pinned self cert is still more secure than this because you don’t have to trust any CAs.

> The time for self-signed certificates has passed.

This is bad blanket advice and very much depends on use-case.

Re: iOS 18 breaks IMAPS self-signed certs

#94
post #86

Earlier quoted context omitted.

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.

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

The whole system and everything built on it that underlies trust in encryption on the modern Internet is designed in a way that requires parties called certificate authorities. That's just the design, since it was largely designed for two unrelated people to establish secure communication.

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.

Re: iOS 18 breaks IMAPS self-signed certs

#95

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.

It’s 2024, we’ve seen countless examples of sophisticated hackers getting into all kinds of systems. Anybody who makes a blanket statement that you have to trust the public PKI is either lazy or stupid.

SSH has TOFU and it works very well if you don’t want a key infrastructure.

Re: iOS 18 breaks IMAPS self-signed certs

#96

Earlier quoted context omitted.

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.

> Uh what is a mitm cert? You're the custodian of the private key associated with the certificate, not LetsEncrypt. 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 ro…

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

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.

Re: iOS 18 breaks IMAPS self-signed certs

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

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 wil…

You need to calm down and take a step back to realize not everyone needs to support 20 devices or even 2. What you’ve suggested is a ridiculous blanket statement assuming everyone is setting up things for a fleet of clients.

Re: iOS 18 breaks IMAPS self-signed certs

#98
post #74
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.

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

Re: iOS 18 breaks IMAPS self-signed certs

#99
post #86

Earlier quoted context omitted.

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.

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

You shouldn't, and (this iOS bug aside) you don't, in general. But you're going to run into less friction if you do it the "blessed" way. That's just life.

Re: iOS 18 breaks IMAPS self-signed certs

#100
post #98
post #74

Earlier quoted context omitted.

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.

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

Post reply on HN