Re: MobileMe Webmail Security — There Is None
‘Prince McLean’, writing for AppleInsider:
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. 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 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.
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.
It’s pretty clear to me from this description that (a) McLean doesn’t know much about data security or HTTP, and (b) the system he’s describing would be patently insecure. And unfortunately, the actual system is just as insecure as I was afraid it was.
The most glaring problem is that, since the main page resources (HTML and JavaScript) aren’t loaded over SSL, there’s no way to tell whether they’re genuine. By now everyone ought to be aware of DNS forgery attacks ; if the coffeeshop where you’ve gone online has an infected WiFi router, it would be nice to know whether its DNS record for “me.com” points to Apple’s servers or to a phishing site. But without SSL there’s no way to tell. Obviously, if you’ve loaded a hacked forgery of me.com’s web-app, any assurances made about “authenticated handling of JSON exchanges” are completely pointless, because your JSON exchanges are probably going straight to a pwned server in Uzbekistan.
(You may object that the initial login page is SSL-protected. It is, but unfortunately it’s at a completely different domain, auth.apple.com. A DNS attack on MobileMe would operate by leaving auth.apple.com alone, so you’d be handed off to the fake server after logging in.)
After writing the above, I got curious enough to dissect the traffic myself. So I used HTTPScoop to sniff while I viewed a couple of emails. Not only is there no SSL authentication, but the requests and responses aren’t even encrypted at all. I could easily read the plaintext of the email messages right in HTTPScoop, which means anyone else on my LAN (or any admin at my ISP or workplace) could easily have read them too. Oops.
The takeaway from this is that MobileMe’s web apps (at least email) are quite insecure — they won’t protect you against DNS forgery or phishing attacks, and they leave your email traffic wide open for others to read. I would avoid them if at all possible and access your MobileMe content via good old SSL in real desktop mail and calendar clients (such as Mail.app and iCal), rather than blindly trusting Apple’s pretty-looking web apps.
(You may raise a second objection, that most email traffic is sent across the Internet unencrypted anyway. But even with unencrypted email, it is much, much easier to eavesdrop on (or alter) traffic over a LAN, especially wireless, than it is to intercept Internet backbone traffic between ISPs. It’s the difference between attacking weak, easily accessible infrastructure plugged in by some baristas with little computer experience, vs. hacking into large commercial routers secured in data centers and run by experts.)
[Disclaimer: I am not a security guru. But I’ve spent quite a bit of time over the past year studying data security and cryptography, and implementing some of the techniques; and honestly, it doesn’t take a Bruce Schneier to simply run a packet sniffer and notice plaintext email traffic.]
August 18th, 2008 at 2:16 AM
It should be noted that, until recently, GMail did not default to SSL either.
What’s particularly unfortunate about this story is that 1) unencrypted e-mail still (in 2008!) is far from a rarity; 2) you are, in this case, paying (far from little) for unencrypted e-mail, i.e. this is a self-proclaimed “premium” service — and one that just got launched in its newest branding/iteration at that; 3) McLean/Dilger, in his unfortunate tendency of being overconfident of his preconceptions, presents his assumption that there may not be any security issues as fact.
Given that, according to your packet sniffing, even the data itself isn’t encrypted, one can only conclude that the author failed to do even the slightest bit of verifying this assumption of this.
August 18th, 2008 at 2:59 AM
I think you should qualify your comments to point out that you would also never download software from a developer’s site that wasn’t protected by SSL because some hacker might have spoofed their server in order to give you a Dashboard Widget or Firefox plugin that steals your identity and infects your Mac with spyware, just as you fear might happen with fake MobileMe apps. Of course, a similarly malicious server could just as well have an SSL badge. Most users wouldn’t know the difference, or know what to make of any warning that popped up.
You also would never say your credit card number over the phone when ordering a pizza because somebody might be listening into your unencrypted phone conversation. Right.
Of course, if somebody has the capacity to sniff your local network traffic, you have already been compromised. They’re probably also going through your house taking DNA samples so they can clone you and replace you with a fake you.
The level of pseudo-security you want to layer on MobileMe not only makes little sense, but is in all the wrong places. If Apple really wants to secure email, it should do it using certificate based signing and encryption right on the client before transmitting it.
Arguing that the entire app needs to be SSL-ed is silly. Saying that I “don’t know much about data security or HTTP” is also a great way to introduce your “email must be highly secured for 25% of its journey” spiel, but it’s a bit too much.
Come on, this sentence makes no sense:
“Obviously, if you’ve loaded a hacked forgery of me.com’s web-app, any assurances made about “authenticated handling of JSON exchanges” are completely pointless, because your JSON exchanges are probably going straight to a pwned server in Uzbekistan.”
Invaders of the MM Body Snatchers. This is the kind of stuff I’d expect from CNET writers. How about just sticking to explaining why you think SSL would help protect MM users from people who are smarter than them and want to read their emails. I don’t think SSL would help things in that area, and it’s not because I “don’t know much about HTTP.”
August 18th, 2008 at 3:04 AM
I also need to point out again that I never claimed MM does encryption of data. I only addressed authenticated JSON exchanges between the client app and the server, which use typical cookie passing to make sure that they are not being sent to Uzbekistan.
Unless of course, the Uzbekistanis write a convincing MM set of web apps and surreptitiously spoof MM subscribers into visiting their site rather than me.com.
Of course, if somebody has the capacity to sniff your local LAN (or Starbucks WiFi), they can probably also poison your DNS, and you’d never be the wiser, visiting sites you thought you knew. More Body Snatchers! It’s all so very scary.
August 18th, 2008 at 6:42 AM
I would think right now some manager at Apple is asking some engineer “How long would it take / How much would it cost to switch MobileMe to SSL?” and to do it if it were trivial or even minimal cost.
That they haven’t yet means it ain’t trivial or minimal.
But they have to do it, that much is clear. Perhaps by the December — “a service we are all proud of by the end of this year”.
Cheers,
Colin.
August 18th, 2008 at 7:38 AM
“You also would never say your credit card number over the phone when ordering a pizza because somebody might be listening into your unencrypted phone conversation. Right.”
That’s not analogous at all to mobile me. That’s more like being afraid of someone sniffing the email at the ISP level where it’s unencrypted. If you’re worried about that, you should be PGP/GPG’ing your emails anyway. Then even if you’re password is compromised no one can read the contents of your mails (although they can delete them. And calendar information isn’t necessarily broadcast in plaintext, so if Apple wanted to protect it completely, they could.
A webmail client is more like ordering a pizza in a crowded room by shouting your credit card number to the person for everyone to hear. It’s trivial for people in your local, untrusted environment to eavesdrop.
SSL is better for security. I agree with you it’s not a -ton- better, but it’s a little better.
August 18th, 2008 at 9:21 AM
Prince McLean writes: “Unless of course, the Uzbekistanis write a convincing MM set of web apps and surreptitiously spoof MM subscribers into visiting their site rather than me.com.”
You are unfamiliar with how man-in-the-middle attacks work. The rogue server would merely have to pass along the packets to the real MM site, and then pass back the results. It would also be in a position to doctor or forge messages in either direction. In the context of email and calendars, though, man-in-the-middle is overkill; just snooping on the LAN is sufficient— and easily done with any old laptop using just the software that’s built into MacOS.
August 18th, 2008 at 9:50 AM
@Prince McLean: Please go take a course in web application security and then come back and re-read your article. You will see how ignorant your statements on security in MobileMe sound.
August 18th, 2008 at 10:09 AM
Prince McLean wrote:
This is a bit disingenuous. First of all, both of you have demonstrated lacking in the computer security knowledge department- Jens is just being honest about it. The fact is- you both are right, in particular areas.
While it is true that using SSL for a full email web app is only protecting a portion of the email, since once it’s relayed to other servers it won’t be encrypted anymore. However, Jens is also right that the most likely point of attack will be that last mile. Which network is more likely to be compromised, Cicso’s backbone or your average home WEP wifi network? Sure, the former happens from time to time, but the latter is happening continuously every day. Furthermore, who is more likely to be interested in snooping your email? J. Random Hacker, or your jealous ex?
Also, the “e-mail isn’t secure anyway” argument makes more sense when you’re talking simply about SMTP (outgoing email) connections. An email webapp, however, does more than just send outgoing email, it reads incoming email too. I’m much more worried about insecure incoming email than outgoing emails (which I can control, and encrypt when necessary). How many banks and other online services send password reset codes in plaintext to your email? A hacker who can snoop your incoming email has access to a lot more information than one that can only capture your outgoing SMTP traffic.
Finally, your characterization of someone who worries about these things is unfair. It is trivial to eavesdrop on people’s connections, especially in a public WiFi environment, and you don’t even need to compromise a router to do it. All you need to do is sit down and run a sniffer. No DNA need be collected.
For $99/year, I would expect a bit higher level of security.
August 18th, 2008 at 12:42 PM
But Madcap, that’s the point. If a jealous ex is after your personal info, SSL on MobileMe isn’t going to lock things down, particularly if they have the capacity and resources and access to snoop your local LAN traffic. That kind of threat probably also has access to your PC, so all bets are off, and SSL on your webmail isn’t going to isolate you from that.
The real intent of the “SSL on MM” discussion is that users are under threat by that J Random Hacker, which is what I’m pointing out is a bit unrealistic.
This article goes on to suppose that hackers of the Orient will be writing a fake MM suite of apps in order to dupe MM subscribers, and that only SSL can prevent such malicious DNS redirection. Bu that’s ridiculous. It’s not that I’m too ignorant to know what Man in the Middle attacks are, but that’s not the argument presented here.
I’m not defending Apple’s engineering as being NSA-class security, I’m saying its a consumer offering that takes reasonable steps to authenticate users’ transactions. I was originally misquoted as saying that MM uses SSL internally somehow, which I never stated.
Experts (and I’m fully aware there are plenty of them who know far more than me about the subject) are often content to (as Khurt Williams of OpenID above) simply make arrogant dismissive gestures rather than point out or explain what’s wrong. That leaves me to defend what I stated and clarify that I didn’t say what critics have shoved in my mouth.
I’m happy to be corrected when I’m wrong, but don’t expect to post asinine attacks that call me a moron for saying things I didn’t, and demand that Apple’s consumer offerings should attempt to secure people from their spouses using technical solutions to social engineering problems without getting a response.
August 18th, 2008 at 5:15 PM
“Of course, if somebody has the capacity to sniff your local LAN (or Starbucks WiFi), they can probably also poison your DNS, and you’d never be the wiser, visiting sites you thought you knew.”
And that’s exactly what SSL is good at preventing.
It’s becoming more clear that you know just enough about computer security to be dangerous…
August 18th, 2008 at 5:39 PM
Except that the only protection SSL provides is to throw up a warning about security certificates that most users at Starbucks would 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 a website.
.Mac users were presented with a SSL warning related to mac.com being redirected to me.com, and nobody seemed to even notice. You’re telling me that SSL warnings are going to secure them when they are sent to me.info or me.192168.com by a malicious DNS?
If you’re exposed to bad DNS and LAN ine sniffing, you’re fucked. No amount of making fun of me is going to save your clients either, Tom.
August 18th, 2008 at 6:47 PM
Here’s the thing, people…
SSL is good for preserving confidentiality. What it is NOT good for is verifying that software is “genuine” or that a website is what you expect. Just because an SSL session looks all right (i.e., the browser doesn’t bark about certificate errors) doesn’t mean that it IS all right.
Here’s an attack method that would be guaranteed to be “secure” according to Jens and Tom:
1. Convince an SSL certificate authority to issue you a certificate for the domain “me.com.”
2. Make sure the issuing certificate authority is ALSO one whose public certificate is automatically installed in everyone’s browser. Any of the 132 “trusted roots,” for example, stored in the Apple System Roots keychain would do nicely. Here’s one: “NetLock Minositett Kozjegyzoi (Class QA) Tanusitvanykiado,” from Budapest.
3. Poison the upstream DNS for your target population and divert all traffic for me.com to your domain and fake webapp. Make sure all of the traffic is encrypted so that Tom and Jens are happy.
4. Guess what? Because the SSL certificate was issued by a trusted authority, AND the certificate itself is valid, your victim’s browsers will never bark.
There you have it. A supposedly sniff-resistant session that is still nonetheless 100% hosed. It is a man-in-the-middle SSL attack, and it works because of the fact that ALL browser makers embed the list of their trusted certificates into the browser. All an attacker needs to do is persuade an issuer to “go rogue.”
The scenario I’ve described isn’t very hard to imagine. If you work for a corporation that uses, for example, a Finjan web appliance, you are probably already subjected to this already because your employer is inspecting your web traffic as it goes through their proxy. Finjan and appliances like it have a feature called “transparent SSL termination and re-encryption,” which is a fancy way of saying “man in the middle.”
Tom: I wouldn’t discount Apple’s “unauthenticated JSON exchange” technique so easily. Have you looked at the algorithm? I have not, but 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.
Prince: the “SSL is slow” argument is really lame. SSL adds a little overhead at the beginning of the session (during the session handshake). But ongoing crypto operations after the session is established aren’t very taxing at all.
And one more thing: this “snooping the local LAN” argument makes no sense at all. SSL traffic doesn’t magically terminate itself at your home router. It terminates in the browser. Snooping your wife’s SSL session while you are both at home would just turn up gibberish ciphertext.
As for what Apple should do here — I agree completely that they should encrypt all session traffic by default. But the lack of SSL doesn’t mean that they are any more (or less) to susceptible to phishing than a site that does use it. Apple should ALSO start supporting extended-validation SSL (EV-SSL) because it would help with (but not completely solve) the man-in-the-middle “rogue CA” problem.
Sorry for the long message. But just about everybody is a little bit wrong here.
August 18th, 2008 at 10:44 PM
Andrew Jaquith:
Step 1 of your scenario is where it falls down. As soon as someone proves that an issuer has “gone rogue”, the major browser vendors will issue security updates yanking that CA’s cert from their browsers. That, or they’ll add rules revoking the particular rogue issues with assurances the CA has cleaned up its security policies.
As for the web filters with SSL filtering, that typically requires (for transparent operation), that IT departments manually install CA certs from the web filter manufacturer (and, usually, ones specific to that company’s particular installation of the filter) on every machine on the network. Otherwise, you get the self-signed certificate, or non-existent CA warning. If your implication was that this would be an easy way for, say, public access terminals to implement man in the middle attacks and steal customer data, you’re totally right.
August 19th, 2008 at 1:45 AM
While gmail used to never default to ssl, they at least supported it if you went to https://mail.google.com - since specifying it in the URL works, all my gmail bookmarks include the magic ‘s’, so for all I know, they still default to insecure. Mobile Me on the other hand gives me a 404 if I add the magic ‘s’. FAIL.
August 19th, 2008 at 6:28 AM
I see valid points in the 2 arguments, however:
0) If you’re using a WLAN with WEP you are hosed anyway.
1) Who’s sniffing your LAN, anybody ever hear of a switch? You can sniff your own traffic, that doesn’t mean everyone can. If someone is actually port mirroring or something then you are in much bigger trouble than just having your email read.
2) Your hypothetical rogue site could easily have a certificate, most users don’t ever look at a certificate to see who issued it, etc.
3) Yipes! This webpage ain’t secure! All the stupid stuff in my post was probably inserted by someone else!
4) Not that many sites use EV-SSL and it costs a lot to get those certs. I think people are not accustomed to relying on extended validation and they won’t until it is more common.
August 30th, 2008 at 7:57 AM
MobileMe Mail, Address Book and iDisk use gzipped connections (Accept-Encoding: gzip, deflate) between server and browser in order to update its page(s) with content; MobileMe Calendar, however, uses plain-text connections!
While I think the likelihood of anyone snooping on Internet traffic containing data associated with me is minimal (top-level routers would be difficult and unlikely to snoop, and I would hazard a guess that absolutely no-one is likely to listen in on my Ethernet connection between my DSL and computer), common sense would have to prevail, where I would have to decide whether or not to use the service despite its design.
And I would expect that you would have to, too! Don’t expect Apple to fix their service: they are not obliged to.
—tonza
August 30th, 2008 at 12:08 PM
@Tony:
Gzipping offers zero security, since it’s trivial to decode (Wireshark and other network protocol sniffer/analyzers do it automatically)
Yes, it is unlikely that someone is physically snooping your home network or a backbone internet router, but that’s only one possible attack vector. Your DNS could be hijacked any number of ways (drive by pharming, the recent DNS exploit, etc), or you could be using a shared WiFi access point.
And of course the “unlikely” argument essentially amounts to “security through obscurity”.
August 30th, 2008 at 3:16 PM
Sorry, I hadn’t been tending to the comments here.
@ “Prince McLean” (which isn’t his real name, btw; I don’t know why he’s using a pseudonym) — Re. “This article goes on to suppose that hackers of the Orient will be writing a fake MM suite of apps…”
Of course I supposed no such thing, only that hackers could intercept and/or modify MobileMe traffic.
This statement came after your having been advised several times by me and others to please go and read up on Man-In-The-Middle attacks. “Prince”, I can only assume from this that either (a) you don’t care enough about computer security to read a Wikipedia article or two; or (b) you did read about it but failed to understand it; or (c) you did understand it but are deliberately making untrue statements.
Either of those possibilities puts this below the level of discourse I’d like to have here.
August 30th, 2008 at 3:20 PM
@Tony — “I think the likelihood of anyone snooping on Internet traffic containing data associated with me is minimal”
If you’re at home, I would agree. But, as I’ve said above, public WiFi networks are a different matter. It’s like the comparative risks of getting your pocket picked (or catching flu) at home vs. out in public.
September 2nd, 2008 at 2:35 PM
FYI: via John Gruber: this is a perfect example of a real exploit against non-SSL-secured webmail.
“A tool that automatically steals IDs of non-encrypted sessions and breaks into Google Mail accounts has been presented at the Defcon hackers’ conference in Las Vegas […] Even though when you log in, Gmail forces the authentication over SSL (Secure Socket Layer), you are not secure because it reverts back to a regular unencrypted connection after the authentication is done. […] This makes it possible for an attacker sniffing traffic on the network to insert an image served from http://mail.google.com and force your browser to send the cookie file, thus getting your session ID. Once this happens the attacker can log in to the account without the need of a password. People checking their e-mail from public wireless hotspots are obviously more likely to get attacked than the ones using secure wired networks.”