On Mon, 15 Dec 2008 00:32:05 +1300 Chris Bannister <mockingb...@earthlight.co.nz> wrote:
> Hi, > > http://www.webmonkey.com/blog/Why_You_Should_Turn_Gmail_s_SSL_Feature_On_Now I can't say that I have a really good understanding of the issues, but I believe that the article is not as clear as it might be. It claims that: "How do you know a connection is secured by SSL? The handy “s” after “http” will tell you. For example, https://mail.google.com is encrypted while http://mail.google.com is not. You can force an encryption by adding the “s” yourself, or by turning on “Always use https” from the Browser Connection settings of your Gmail account." This implies that using the https url is sufficient for security, but Mike Perry, the hacker that the article largely relies on, has taken pains to repeatedly explain that this is not so: "As I presented in my Black Hat and DefCon talks on Securing the Tor Network, it turns out that using https for accessing mail.google.com is not sufficient to protect you from many "Sidejacking" attacks. The 'GX' authentication cookie for mail.google.com is set to be transmitted for any type of connection (http or https). This is the only cookie one needs to authenticate to gmail. This "Any type of connection" property allows an attacker execute a cross site request forgery attack to inject spoofed 'http://mail.google.com' content elements or meta-refresh tags into ANY WEB PAGE loaded by a user. Repeat: the user does NOT have to be using gmail at the time, they just need to have a valid 'GX' authentication cookie from a prior login, and then visit ANY WEBSITE. Upon fetching/executing these injected elements, the browser will transmit the 'GX' cookie in the clear for the load of the spoofed element." http://seclists.org/bugtraq/2007/Aug/0070.html "Vulnerability 2: HTTPS but Insecure Cookies This is the vulnerability I announced in my Bugtraq post last year, and the one I featured in my DEFCON talk. Basically, it revolves around the fact that cookies have two modes: secure and insecure. If a cookie is insecure, a browser will transmit it for plain old http connections, and an active attacker can then inject a set of http images for sites that they want cookies for, and the browser will happily transmit cookies for these sites unencrypted, allowing their capture. This attack can even be automated for the majority of sites without the need for a list of targets (though a list of targets can also work just fine against these sites as well, to capture their cookies for every IP on the network). I describe the automated process in both the core logic post, and the original writeup post of CookieMonster." http://fscked.org/blog/overview-web-mitm-vulnerability-surface > Chris. Celejar -- mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
