... 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.
....
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.
That's wrong. If you don't serve the static page (HTML and all) with SSL, then what's stopping someone from intercepting the traffic and injecting a backdoor written in JavaScript into the application? The application can then make JSON requests as normal, but secretly send the private data elsewhere.
I actually don't think anything (besides the login process) is encrypted. You were probably looking at the gzipped responses and thought it was encryption (I did the same thing at first too)
You're right.... My initial sniffs were done with a quick run of tcpdump captured to a file and doing a quick search for obvious clear strings, but upon further closer inspection, I saw the gzip headers.
Further investigation through a real packet sniffer with proper decodes (Ethereal in this case) showed up the plain clear text on-the-wire, which was not entirely surprising (since as I said, many assumptions were made in this article without the benefits of an actual packet trace).
Comments
I'm actually in Silicon Valley.
I really hope that IP address-to-location is wrong or that could explain some of the slowness with MM.
... 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.
....
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.
That's wrong. If you don't serve the static page (HTML and all) with SSL, then what's stopping someone from intercepting the traffic and injecting a backdoor written in JavaScript into the application? The application can then make JSON requests as normal, but secretly send the private data elsewhere.
I actually don't think anything (besides the login process) is encrypted. You were probably looking at the gzipped responses and thought it was encryption (I did the same thing at first too)
You're right.... My initial sniffs were done with a quick run of tcpdump captured to a file and doing a quick search for obvious clear strings, but upon further closer inspection, I saw the gzip headers.
Further investigation through a real packet sniffer with proper decodes (Ethereal in this case) showed up the plain clear text on-the-wire, which was not entirely surprising (since as I said, many assumptions were made in this article without the benefits of an actual packet trace).