|Submitted by mikeperry on Thu, 08/14/2008 - 18:24|
About a week before my talk, Google announced that they are "making security easier" by providing people with the option of using only https for gmail. I think this "fix" is still broken for several reasons.
First off, the average user will not set this pref. They have been trained that "https in the url means it is secure". Even if they do see it, they will likely read the help for the option (which informs them https is slower), and think to themselves they do not need https always, but really only sometimes. They will decide that for those instances where they "know" they need security (such as when they use open wireless at the local coffee shop), they can just type 'https://mail.google.com', login via 'https://www.google.com/accounts', get redirected to 'https://mail.google.com', and this will be enough. Of course the reality of the situation is that in this case, their 'GX' cookie is still marked for transmission over regular http, allowing it to be stolen in an automated fashion.
There is no reason why Google should not be able to set the ssl bit on the 'GX' cookie in this case, especially given that they already have logic to redirect users back to https after the login bounce. Doing this would not only make things intuitive for how people expect to interact with websites, it would also save them SSL horsepower for instances where people really do only want security sometimes (though I have a hard time believing this applies to anyone who really understands the situation, and believe that this is just a hidden tax on ignorance).
Second, the pref is only currently available to "vanilla" gmail users. Users with accounts on Google hosted domains cannot set this pref at all as of this writing, and the domain owners need to cough up $50 per seat to set this pref across their entire domain.
Third, the setting does not apply to other Google services, which can still be hijacked by an automated tool. Moreover, as Nick Weaver pointed out, an attacker can also redirect users to other google services, and leverage even a "secure" gmail user's google.com SID and LSID cookies to obtain access to their Google docs, Blogger, Picasa, and Google finance accounts. Support for this has not yet been added to my tool, but I will accept patches. For an average Google 'hosted domain' company, TONS of fascinating and valuable information can be found in their Google documents.
So while the Gmail team may claim they have "made security easier", I think they really did not take usability into account when they implemented this feature, and the Google apps team still has a long way to go in general.
UPDATE: 8/21/08 9:00pm Pacific
Gmail is now setting the 'secure' bit on their 'GX" cookie for users who start out in https via the login page. However, it is still possible to redirect these users to http://mail.google.com, and cause the login system to demote their GX cookies back to insecure.
Additionally, users who start out in http, but later decide they want ssl security by navigating to https://mail.google.com still do not get their cookies set as secure. To me, this seems to be the most intuitive way to provide security, and I describe the process in more detail in this blog post.