Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

A Good Reason To Go Full-Time SSL For Gmail

Posted by timothy on Tue Aug 19, 2008 10:26 AM
from the oh-that-hurts dept.
Security Businesses Encryption Google Privacy The Internet Communications
Ashik Ratnani writes with this snippet from Hungry Hackers: "A tool that automatically steals IDs of non-encrypted sessions and breaks into Google Mail accounts has been presented at the Defcon hackers' conference in Las Vegas. Last week, Google introduced a new feature in Gmail that allows users to permanently switch on SSL and use it for every action involving Gmail, not just authentication. Users who did not turn it on now have a serious reason to do so, as Mike Perry, the reverse engineer from San Francisco who developed the tool, is planning to release it in two weeks."
+ -
story

Related Stories

Submission: Gmail Account Hacking Tool by Ashik Ratnani (1341883)
[+] HTTPS Cookie Hijacking Not Just For Gmail 128 comments
mikepery writes with a followup to last month's mention of a security vulnerability affecting Gmail accounts, which it seems understated the problem. "I figure the Slashdot readership is the best place to reach a large number of slacking admins and developers, so I want to announce that it's been 30 days since my DEFCON presentation on HTTPS cookie hijacking, and as such, it's now time to release the tool to a much wider group. Despite what was initially reported, neither the attack nor the tool are gmail-specific, and many other websites are vulnerable. So, if you maintain any sort of reasonable looking website secured by any SSL certificate (Sorry Rupert, you lose on both counts), even if it is just self-signed, you can contact me and I will provide you with a copy of the tool. Be sure to put 'CookieMonster' in the subject, without a space." (More below.)
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

A Good Reason To Go Full-Time SSL For Gmail 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Good thing Slashdot is safe... (Score:5, Funny)

    by Anonymous Coward on Tuesday August 19 2008, @10:27AM (#24659201)

    Or else someone could hijack my accBILL GATS SI TEH DEVLI!!!!!!!!!

  • Just for Google? (Score:5, Insightful)

    by Toe, The (545098) on Tuesday August 19 2008, @10:28AM (#24659235) Journal

    Is there any reason to not use SSL every time one sends a password?

    Unfortunately, the general public still seems entirely uneducated about SSL, figuring that passwords must be secure because they appear as bullets on the screen, right?

  • 3 clicks (Score:5, Informative)

    by pebcak (773787) on Tuesday August 19 2008, @10:31AM (#24659279) Homepage
    Once you're signed into Gmail: Settings -> Always use https -> Save changes

  • Google Announcement (Score:5, Informative)

    by ShadowRangerRIT (1301549) on Tuesday August 19 2008, @10:32AM (#24659293)
    For info on the new setting and how to enable it, see the Gmail blog post [blogspot.com].

  • A few notes... (Score:5, Insightful)

    by nweaver (113078) on Tuesday August 19 2008, @10:32AM (#24659297) Homepage

    Mike Perry did a great public service by making this tool and making it available.

    This attack also works against yahoo mail, hotmail, etc. Just Yahoo, hotmail, etc don't even OFFER SSL, so well, if you use them, your FSCKed.

    And Google has known about this problem for a LONG time. EG, see my blog post from last february! [icir.org].

    Google waited for a year before even giving users the OPTION to be protected when SSL is used, and notice that it was only after they found out about Mike Perry's talk that the option was even added.

    Also, as I argue, they got it wrong. The checkbox is good, but most users don't know about it. But if a user MANUALLY enters https://mail.google.com/ [google.com] I argue that google should INFER that the user wants to be SSL-only, at least until they explicitly log out.

    • Re:A few notes... (Score:5, Insightful)

      by derrickh (157646) on Tuesday August 19 2008, @11:02AM (#24659725) Homepage

      So he's going to release a tool that lets people break into Gmail accounts. And unless you read slashdot, you'd have no idea to go into preferences and flip a switch.

      How is this a public service? For the 99% of the world who dont read SD every day, they're pretty much screwed.

      It's good I'm a nerd and will now flip the magic switch on my gmail account...but it seems like a big f-u to everyone else.

      D

    • Re:A few notes... (Score:5, Interesting)

      by Dolohov (114209) on Tuesday August 19 2008, @12:03PM (#24660761)

      Mike Perry did a great public service by making this tool and making it available.

      WTF? No he didn't. Pointing out the vulnerability is a a public service, yes. Giving a talk where he outlines the problem? Also a public service. Distributing the means for anyone to make use of this vulnerability (ESPECIALLY when so many major vendors aren't prepared for it yet) is not a public service anymore. It's just arming script kiddies. Ralph Nader was able to do plenty of good without going around ramming into Chevy Corvairs to somehow "drive home" the need for a fix.

  • UNLESS YOU CHECK, you are insecure! (Score:5, Informative)

    by nweaver (113078) on Tuesday August 19 2008, @10:52AM (#24659587) Homepage

    Unless you SET THE PREFERENCE, you are insecure, even if you MANUALLY type in https://mail.google.com/ [google.com] always.

    Because unless you SET THE PREFERENCE, google does NOT set the session cookie to be SECURE.

    This is what Mike Perry's tool does: it takes any of your OTHER connections, redirects it to http://mail.google.com/ [google.com] so your browser spits out the session cookie anyway, and then can redirect you back (so you don't know what happened).

    Google's SSL mode for gmail, UNLESS YOU SET THE PREFERENCE, offers you NO protection against an active adversary. And since someone snooping your traffic at starbucks can just as easily inject packets, IT OFFERS NO PROTECTION EVEN IF YOU MANUALLY TYPE IN HTTPS ALL THE TIME, UNLESS YOU SET THE PREFERENCE!!!!

  • Gmail Notifier (Score:5, Informative)

    by triplej3000 (804712) on Tuesday August 19 2008, @10:55AM (#24659635)
    Selecting 'Always use https' breaks Gmail Notifier. Luckily Google has released a patch for this. Here is a link: http://mail.google.com/support/bin/answer.py?hl=en&answer=9429 [google.com]

  • Why can't the whole web be HTTPS? (Score:5, Interesting)

    by thomasdz (178114) on Tuesday August 19 2008, @11:02AM (#24659731)

    I can understand that back in the web's "stone age" (mid 1990s), having HTTPS for every web site would have seriously slowed down all the computers due to CPU usage, but nowadays is there any real good reason that the whole web can't be HTTPS?
    With all the government and ISP snoopings going on, I'm surprised that at least some sites haven't gone that way.
    (or is it that embedded browsers like on cell phones can't do SSL?)

    TDz.

    • Re:Why can't the whole web be HTTPS? (Score:5, Informative)

      by Quietust (205670) on Tuesday August 19 2008, @11:23AM (#24660079) Homepage
      One of the main problems is that HTTPS is fundamentally incompatible with virtual hosts - you connect, do the SSL handshake (and get the server's certificate), verify that the common name on the SSL cert matches the hostname you typed in (to make sure the site is who you think it is, otherwise display big warning messages) and that it is trusted (i.e. complain if it's self-signed), and then you send your HTTP request. The only way it could work would be if an SSL certificate could match multiple hostnames (which I don't believe is the case, though I could be wrong).

      Interestingly, net-wide HTTPS would probably make IPv6 a bit more important (since a great deal of web hosting services put dozens of sites on the same machine and same IP address, charging significantly more if you want SSL due to the requirement of having a unique IP address).
    • Because CA-signed ssl certs cost $$ for often no measurable (as in $$) benefit, HTTPS doesn't work with name-based virtual hosting, and new browsers treat self-signed SSL as evil incarnate.

  • Author's site (Score:5, Informative)

    by Captain Segfault (686912) on Tuesday August 19 2008, @11:09AM (#24659855) Homepage Journal

    Mike Perry's site [fscked.org] might (or might not) be a better source than some random blog post that doesn't even link to it.

  • don't freak out, requires packet sniffing (Score:5, Informative)

    by YesIAmAScript (886271) on Tuesday August 19 2008, @11:13AM (#24659931)

    Yes, this is a vulnerability. But it isn't like every person out there on the internet is going to be able to steal your session cookies in two weeks when the tool is released.

    In order to execute this attack, a person would have to be able to sniff your packets and steal the cookies. And since the vast majority of people on the internet have no ability to intercept your traffic, this means in practice, the average person is pretty safe without having to worry about all this.

  • Cache relevancy depletion (Score:4, Interesting)

    by DuSTman31 (578936) on Tuesday August 19 2008, @11:25AM (#24660125)

    One thing that I find somewhat counterproductive is that browsers do not save files sent over SSL in their caches.

    It's sensible, I suppose, to assume that if something's sent over an SSL channel that it's sensitive and therefore shouldn't be saved, but it would give a speed and bandwidth efficiency hit which would deter usage of SSL for everyday browsing.

    You could, of course, have the HTML transmitted over SSL and the supporting images over plain HTTP, but then the browser will scare people by warning that not all content on the page is secure..

    I think browsers should start looking at encrypting their cache files, so that stuff such as SSL can be accommodated without breaking caching.

  • This is not "use SSL" (Score:5, Informative)

    by blueg3 (192743) on Tuesday August 19 2008, @11:37AM (#24660327)

    The summary (and many, many replies) have it all wrong. The point is not that you need to be encrypting all of your traffic to Gmail (for example) with SSL.

    The need for SSL-encrypting your session was known with sidejacking. If you use SSL for credential exchange but not for the whole session, your session cookie is transmitted in the clear, and an attacker can sniff it and use your session (as the cookie acts temporarily as a credential). Encrypting the whole session with SSL prevents this. This is well-known at this point.

    The subject of this talk was not sidejacking. If the site (Gmail) does not set the secure bit on the session cookie, then your session cookie can be transmitted in the clear, even if all of your intentional communication with Gmail is over SSL! An attacker need only inject a link to the appropriate domain (e.g., mail.google.com) in some other page you request, and the cookie will be sent with that request over HTTP. Only by marking the cookie as secure will the browser refuse to send it over HTTP.

  • I was at DEFCON - the author is confused (Score:5, Informative)

    by remitaylor (884490) on Tuesday August 19 2008, @11:46AM (#24660475)

    The author of this post seems to be really, really confused. There were multiple presentations on ways to hack your Google accounts and Google security flaws, etc.

    There was a presentation on howto exploit Google Gadgets (which have access to your local javascript), a few presentations on Cross-Site Request Forgery (CSRF)(which you can do to send your own HTTP requests as the visitor if you have your own image or iframe on the page), and a presentation on hijacking your sessions if you ever access a site over plain-text (non-SSL), and putting the password page on SSL doesn't help (this requires the attacker to be on your local network!!!!!!!).

    The title of the post sounds like they're talking about The Middler, a Ruby-based proxy by Jay Beale for intercepting all user data on a shared network, such as a coffee shop, where you can get users to go through your proxy.

    If the author is talking about The Middler ... that attacker has to be on your network!!! This is only an issue on untrusted networks.

    Jay Beale's talk was the one the mentioned SSL the most, so I'm gonna guess that the author is talking about that, even tho the article seems to mix everything up.

    To see the descriptions of the actual talks and whatnot, visit the DEFCON schedule: https://www.defcon.org/html/defcon-16/dc-16-schedule.html [defcon.org]

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.