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".
iOS 18 breaks IMAPS self-signed certs
91–100 of 157 posts
Re: iOS 18 breaks IMAPS self-signed certs
#92Earlier 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.
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
#93Earlier 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.
> 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
#94Earlier 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?
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
#95It'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.
SSH has TOFU and it works very well if you don’t want a key infrastructure.
Re: iOS 18 breaks IMAPS self-signed certs
#96Earlier 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…
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
#97Earlier 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…
Re: iOS 18 breaks IMAPS self-signed certs
#98I 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
#99Earlier 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?
Re: iOS 18 breaks IMAPS self-signed certs
#100Earlier 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.
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.