Where we’re going, we don’t need SSL

Read a funny thing on DaringFireball:

AppleInsider 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

Hmmm, sounds awfully fishy. If the page is over plain HTTP, then it will have a lot of trouble making requests over HTTPS. So I went over to AppleInsider to read for myself:

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.

“Unnecessary panic,” eh? What exactly is “authenticated handling of JSON?” Authentication does not provide confidentiality, especially given that just about everyone is typically accessing the net over an unencrypted (or trivially encrypted) wireless network. Sorry folks, this is perfectly rational panic. For $100/year, encrypting my contacts and email is a reasonable expectation.

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.

Yes, it would slow things down, but it would also improve security. Significantly. This is total BS.

One other advantage held by MobileMe in terms of security is that Apple runs the entire show. There’s no third party ads being injected into Apple’s MobileMe apps, no external scripts introducing search results, alerts, or buddy lists that could potentially intercept secure transactions with the server, nor any opportunities for Adobe Flash, Microsoft’s Silverlight, or other potentially vulnerable plugins to expose unforeseen security threats. A simplified trust relationship equates to stronger security.

Hmmm, sort of, except this is greatly exaggerated. Gmail doesn’t have external widgets either. As for smacking around Flash and Silverlight, it’s a little bit vague and gratuitous.

Thankfully, DaringFireball catches this:

Update 2: Looking at traffic with [tcpdump], it appears to me that nothing other than your initial authentication/login is encrypted. All the XMLHttpRequest data, both reads and writes, appears to be sent as gzip-compressed plain text. This is not secure at all.

Yes, good catch, but you don’t even need the low-level tools here. Just use Firebug or Safari Web Inspector to see which requests are being made, and note that, unsurprisingly, everything is over plain HTTP. And, if you try https://www.me.com, you get a bad certificate (from Akamai).

Apple, I’m a big fan in general, but this is pretty pathetic, and AppleInsider, that’s some shockingly bad reporting.


Posted

in

,

by

Tags:

Comments

6 responses to “Where we’re going, we don’t need SSL”

  1. Michael Janke Avatar

    So which is more pathetic, Apple, for not encrypting the data, or Appleinsider, for covering Apple by making up complete garbage for excuses?

  2. Michael Janke Avatar

    So which is more pathetic, Apple, for not encrypting the data, or Appleinsider, for covering Apple by making up complete garbage for excuses?

  3. […] Adida calls out Apple for the poor security of its MobileMe web applications and AppleInsider for its misguided […]

  4. […] Adida calls out Apple for the poor security of its MobileMe web applications and AppleInsider for its misguided […]

  5. […] Adida calls out Apple for the poor security of its MobileMe web applications and AppleInsider for its misguided […]

  6. […] You can find more technical details on the Benlog blog. […]

%d bloggers like this: