little boxes made of words

1. On Mon, Aug 18 at 2am,
   chucker23n (LJ) said —

   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.
2. On Mon, Aug 18 at 2am,
   Prince McLean said —

   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.”
3. On Mon, Aug 18 at 3am,
   Prince McLean said —

   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.
4. On Mon, Aug 18 at 6am,
   Colin Prince said —

   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.
5. On Mon, Aug 18 at 7am,
   Rob said —

   “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.
6. On Mon, Aug 18 at 9am,
   David Leppik said —

   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.
7. On Mon, Aug 18 at 9am,
   http://khurt.myopenid.com said —

   @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.
8. On Mon, Aug 18 at 10am,
   madcap said —

   Prince McLean wrote:

   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.

   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.
9. On Mon, Aug 18 at 12pm,
   Prince McLean said —

   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.
10. On Mon, Aug 18 at 5pm,
    Tom Robinson said —

    “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…
11. On Mon, Aug 18 at 5pm,
    Prince McLean said —

    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.
12. On Mon, Aug 18 at 6pm,
    Andrew Jaquith said —

    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.
13. On Mon, Aug 18 at 10pm,
    Andrew Wooster said —

    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.
14. On Tue, Aug 19 at 1am,
    got nate? said —

    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.
15. On Tue, Aug 19 at 6am,
    william said —

    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.
16. On Sat, Aug 30 at 7am,
    Tony Kavadias said —

    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
17. On Sat, Aug 30 at 12pm,
    Tom Robinson said —

    @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”.
18. On Sat, Aug 30 at 3pm,
    Jens Alfke said —

    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.
19. On Sat, Aug 30 at 3pm,
    Jens Alfke said —

    @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.
20. On Tue, Sep 2 at 2pm,
    Jens Alfke said —

    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.”
21. Name:
    Email:
    Website:
    Name and email are required. Thanks!
    
    [Or log in]    [Or register]

    Or use your OpenID:
    LiveJournal username DeadJournal username Other OpenID URL

    HTML: You may use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>

    Notify me of followup comments via e-mail

Design: Hemingway, modified by Chris Gerlach, further modified by me, Jens.

Entries feed   Comments feed