Hacker News Reader

Comment by xg15 | Hacker News Reader

I'm not sure how the situation is with Apple, but it always bothered me that on Android, apps can implement their own logic for TLS certificate validation. Apps can use this to hardcode key-pinning and make it effectively impossible (short of patching the app) to inspect an encrypted connection, even if you're the owner of the device.

I feel the push for DoH will make this even worse - because then you won't even know which servers your apps are connecting to.

View on HN

Once you install closed source software, you're no longer the sole owner of your computer. If an app wants to hide data, and they can't rely on tls to do it, they'll just add another layer of encryption.

Unfortunately Google both supports and recommends this. Recently they've even made it easy for apps to automatically ignore any custom certificates added to the trust store, so they don't even have to bother to implement pinning.

Yeah, I'm honestly not surprised. Apologies for the cynicism, but sometimes I wonder if the pushes for HTTPS-everywhere, certificate transparency and DoH are really more for the privacy of app developers instead of the privacy of users...

If you care about the privacy of users, you need software that the user controls, not the developer. Therefore free software.

Supply-side economics is and always will be dominant.

Understandable position for them to take when you have the likes of Facebook / Onavo etc pushing VPNs and root certificates on uninformed users for "research".

Same for Apple, I've had to bypass this multiple times for pen testing engagements. There are ready to use modules to patch it out, no root / jailbreaking required.

There is lots of good security reasons to do this. Further, if they didn't people would just roll a Swift / OBj-C SSL library and do it all themselves, which would be worse I think.

Sorry for asking, but what secure reasons would that be?

If Apple wanted, they could prohibit the last point by requiring all apps to delete TLS handling to the OS and failing the review otherwise.

It stops people who have root certificates installed on their phone (e.g. the Facebook research app from a couple weeks ago) from being able to monitor traffic.

But it also allows that very same app to smuggle all kinds of tracking data to facebook without the developers having to worry that anyone would catch it doing so.

Also, we already have several systems to manage app access to things that could potentially be misused. Why not manage user certificates the same way?

E.g., pop up a consent prompt before letting an app install anything - or, if that is too annoying, don't give apps access to the functionality at all and exclusively manage certificates via the system UI.

> It stops people who have root certificates installed on their phone... [emphasis mine]

Indeed. That's my point. I'd consider this a bug, not a feature.

Are you talking about iOS? What solutions exist to bypass certificate pinning without jailbreaking?

Yes, A tool called Objection can do it. You have to modify and re-sign the app you are interested in bypassing. Requires a developer account and the .ipa of the app you want to work with.

https://github.com/sensepost/objection

It seems like this requires a decrypted IPA. Do you know of a way to get those without jailbreaking?

Its a feature not a bug, and also thats the same with Apple. On top of that, with android you at least can easily become root and hook into the TLS library yourself and read the network traffic this way. Which is why this article is pretty underwhelming if you ask me, whats interesting is looking at the content that the apps are sending about you.

> short of patching the app

Well, yeah, you need to go beyond a traffic sniffer because if a traffic sniffer was enough, where is the security gain?

Apps using custom certificates is a best practice and absolutely essential for communicating securely with devices that can not participate in the web CA (because, duh, they are not websites). Think your local network WiFi camera.

(* secure->security, delete->delegate at the reply below, got caught by the noprocrast thing at the worst of times, sorry...)

Reply on news.ycombinator.com