Hacker News Reader

Comment by leoh | Hacker News Reader

If you are building an app and want to protect against this kind of thing, you can use SSL pinning. This means that you hard-code your API server's public SSL key into your app and explicitly reject and other public keys, even if they are installed of trusted by the OS. Incidentally, the twitter iOS app does this — you can't observe its traffic via Charles or other snoopers.

View on HN

It's not really a protection though. With a jailbroken phone you could probably change the key with a hex editor or similar. There's also this: https://github.com/iSECPartners/ios-ssl-kill-switch

Also, you're totally screwed if you need to reissue your SSL cert for a security problem (think heartbleed). You'd have to reissue the cert, wait for apple to approve the update, then hope that a significant proportion of your users actually update your app.

Ah - that might explain why I had trouble trying to sniff the data for QuizUp too.

I didn't know you could do that, so thanks!

Yep no luck for QuizUp here as well.

Downside: can't change to a new SSL cert without updating the clients!

What I do is I generate an inhouse CA for uses like these and hardcode its certificate into the clients: the key used by the API server can then be changed whenever necessary, just as if it were signed by a commercial CA.

Would you be able to expand on how you generate an inhouse CA? From Googling I don't think you're becoming an intermediate CA as that seems extremely costly! I am in the situation where I have a pinned cert in my app and I will have to address it's expiration in the future!

Since you are hard-coding the CA, it doesn't have to be an actual intermediate CA that is trusted by anyone except for your app (that has it hard-coded.)

But as people say, they could easily edit your binary to change the CA, or disable the CA check entirely, so, like any DRM system, you can't keep the protocol secret.

It can be done using openssl (the documentation is a bit opaque but it's not hard to do). As Robin_Message says, I'm not becoming an intermediate CA — I'm generating my own root CA, which no one except me and my apps trust. In turn, my apps contain only my own CA as a trust root. There really isn't an advantage to using a commercial CA here, beyond the fact that their web portal is probably easier to use than the openssl command line.

Reply on news.ycombinator.com