“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.”

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.

@ “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.

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”.

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

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.

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.