AppleInsider.com posted an article today claiming the lack of SSL on MobileMe has caused “unnecessary panic” and MobileMe is in fact secure. This is 100% false.

I’m not sure what to make of the article. I feel like the author said a bunch of big words hoping that most people would assume he knew what he was talking about and move on. Let’s try to break it down:

Data transaction security in MobileMe’s web apps is based upon authenticated handling of JSON data exchanges between the self contained JavaScript client apps and Apple’s cloud, rather than the SSL web page encryption used by HTTPS.

So the “JSON data exchanges” are “authenticated”. This is like saying “You can only read your email if you’re logged in”. I should hope so.

The only real web pages MobileMe exchanges with the server are the HTML, JavaScript, and CSS files that make up the application, which have no need for SSL encryption following the initial user authentication

This implies that while the app itself isn’t encrypted, it doesn’t need to be since the data itself is. This would be nice, but:

• As Andrew Wooster points out, if a man-in-the-middle attack is possible, the app itself can by hijacked, and all bets are off. In addition to providing encryption, SSL can protect against MITM attacks. See below.
• The data is actually NOT encrypted. Doh. See screenshots below.
• Even if MITM attacks are taken out of the equation, and Apple wanted to encrypt the data but not the app, it’s simply not possible to make HTTPS requests from a page loaded over plain old HTTP due to the same origin policy. There are numerous tricks (iframes, script tags, etc) to get around the same origin policy but none that I’m aware of would be useful in this sort of situation.

Viewing MobileMe’s traffic in your network sniffer of choice (I prefer Charles and Wireshark) shows your data is actually unencrypted.

Calender:

Email:

Finally, the article states:

This has caused some unnecessary panic among web users who have equated their browser’s SSL lock icon with web security. And of course, Internet email is not a secured medium anyway once it leaves your server.

SSL is, in fact, the standard for securing web apps. I am much more inclined to trust SSL, which is known to work well, than a proprietary solution (or in MobileMe’s case, none at all).

Regarding email being unencrypted, it is true that email is often unencrypted between mail servers, but the more important link is between the user and their mail server, especially with widespread WiFi usage. Any sane person will use POP, IMAP, or web mail over SSL, which is more than MobileMe can claim to offer. And don’t forget it’s not just email we’re talking about: calendars, contacts, files, etc are also transmitted in the clear by MobileMe.

*[Clarification: this article only pertains to the MobileMe web interface. IMAP email and OS X syncing do offer encryption]*

The article reminded me of the recent Mozilla SSL policy bad for the Web article and ensuing comments on Hacker News. Some people are upset that Firefox 3 makes it harder for users to visit sites with self-signed SSL certificates. They claim this is bad for the web because it forces anyone who wishes to use encryption to pay a certificate authority (CA) for a signed SSL certificate, which goes against the openness of the Web.

They point to the fact that self-signed certificates can offer encryption without authentication. This is true, until a MITM attack is possible, at which point the encryption becomes useless. The attacker simply inserts himself between you and the server, encrypting both channels with his own self-signed certificate, while still intercepting all communication. This is much worse than no encryption at all, since the user may naively believe it’s a secure connection.

If browsers were to blindly accept self-signed certificates, the system would break down. Just because you wanted to save $15 on a SSL certificate, I would no longer be warned of MITM attack on my bank website. Clearly not acceptable.

So they suggest making the warning less obtrusive, but then average users who don’t know what SSL will simply ignore it. The more sites that use self-signed certs, the more they ignore it, and the more they become used to it, until the day they go to their bank’s website and get a warning they ignore out of habit. It’s a user interface problem just as much as a technical problem.

Making the warning scary and difficult to ignore accomplishes two things. It makes it harder for the user to accidentally ignore it, and it encourages webmasters to use CA signed certificates, which are far more secure.

My point is that when thinking about security you must take the whole system into account, not just pieces of it. SSL encryption on MobileMe’s login page is useless if the attacker can then sniff all the data, just as SSL encryption is useless if you can’t be sure who you’re talking to.