4 ms·

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 k

by leoh 12y ago

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.

coffeecheque 12y ago
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!
- Chris911 12y ago
  Yep no luck for QuizUp here as well.
- e28eta 12y ago
  Downside: can't change to a new SSL cert without updating the clients!
  - wiml 12y ago
    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.
    - ohnoberyn 12y ago
      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!
      - Robin_Message 12y ago
        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.
      - wiml 12y ago
        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.
martinald 12y ago
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 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.

by leoh 12y ago

coffeecheque 12y ago

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!

Chris911 12y ago
Yep no luck for QuizUp here as well.
e28eta 12y ago
Downside: can't change to a new SSL cert without updating the clients!
- wiml 12y ago
  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.
  - ohnoberyn 12y ago
    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!
    - Robin_Message 12y ago
      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.
    - wiml 12y ago
      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.

martinald 12y ago

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