Is Apple’s MobileMe Secure?
August 22nd, 2008
Daniel Eran Dilger
A recent article presenting how MobileMe works was been roundly criticized by at least three different bloggers. While the original article did not primarily address MobileMe security, the statements made about MobileMe’s security do warrant some additional detail and clarification. In contrast, much of the criticism was wildly overstated to the point of actually misinforming users about the actual state of MobileMe and email security. Here’s a look at what’s involved.
Inside MobileMe: Web 3 and Web Client-Server apps
MobileMe’s Web App Data Transactions are not SSL Encrypted.
I enjoy reading John Gruber’s excellent Mac resource, the Daring Fireball. It initially stated, “[Inside MobileMe: Web 3 and Web Client-Server apps] reports that the MobileMe web apps supposedly do use SSL, even though you don’t see ‘https:’ URLs or the ‘secure’ lock icon in your web browser.” However, the referenced article did not ever state or even suggest that MobileMe’s web apps use SSL or other forms of encryption when accessing the web apps for email and other services, outside of login and account settings. Gruber corrected the remark after being notified of this.
For the record: Apple’s MobileMe desktop email can be secured via encrypted SMTP and IMAP; Apple presents details on how to ensure this is set up, as users may not have this enabled by default. Address Book and iCal sync on Mac OS X is secured automatically when it transacts with Apple’s server cloud. Windows apps use the same security when syncing their data via Outlook through iTunes for Windows. The iPhone and iPod touch also support encrypted email and all push messages are also secured via encryption.
However, the MobileMe web apps are only secured by SSL through the initial login authentication session and again only when users access their account information to do things such as change their password, update their billing information, or order additional services. Outside of that, all email, calendar, and contact data that is exchanged between the web client and the cloud is not encrypted, and can be sniffed by anyone with access to the network (below, click to enlarge).
What Unencrypted Web Apps Mean for Users.
This means that as you send email, read emails, create new calendar items, view calendar events, and view contacts, that data is being sent in the clear across the Internet between the web browser and the cloud. This does not mean that if you access your email, anyone who might be sniffing traffic could intercept your account information, your login, your credit card information, or change your password. They also could not access anything you did not access yourself, so creating an email does not automatically allow them to read through your contacts, for example.
MobileMe’s limited SSL protection on its web apps presents a real (albeit unlikely to be widely exploited) security hole. However, it is important to note that Microsoft and Yahoo provide the same, limited level of SSL protection for their web services as Apple does; both Yahoo Mail and Microsoft’s Live Hotmail send data in the clear after the initial login. Google has just started offering SSL protection by default for Gmail (below, click to enlarge).
A followup article recommended that Apple should use the same IPSec-type of security for its MobileMe web services as it does for desktop sync. Other critics have noted that because Apple charges $8.25 per month for MobileMe, it should provide a better level of security than Microsoft or Yahoo and at least match Google. At the same time, it is important to recognize that adding SSL encryption does not automatically or even fully secure email.
Apple’s secret “Back to My Mac” push behind IPv6
SSL is Not a Panacea.
Blogger Jens Alfke, who works for Google, also took the MobileMe article to task. Alfke wrote that Apple’s MobileMe apps not only do not perform data encryption, but also leave open the potential for rogue hackers to perform DNS forgery or phishing attacks that SSL could help prevent, or at least flag as a problem for the user when they occur.
For example, a user trying to access webmail at me.com could hypothetically be redirected to a fake me.com by a bad DNS server, Alfke wrote. With SSL in place through the entire transaction, the user should at least be warned that the impostor me.com site did not match its known certificate. Without SSL, MobileMe web apps could therefore theoretically fall prey to a man in the middle attack, where all transactions were passed through a malicious user’s third party control for tampering or viewing. Additionally, Alfke theorized that the web apps themselves could be replaced entirely by a fake site that pretended to be MobileMe in an Invasion of the Body Snatchers scenario.
There are two problems with these scenarios. Alfke’s assumption that MobileMe’s “unauthenticated JSON exchange” could be easy to exploit, allowing redirect via bad DNS, is based in conjecture not fact. In response to his posting, Andrew Jaquith of the Yankee Group pointed out “there are lots of ways for two parties keep rotating secrets on both sides of the wire without disclosing them. See, for example, RFC 1938. I don’t know exactly what Apple is doing with JSON, but dismissing it just because it isn’t encrypted doesn’t prove anything.”
Jaquith also described why SSL is not good for “verifying that software is ‘genuine’ or that a website is what you expect,” as Alfke claimed in dismissing Apple’s security architecture for its MobileMe web services. Jaquith presented a scenario that would result in “a supposedly sniff-resistant [SSL] session that is still nonetheless 100% hosed.”
Security through False Assurity.
On top of that, even in cases where SSL could identify that something bad was happening, the only protection SSL really provides is to throw up a warning about security certificates that most non-technical users browsing at Starbucks would likely just click through to dismiss before happily giving away their credit card info, thinking they are safe because they are interacting with the “SSL” icon on for a website.
When Apple transitioned from .Mac to MobileMe, users were presented with a SSL warning related to mac.com being redirected to me.com, and nobody seemed to even notice. SSL warnings are similarly not going to secure users who do not understand the security issues involved when they are sent to me.info or me.192168.com, or redirected by a malicious DNS to a server pretending to be me.com but failing the SSL check.
Therefore, the benefits of adding SSL were greatly overstated by some critics, who also failed to even consider its drawbacks and limitations. If Apple simply added SSL, it certainly would, as stated in the original article, provide a “false sense of security that distracts from real security threats.” At the same time, the original article also understated the value SSL would provide web browser users. Adding SSL security throughout MobileMe’s web apps, particularly those that deal with private data, would likely provide benefits that overshadow the added overhead. Despite that, it would not “secure” email for users, as described below.
Never Cry Poppycock.
While the original article was not purporting to be a tome on security, another response to it claimed special expertise in security. However, the author not only greatly overstated his case, but also resorted to unprofessional language in demeaning and dismissing the whole of an article just because he took issues with a minor portion of it.
Rich Mogull’s “MobileMe Web Interface Insecure, But Other Apps Get It Right,” published by Tidbits, provided some interesting comments on the subject, but began with an unnecessarily arrogantly overstatement of criticism that misstated the point and the context of the article in order to attack it as “patently false” “technobabble” “poppycock” and so on.
Mogull didn’t contact the author of the original article prior to writing about what he claimed was so wildly inaccurate. In addition, his own presentation is flawed and overstated in ways that are far more misinforming than any disputed details in the original article.
Consider the Context.
“Being able to inject executable code into a system from malicious sources is a primary security problem. For that reason, web apps that transmit data using JSON have to authenticate with the server and regularly perform security handshakes to ensure that the data being sent back and forth is indeed coming from and going to a trusted source.”
Mogull not only ignored that context, but only linked to the second page of the article, where the quote appeared without its immediate context. This enabled him to present that the comments on how JSON is secured were entirely about “why SSL was unnecessary,” which was not the point of the text at all.
Quibble vs Patently False.
The article presented that there was “unnecessary panic among web users who have equated their browser’s SSL lock icon with web security;” that is accurate. While SSL encryption provides an additional layer of security, is not infallible. SSL security requires faith in fallible architectures that have regularly published vulnerabilities. Suggesting that SSL would be a panacea for webmail is false for a number of reasons: SSL can be spoofed; the browser only presents a cryptic warning when that happens, which many users would not know how to handle if it were being spoofed; and the larger fact that even SSL-secured web email is not really secure.
The original article also correctly pointed out that SSL could provide a “false sense of security that distracts from real security threats.” Users who think that SSL web-based email is secure and therefore appropriate for sending confidential information are in for a rude awakening. Email is not secure, and carefully securing part of the email transmission is like only locking three doors of your car. It’s better to understand that thieves can take anything in your car rather than to lock three doors and assume that you can leave valuables on your seat that cannot be taken.
Mogull is arguing that Apple hasn’t provided a functional lock on the driver side door of its webmail service, ignoring the fact that Internet email has no locks on the tailgate or the rear doors at all. This is penny wise and pound foolish security, and can be judged as the “patently false technobabble poppycock” that he quickly used to dismiss an article that was only touching on one aspect of security in a larger piece that was really addressing how MobileMe works as a service and the future potential it holds out.
Mogull’s reply was entirely about security, but it delivers the wrong message. It’s not just easy to quibble about some of Mogull’s details; his primary argument that the original piece was ridiculously wrong is just false, primarily because he overstates it in such an over the top, arrogant way.
SSL is Not Evil.
Having said that, the original article did understate the value SSL can add in securing webmail. SSL is useful in protecting users at the point where they will be most vulnerable when checking webmail, as they are more likely to be at a public terminal or perhaps using unsecured public WiFi when using the web rather than desktop clients (which are secure using encrypted transmissions) or an iPhone (similarly secured).
SSL web apps would provide MobileMe users a similar level of security; Apple currently does not present this throughout the entire webmail session, only when the user authenticates and if they enter account details to change their password or order new services, as noted previously. With SSL, webmail addressed to other MobileMe users, as well as access to one’s own contacts and calendar would be very secure. Email to other domains would continue to be exposed, unencrypted, as it crosses the open Internet.
Sending email is like sending a postcard: anyone intercepting the postcard on its way to the post box, from there through the mail system, or on the way to the recipients mailbox will be able to read what’s written on it. Encrypted email is more like a letter written in code inside of a security envelope: it would be far more difficult to view its contents. However, SSL email only provides security for part of the trip; it’s like carefully guarding your postcard until you drop it in the mailbox. This will prevent casual eavesdroppers from seeing what you’ve written, but won’t protect you from having your postcard read from that point on, because it is wide open throughout the rest of the trip.
In addition, when using a public computer or improperly secured WiFi network, the SSL security provided to a webmail user can’t be trusted. A public PC is just as likely to have a spyware keylogger installed (if not more so) than a malicious hacker listening in on the transmission remotely. Your emails could therefore be spied upon before they were sent through the secure SSL pipe to the cloud. Similarly, using an unsecured WiFi connection opens a user to security issues that far outweigh having your email transactions possibly sniffed.
Additionally, across the industry there are few webmail providers who deliver greater security that Apple’s MobileMe. Google just recently added SSL, while Microsoft and Yahoo provide similar security to Apple’s web interface in MobileMe: SSL encrypted authentication and account protection (you can’t change your password in the clear on MobileMe, only in an SSL session).
Doth Protest Too Much, Methinks.
So while SSL isn’t worthless, it does not present the bulletproof panacea that Mogull suggests it would in his over the top, excessively arrogant, one-sided attack piece. While the original article’s understatement of the benefit that SSL could bring to Apple’s MobileMe webmail could rightly be criticized, it did not say that the existing webmail service was secure. Instead, it said email was not secure and shouldn’t be trusted, and that SSL could provide webmail users with a false sense of security.
Mogull presented this in a mocking, simplified paraphrase as, “we think SSL would bog down performance without providing security.” He then concedes that he has overstated his own arguement by agreeing that SSL would have a limited impact on securing users, saying, “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.”
Mogull could have presented his last paragraph by itself, essentially warning users that MobileMe’s web interface exposes them to unlikely but theoretically possible dangers, and explain that Apple’s expanded use of SSL could help secure its webmail service from some of these kinds of attacks. Instead, the solution he demands would only provide limited benefits to users while providing that suggestion that webmail is more secure that it really is in practice. This is far worse of a problem than acknowledging that email is simply not secure and should not be treated as such.
Like reading RoughlyDrafted? Share articles with your friends, link from your blog, and subscribe to my podcast (oh wait, I have to fix that first). It’s also cool to submit my articles to Digg, Reddit, or Slashdot where more people will see them. Consider making a small donation supporting this site. Thanks!