NotQuiteLeet.com

I was trying to explain security differences between webmail pages in a discussion with colleagues recently.

I set up a trial .mac mail account and used my existing gmail account for comparison.

I was shocked to discover that the .mac webmail login page isnt even a secure page (https://). The web address is http://www.mac.com/WebObjects/Webmail.woa/689.

Now if you change http:// to https:// it redirects back to the http://. This is confusing because the .mac security policy clearly says “When you log in, .Mac uses industry-standard SSL encryption to protect the confidentiality of your member name and password.”

So apparently the SSL connection is only for the authentication process, not the actual page itself. This is an unfavorable process from a security perspective.

Google’s Gmail loads for me by default https://google.com/accounts/…

Both webmail pages do return an http:// after login SSL though.

So why do people pay for .Mac mail (a hefty price at that) when it is proven that .Mac mail isnt as secure as gmail, or other readily available email services via the web interface?

A better question is why in the hell does Apple support SSL through the Mail client (Apples own email client), but not through the web interface?

Are the Apple cult consumers really this blind and ignorant?

Does any apple supporter or advocate actually care about the integrity and quality of Apples products?

This is very poor form by Apple.

---

Update

So there seemed to be some confusion on the topic of discussion. I do write posts to bait people in, but in this instance it seems I wasnt as clear on addressing the issue as I should have been. Some people dont see past the problem or implications with the problem statement. They simply try to disprove the literal statement.

So when I say .Mac webmail isnt secure, it is because the entire page isnt a secured SSL session. Only the username and password is secured via SSL. However, how do you know the page sent to you when you type in webmail.mac.com is from Apple? There is no certificate verifying this.

So, as described in this https tutorial since the page is not offered to you initially via https, you dont know who you are submitting your username and password to.

one piece of important information that you do want secured: the address (URL) of the web page that will accept, validate and process the userid/password that you enter. Theoretically, if the web page into which you enter a userid/password was sent to you via HTTP, it could have been intercepted and modified along the way. A bad guy could have changed the URL that validates the userid/password to one of his own making.

For example, the Gmail web page that validates your userid/password is “ServiceLoginAuth”. If a bad guy intercepted the initial login page, this could be changed to something like http://www.badguy.com/stealuserid.html.

What has just been described is called a “Man in the middle” attack.

The practice of only securing the sensitive data and not the entire session or page is a highly controversial one.

Security is mostly a philosophy, but not putting the extra effort in to securing an email account people actually pay for is sad, especially when Yahoo and Google are free. Its not like Apple doesnt have the server capacity to do it. iTunes store anyone? My goodness they are the #3 music retailer in the US and its all done online, so lets try not to use the “server processor/overhead” reasoning.

You can read more on the concern of this practice on Opera’s site , and on MSDN.com.

I think the best conversation piece is by Brian Krebs for the Washington Post

You must be logged in to post a comment.