Cryptographic egg-on-Facebook, and on Google Calendar, too

There’s cryptographic egg on the faces of both Google and Facebook after the recent publication of some interesting results by Dan Wallach, a university professor in Texas.

Wallach, a computer scientist at Rice University in Houston, performed a very simple, but highly effective, experiment in his undergraduate security class.

The class set up the Wireshark network sniffer and listened in whilst he performed a series of web transactions from his mobile handset.

You can read up his results in detail on his own blog – he and his class did the work, after all – but two specific observations stand out:

* Even though he had turned on full-time HTTPS (SSL) in his Facebook profile, Facebook’s Android app didn’t bother with the secure connection except for the login part. Everything else was in the clear.

* Google didn’t encrypt traffic to its own Google Calendar service from its own Android OS, although it did encrypt traffic to other Google services.

Ten out of ten to Prof. Wallach from a pedagogical perspective. In what I can only imagine was a lecture which will be remembered as great fun, he’s taught his students – which now include all of us – two useful lessons:

READ THE SMALL PRINT and ASSUME THE WORST.

As you can see if you watch my colleague Chester Wisniewski’s video on how to set up HTTPS on Facebook, the Secure Browsing option offers to let you “Browse Facebook on a secure connection (https) whenever possible.”

“Whenever possible,” it seems, means “if both sides happen to support it.” So you may easily – and unknowingly – fall back to an insecure configuration at the whim of the least secure part of the system, including at the request of the client trying to connect.

Cryptographic systems often work this way for convenience and backwards compatibility. But this plays straight into the hands of cybercrooks. Loosely speaking, they can bypass any new-fangled strong security measures at their own discretion. This sort of setup is a bit like having a front door lock which requires a key unless you happen not to have one, in which case the handle alone will open the door.

It seems that both Google and Facebook have failed to enforce their own much vaunted web security settings even from their own Android client apps. This won’t do.

Both companies really ought to bite the cryptographic bullet and offer a configuration option for mandatory HTTPS. This would be a setting by which well-informed users could instruct the Facebook or Google servers to reject any attempt – whether accidental or deliberate – to make an insecure connection.

What if that breaks some of Google’s and Facebook’s most attractive features, and makes those self-same users unhappy? What if third-part app developers complain?

Tough. That’s part of the price of security. As the HBGary Federal hack made perfectly clear, taking chances with convenience by dropping your guard – even temporarily – can have dire consequences.

_{PS. Accessing calendar information over an insecure WiFi connection, where anyone could be listening in and somebody probably is, might sound innocent enough for non-business purposes. But if your calendar places you in Denver whilst your apartment is in Burlingame, that would be quite useful information to a thief, wouldn’t you say?}