Although the launch of MobileMe wasn't exactly one of Apple's high points in product releases, even the most acerbic of critics grudgingly admits that its Web interface is one of the more well-designed on the market. Unfortunately, MobileMe's Web application is also one of the least secure: Apple allows anyone to listen in to your communications, including the contents of email and calendar updates.
AppleInsider, reporting on MobileMe on 15-Aug-08, attempted to assuage concerns that the MobileMe Web interface does not use SSL encryption to protect connections from malicious sniffing or hijacking. They stated SSL was unnecessary because:
"If Apple applied SSL encryption in the browser, it would only slow down every data exchange without really improving security, and instead only provide pundits with a false sense of security that distracts from real security threats."
As reported by Jens Alfke at the Thought Palace blog, although your initial login to MobileMe is encrypted, the rest of your session is transmitted in plain text. If anyone on your network decides they want to sniff your connection and read your email, there's nothing to stop them.
What AppleInsider's statement boils down to is, "Apple checks that you're a real user when you log in; everything else is sent in the clear between your browser and their servers; and we think SSL would bog down performance without improving security." They couldn't be more wrong about that last conclusion.
You (Should) Get What You Pay For -- To be fair, Yahoo Mail and Hotmail also fail to use SSL beyond your initial log in, while Google only recently added complete-session SSL to Gmail as an option. But that's no excuse for Apple's decision. Yahoo Mail and Hotmail are free services, while we pay $99 per year for MobileMe. Call me demanding, but I expect more from a commercial service. Google now offers SSL for free, and it's almost always an option (or default) for commercial Web services offering mail.
There's also another subtle, but important, flaw in Apple's handling of user authentication. As noted by Alfke, the secure authentication page points to auth.apple.com while the rest of MobileMe uses the domain me.com. By breaking the bond between the digital certificate used by SSL to verify a domain, and the domain where most of the interaction takes place, users are vulnerable to redirection attacks as highlighted by the recent DNS vulnerability (see "Apple Fails to Patch Critical Exploited DNS Flaw", 2008-07-24). DNS can also be poisoned on a local network, where an attacker floods a network with responses for non-secure domains: say, a hotspot where you're logging in.
A bad guy can hijack the me.com domain temporarily and redirect you to a malicious site without affecting your login experience, since you will still be authenticating to the unaffected apple.com domain. While I doubt many bad guys will completely replicate the MobileMe Web interface, a common attack method (and one I demonstrated using Wi-Fi at the recent DefCon hacker conference) is to redirect you to a malicious Web page, which quickly attacks your Mac and then forwards you back to the real me.com before you notice.
(Apple does mark its authentication cookie, stored in the browser, with a secure flag. This token, which is used to maintain a persistent logged-in state, is only sent to auth.apple.com via SSL. This avoids sidejacking, a technique that formerly worked with Gmail and other Google services until the company wised up and made sure tokens were as protected as passwords. See "Sidejack Attack Jimmies Open Gmail, Other Services," 2007-08-27.)
Good News, And Protecting Yourself -- While there's a reasonable, if small, risk someone might sniff your connection when you are out in public, the odds of a redirection attack are extremely low. And although MobileMe's Web interface is essentially insecure, the other MobileMe services (except iDisk) are properly protected.
When you set up your MobileMe email account, it defaults to a secure connection, and in testing iCal, I found both the push and manual synchronization process appears to use SSL. Using a sniffer on my own system, I was unable to access the contents of any synchronizing calendar entries or email. iChat authentication is also secure, and MobileMe installs digital certificates to enable secure chats with other iChat users - unlike AOL Instant Messenger and many other free instant messaging options. Note that if you use iChat with MobileMe encryption enabled, but you correspond with an insecure AIM user, that iChat connection is still insecure.
Although I don't need to use it often, since I'm never far from my Mac or iPhone, I love the new MobileMe Web interface. But since I'm most likely to use it on insecure systems and networks, like Internet cafes when traveling internationally, I'll have to skip the convenience and stick with more secure options until Apple decides to support SSL properly.