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

31–40 of 157 posts

Re: iOS 18 breaks IMAPS self-signed certs

#31

Post by londons_explore »

tadfisher wrote: post #30
punnerud wrote: post #27

I wish they could break Snapchat, Facebook etcs ‘s self-signed certs. I own the device, why can’t I see the traffic to and from all of these apps if I add my self-signed cert and approve to use a MITM-proxy. Most apps work, but not everyone. Often called certificate pinning.

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

Re: iOS 18 breaks IMAPS self-signed certs

#32

Post by qingcharles »

tadfisher wrote: post #30
punnerud wrote: post #27

I wish they could break Snapchat, Facebook etcs ‘s self-signed certs. I own the device, why can’t I see the traffic to and from all of these apps if I add my self-signed cert and approve to use a MITM-proxy. Most apps work, but not everyone. Often called certificate pinning.

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.

Can you not extract the key from the apps? They are only signed against modification, surely? Can you not read the data they have stored on the handset?

Re: iOS 18 breaks IMAPS self-signed certs

#33

Post by mmd45 »

punnerud wrote: post #27

I wish they could break Snapchat, Facebook etcs ‘s self-signed certs. I own the device, why can’t I see the traffic to and from all of these apps if I add my self-signed cert and approve to use a MITM-proxy. Most apps work, but not everyone. Often called certificate pinning.

i saw a video on youtube where a guy intercepted https app traffic from an android app for a smart scale where the app used certificate pinning. there was some very automated tool for defeating the cert pinning. unfortunately i can't find the video link.

Re: iOS 18 breaks IMAPS self-signed certs

#34

Post by nerdile »

So in summary: iOS used to accept untrusted certificates, yikes! Now, it validates the server cert, and people are upset? This blatantly insecure thing is broken now and the posters don't want to set it up securely?

It seems like these people are just struggling with how to properly set up their email server and clients when using a private CA. If you're going to use your own CA, then configure your client to trust it. The rest of us should be able to enjoy secure defaults and not have to worry about our less informed family members being tricked into bypassing basic security protections like TLS validation.

Re: iOS 18 breaks IMAPS self-signed certs

#35

Post by stephenmac98 »

shakow wrote: post #19
stephenmac98 wrote: post #14

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.

There is no security hole if I am singing my own certificate for my own mails on my own server; it would mean that I do not trust... myself? Now if I were to provide this as a commercial service, sure, my customers may be worried.

"This is good enough because I don't expect anyone other than me will use it" is lazy

What would happen if you connected to your mail client today and you got prompted "Trust this certificate?" showing a certificate with the same subject as the one you generated? Most people would click trust and get MITM'ed

Allowing self signed certificates significantly lowers the bar when it comes to generating a new certificate which can closely resemble an existing certificate

Beyond that, the management of multiple trusted certificates creates all sorts of room for confusion in an environment. 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

Re: iOS 18 breaks IMAPS self-signed certs

#36

Post by mmd45 »

nerdile wrote: post #34

So in summary: iOS used to accept untrusted certificates, yikes! Now, it validates the server cert, and people are upset? This blatantly insecure thing is broken now and the posters don't want to set it up securely? It seems like these people are just struggling with how to properly set up their email server and clients when using a private CA. If you're going to use your own CA, then configure your client to trust i…

bad summary. it prompted you to accept the certificate upon first use and then pinned it which is far different than what you are describing in terms of security implications.

Re: iOS 18 breaks IMAPS self-signed certs

#37

Post by anamexis »

shakow wrote: post #19
stephenmac98 wrote: post #14

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.

There is no security hole if I am singing my own certificate for my own mails on my own server; it would mean that I do not trust... myself? Now if I were to provide this as a commercial service, sure, my customers may be worried.

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.

Re: iOS 18 breaks IMAPS self-signed certs

#38

Post by darknavi »

qingcharles wrote: post #32
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.

Can you not extract the key from the apps? They are only signed against modification, surely? Can you not read the data they have stored on the handset?

Generally apps like Fiddler generate their own cert which you load onto the device and accept. My understanding is this allows it intercept and re-write requests. When you do this, apps using cert. pinning will sniff out your "wrong" cert. and stop working.

Re: iOS 18 breaks IMAPS self-signed certs

#39

Post by darknavi »

anamexis wrote: post #37
shakow wrote: post #19

Earlier quoted context omitted.

There is no security hole if I am singing my own certificate for my own mails on my own server; it would mean that I do not trust... myself? Now if I were to provide this as a commercial service, sure, my customers may be worried.

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?

Re: iOS 18 breaks IMAPS self-signed certs

#40

Post by kstrauser »

qingcharles wrote: post #32
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.

Can you not extract the key from the apps? They are only signed against modification, surely? Can you not read the data they have stored on the handset?

No, the idea is that the app has the server's public key embedded in them, and they use that to verify that they're connecting only to the server with the corresponding private key.
Post reply on HN