Skip the navigation

Kenneth van Wyk: Why mobile apps beat Web apps for privacy

Internet communications are prey to surveillance, but you can better shield them

By Kenneth van Wyk
August 26, 2013 11:37 AM ET

Computerworld - Yet another excellent resource, Groklaw, is shuttering its services as a consequence of what I'll call the ongoing "Surveillance Wars." Rather than debate the politics of surveillance, I want to again make a case for making our software tools harder and more resilient to attack, regardless of where that attack is coming from.

One thing to consider is making more use of mobile apps as opposed to Web apps. Here's the thing: Surveillance typically targets data in transit, which is something that mobile devices and their apps can do a very decent job of protecting.

In my June column, I talked about safeguarding privacy through email security, stressing key management above all -- specifically, doing our own key management and not trusting any external service from doing it for us.

But we have many other means of communication beyond email. With all of them, it's still vital to consider key management, but things can be slightly different.

Most Internet communications rely on Transport Layer Security (TLS) or its predecessor, Secure Sockets Layer (SSL). In either case, the actual key used to encrypt data in transit is generated by the SSL subsystem. Unless you write your own SSL library, you're probably going to use an SSL that is open and respected among the crypto community -- OpenSSL, Bouncy Castle and the like.

Now, you certainly can use OpenSSL in an iOS or Android application, and you certainly can use Bouncy Castle to build an Android application.

But that's not enough.

When an SSL/TLS session is initiated, the server presents to the client its SSL certificate. In traditional SSL, that certificate is checked for two things: Does the name in the certificate match the name and IP number we can derive via a DNS lookup, and is the certificate signed by a trusted root certificate authority (CA)?

There are a couple of problems with doing only that. First, DNS is not trustworthy, so at least part of the trust validation in the above is placing trust in something that can't support it. Second, if the certificate is signed by any CA, that's good enough for SSL, but it shouldn't be good enough for us.

That's where certificate pinning comes in -- a topic I've mentioned here before. And that's where the mobile part of the argument creeps in.

In traditional Web apps, the browser (and underlying system libraries) does the SSL lookups. Some browsers, notably Google's Chrome, use certificate pinning to verify the SSL certificates they use for their own purposes, such as connections to Google servers to check "safe browsing" URLs and so on. But when a browser is rendering the HTML of a Web app and that Web app refers to an SSL encrypted page (HTTPS), the browser lacks the context to do certificate pinning.

Our Commenting Policies
Internet of Things: Get the latest!
Internet of Things

Our new bimonthly Internet of Things newsletter helps you keep pace with the rapidly evolving technologies, trends and developments related to the IoT. Subscribe now and stay up to date!