Rethinking SSL for Mobile Apps

http://www.belshe.com/2012/02/04/rethinking-ssl-for-mobile-apps/

by jbp • 14 years ago

7 4 14 years ago

0x0• 14 years ago

Would baking your own SSL stuff into the app instead of just running with the system URL stuff cause more paperwork regarding Apple and the crypto export control stuff?

Turing_Machine• 14 years ago

I wouldn't think so, as long as you describe what you're doing and describe it as SSL (honestly, of course... I would strongly discourage claiming that it's SSL unless it's really a fully-compatible implementation, with no additional encryption mechanisms, etc.)

There's really very little paperwork required these days, and the process is quite streamlined -- I got approved (fully online) about 20 minutes after submitting the form. I have a hunch that they're getting tired of processing forms that just involve SSL and are more or less rubberstamping 'em. That makes perfect sense -- SSL is a standard technology, they've granted the same export permission a zillion times in the past, etc. I'm not trying to suggest that they're not doing their duty, just that SSL is routine.

However, there's only one way to find out for sure. :-)

lsh123• 14 years ago

The OCSP is used to ensure that in case of security breach the certificate can be revoked dynamically. If you don't care about the "dynamic" part then you can skip the whole OCSP process all together. Now you are in the same state as you will be with embedding your server cert in the app without the need to "hack" the system.

BTW, nothing prevents you from using your own certs. Just make yourself a CA, add root cert to the app, and implement OCSP on your server (if you care about OCSP). Again, no need to hack it and invent new security protocol. Everything you need is already there.

rogerbinns• 14 years ago

The OCSP (certificate revocation check) doesn't have to be done on every SSL setup - the results can be cached for a while.

What is most strange about this article is the assumption that the backend connectivity is coupled to UI interactivity. That is the single worst thing you can do in a mobile app. They should be decoupled as much as possible. In general the user shouldn't even be able to figure out or care that there is latency in the underlying networking.

Of course the one time is when they search for something, but local caching and prediction plus heuristics should help a lot of the time for that. (Of the billions of items on the server, the user is only going to access a tiny subset.)

For the developer types this is a nice presentation (with a nervous presenter?) showing best practises for writing a REST Android app. Pretty much all of the principles apply to iOS and other mobile platforms too where you decouple the user interface from the underlying networking.

Google I/O 2010 - Android REST client applications http://www.youtube.com/watch?v=xHXn3Kg2IQE

Rethinking SSL for Mobile Apps

Related Stories