

Rethinking SSL for Mobile Apps - jbp
http://www.belshe.com/2012/02/04/rethinking-ssl-for-mobile-apps/

======
rogerbinns
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>

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

------
0x0
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
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. :-)

