Slashdot Mirror
A Good Reason To Go Full-Time SSL For Gmail
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."
Or else someone could hijack my accBILL GATS SI TEH DEVLI!!!!!!!!!
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?
The capability to access Gmail over SSL is not new. Perhaps not too many people know about it, but that does not make it new.
The real "Libtards" are the Libertarians!
Once you're signed into Gmail: Settings -> Always use https -> Save changes
For info on the new setting and how to enable it, see the Gmail blog post.
$_ = "wftedskaebjgdpjgidbsmnjgcdwatb"; tr/a-z/oh, turtleneck Phrase Jar!/; print
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!.
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/ I argue that google should INFER that the user wants to be SSL-only, at least until they explicitly log out.
Test your net with Netalyzr
I agree with your major points, but a small quibble:
if a user MANUALLY enters https://mail.google.com/ I argue that google should INFER that the user wants to be SSL-only, at least until they explicitly log out.
Yes, that's how it's been working for me. I'd rather it always used SSL/TLS regardless, myself, but as long as I remember to type "https://gmail.google.com" in the URL bar before I log in, gMail will stay on SSL until I log out. It's been acting that way for about a year I guess; I used to have to do some much more complicated shenanigans to make it stay encrypted.
Is this the road we're going down? Pseudo-homophones of idiomatic phrases?
Yeah, yeah, grammar pedantry is bad. Nevertheless, this stuff hurts to read.
Can you be Even More Awesome?!
" Mike Perry, the reverse engineer from San Francisco who developed the tool is planning to release it in two weeks."
What is a "reverse engineer?"
Is the product called reverse? If so, it should be Reverse, since names of things start with caps.
- Zav - Imagine a Beowulf cluster of insensitive clods...
Until Google added the option, it never actually set the GX cookie as secure, so you could do an active-hijack of any OTHER connection they make so that it does a redirect to http://mail.google.com/ and spits out the cookie in the clear for the attacker to capture.
Test your net with Netalyzr
Unless you SET THE PREFERENCE, you are insecure, even if you MANUALLY type in https://mail.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/ 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!!!!
Test your net with Netalyzr
I'd say it's a good idea regardless. It's a simple checkbox, turns it on permanently, and it doesn't get in your way. It's quite nice, really.
...oh, wait, this is Slashdot. Forgot. What I meant to say was, um, I can't believe the mindless sheep that are so stupid to believe that not using SSL is secure. They are so very stupid and I hate them. Arrrrrrrrrrg they make me so very mad. And Google sucks for not including twenty-hojillion-bit PGP/GPG encryption entirely in Javascript so I can use better encryption because SSL sucks so much and I hate it and if I don't have you in my keyring you don't matter. Stupid people-who-aren't-me. Where does everyone else get off not being as smart and clever as I am? I hate them all.
...there, do I fit in now?
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
If I direct people to mail..com via http it forwards them to the insecure version after login. Unfortunately you can't hit mail..com with https and as a result to be secure people who use my Google Apps mail have to type the long drawn out mail.google.com/a/ to connect to it. I can't seem to find a setting anywhere to force security.... I first submitted the https->http thing to Google when I started using it in like 2004.... about damn time they started doing something about it.
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.
Karma: Excellent. 15 moderator points expire sometime.
I switched on this GMail setting right after i realized the danger from reading the Defcon article; I just didn't think Google would be this careless with private data and assumed previously that in some AJAX-y way the actual GMail session data is being encrypted anyway.
Shame on me.
Power corrupts the few, while weakness corrupts the many.
Is probably DNSSEC. Cue Antibozo to explain why (or why not:)
you had me at #!
here.
you had me at #!
On Linux at least. I am unaware of any updates as of yet.
Mike Perry's site might (or might not) be a better source than some random blog post that doesn't even link to it.
I mean it's Google Mail, Google stores your e-mails till all ethernity and will surely hand it out to any dictator waving something which looks like an official document.
It doesn't matter much how secure the login is as the service itself is designed to be a gapping security hole.
Grammar and spelling suffer as a result of a TV-centric culture. Reading better writers will always improve a writer's style and correctness. (Watching less TV is always healthier for the personality and brain anyway.)
you had me at #!
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.
http://lkml.org/lkml/2005/8/20/95
I don't understand why does someone need to prove a security vulnerability by releasing the tool?
By releasing this tool he will make it available for anyone with bad intentions to implement it. Weeks later we will have issues all over the place because we did not teach our grandparents to enable the checkbox in gmail; or the vulnerability is exploited in other webmail clients. By then, the botnets will be hijacking Gmail accounts to send Spam to everybody
So, really, who benefits of the release of this tool?
I have two gmail accounts: A standard one (@gmail.com) and gmail for orgs (@mydomain.org), the first has "always ssl" in settings, but the former has not. Does anybody knows why and if this is going to change?
DNA in your Linux: DNALinux
Now that I've read this tidbit, I'm sure this is how my Gmail account was compromised.
Last week, I noticed some logins from a Blackberry IP, accessing my Gmail via POP3, which I never use. Someone had apparently gone into my account, turned on POP, then set up their phone accordingly. Now, I have to say, my password is completely unguessable (think along the lines of something like %sprTres3005!). Furthermore, my password is not written down anywhere, and has never been used anywhere except Gmail and a couple banking web sites I use. NEVER used on forums, or bullshit misc. online services. Yet, somehow, someone got into my account. I'm convinced this aforementioned tool was how they did it.
I wonder if the Google Notifier for Mac OS doesn't use secure channels, and that's how they got me. The Google Reader Notifier actually does have an option "Always use https" which is good. I don't see that option in the Gmail Notifier, though.
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.
mutt -f imaps://imap.gmail.com
well, yeah, there isn't (other than that ff3 whines a bit when i try to get it to accept my self-signed cert) really a reason not to use it..
What I'm wondering is why GMail doesn't have the same 256bit AES encryption that my spiffy (and lonely) 1-man forum has, in stead of 128bit RC4?
The problem is not with authentication. The password is sent using SSL - however, after that, by default, it drops back to a normal http session, so everything from there on is sent in the clear.
Why this isn't on by default is a mystery to me.
Those using pirated Tinysoft signatures(TM) are a real threat to society and should all be thrown in jail.
How is releasing this tool a good thing or even a legal thing? Geez, maybe I'll do some serious study into biological weapons and release them into the atmosphere and water supply to get people to have better protection from idiotic actions like this. Someone should string the guy up with CAT 5e from the nearest 3G tower.
Does anyone know of hardware crypto cards that will work in Linux with Apache/mod_ssl?
Slashdot: Failed Car Analogies. Amateur Lawyering. Anecdote Battles.
Now, I have to say, my password is completely unguessable (think along the lines of something like %sprTres3005!)
Crap. I was running a dictionary attack that did %sprUno* and %sprDos*, but the Blackberry hacker got in before I got to %sprTres*, I was so close.
'a';DROP TABLE users; SELECT * FROM DATA WHERE name LIKE '%'... if you're reading this, it didn't work.
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.
Google waited for a YEAR before doing anything, and only added the preference about the time when they heard of Mike's talk, "Exploiting 365th day vulnerabilities..."
Its not like google hasn't had ONE YEAR of warning on this!
Test your net with Netalyzr
Why would anyone concerned about privacy use GMail at all???
When Google was nailed cold for driving past a No Tresspassing sign to take "Street View" photos of a family's private residence, Google responded in court by saying, "complete privacy does not exist".
Google's kow-towing to the Chinese gov't to help them censor Chinese dissidents are profusely documented.
Why would you want anything to do with such a heinous company?
Do you really think that Google Incorporated gives a rat's ass about your privacy? While Google's founding may have had some idealistic and good-hearted mindsets behind it, currently Google is just another for-profit corporation out to make as much money as possible. Your privacy matters only if it impacts the bottom line.
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
Look under "Settings" --> "General" then at the very bottom it says "Always use https". (It doesn't mention SSL so searching the page for SSL turns up nothing).
The Firefox extension Better Gmail also has the option of forcing all gmail connections to use https. I'm not sure if it completely protects against attacks like this, but it would be interesting to see once the tool is released.
Is there a single good reason why Google doesn't force people to use SSL? Like, unless you're in North Korea were it is prohibited or something like that, you have to check a big red box saying "Allow use of insecure http protocol" ? Why make it opt-in security ?
I really don't think you understand.
You *WANT* these tools in the hands of web developers. You want the developers of all of the sites you visit to have these tools and to be able to use and test them. Application security is constantly changing, especially on the web, and we developers *NEED* to stay on top of it. Would you feel more comfortable browsing sites where the developers DO or DON'T know about these tools and howto use them?
Wanna know what the first thing I did when I got home from DEFCON was? I hacked one of my web applications (that I *thought* was secure, using all of the modern conventions we use for site security). And guess what! My applications will have better security after I learned different ways to hack apps. I might make greatly different security decisions, knowing how easy it would be for an attacker to do X, Y or Z.
Hackers have better ethics than you give us credit for.
From the summary and skimming the comments and article real quick, I understand that this isn't anything more than a man in the middle attack coupled with an everyday Replay attack?
If its just that, welcome to the internet! Nothing to see here, move along.
Apparently you didn't understand a thing in the article. The exploit described here does not allow anyone to hijack your GMail account or compromise your password. All they can do is essentially "peek over your shoulder" wile you are reading your email, as long as your session is active. Once you close the session, the intruder loses access together with you.
If your account really got hijacked, look for reasons elsewhere. This has nothing to do with it.
Actually, they could impersonate you and do anything you could do short of actually entering your password. Since you have to enter your password to change it, for example, they couldn't change your password. However, by sending that session ID cookie, they could fake gmail into thinking they were you.
Furthermore, it's possible that the session ID could work even after you've clicked "Log out". I don't know if gmail checks for this (anybody else know?). If it's deleted from your browser but gmail still remembers it, you're still vulnerable. That would be an example of bad design, though: the old session ID shouldn't work after you click "Log out".
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
*you: So your going to stop doing the insecure thing right?
*Him: Buying horse porn with other people's ID's? Nah, I don't care if people know it's me, it's just too expensive.
"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."
Unfortunately not available for anyone who has their own domain's email hosted at google :(
Using SSL for everything is too expensive in terms of computing resources. Gmail gets a staggering amount of traffic as it is, I don't know that they could handle all of it being run through the SSL hardware. I'm just happy the setting is there at all.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
It doesn't appear that the e-mail interface has the same SSL "always on" option as regular Gmail. Too bad.
it may be a corruption, but it's expressive. it's good english and "intents and purposes" is basically redundant. right?
why is intense purposefulness nonsensical ?
> I'll tell you what it's not for, then you'll understand why I can never go back to Seaworld.
Troy McClure? I remember you from so many films I can't even remember them all!
I haven't seen the SSL feature on Google Apps for Domains, thou I am sure if you pay them lots of money a year this feature is enabled.
At least my personal email is safe, who really cares about my business email... -_-
Or Google could just turn it on for everybody and let people opt out if they're stupid.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
gmail will just have to use the non https server to forward the requests for login pages to the https server automatically and do this for all their services that require logins... then you won't have to rely on users setting a preference box... they'll have no choice.
Donald 'Duck' Dunn: We had a band powerful enough to turn goat piss into gasoline.
Someone out there may be reading all of my spam without me knowing.
Intents and Purposes. Sounds redundant and in fact it is. After the Norman Conquest of Britain, it became customary to use both the Norman (French derived) and Saxon words in certain phrases so everyone would understand. It lingers on to this day especially in legal terms. Cease and Desist. Will and Testament. Intents and Purposes.
None of them can see the clouds; The polished wings don't care.
Session hijacking is not a new vulnerability and it is surely not a problem that only the gmail users face. All websites that use sessions to identify users between requests are vulnerable to this. The news here is that now script kiddies have access to a tool to do this. Secondly, the website claims that gmail uses this functionality for low bandwidth users. That may be true. But more than that, SSL handshake is a lot more computationally expensive for the server than it is for the client because server has to perform the asymmetric decryption (of the random number generated by the client encrypted by server's public key). A HTTPS server is supposedly 9 times slower than a HTTP server. So, there is another reason why servers avoid SSL by default.
That was Peter Griffin, not Troy McClure.
After switching your settings, you need to either [refresh] the whole page or logout/login for the changes to take effect.
So much for REST design...
For custom domains using gmail for their mail servers this doesn't appear to be added yet. Anyone have more info than I'm seeing about google aps users?
Thanks for the info, I went to my account and changed my preferences, :)
The solution to this problem isn't enabling SSL, it's not using Wireless networks and if you do, make sure you're using heavy encryption. The only way they can steal info is if they can packet sniff and you shouldn't be using any network where your traffic can be sniffed anyway.
"Cease" and "desist" do not mean the same thing. Neither do "will" and "testament," nor do "intents" and "purposes." Use a dictionary to verify.
To start you off: "cease" means "to stop" while "desist" means "to refrain from doing."
blog
I have been using SSL for my GMail connections for quite awhile thanks to the Better GMail FF extension.
EGGGG-zactly. even if you do use SSL wtf is the point if someone gets in between you and the gateway, and sends you a self signed SSL cert, you're still not safe...
I have my gmail sessions encrypted. But whenever I go to google, it's not https. What are the chances of hijacking the session id from there?
so, if my google reader account isn't https, could anyone just log into my general google account and gmail through there...
Unfortunately, that is not enough anymore. SSL without certificate can be hacked. At least we have /. to tell us when our new policies are outdated.
It would be great if Google would dedicate some more time to getting their mobile apps to support SSL. The one for Blackberry is still broken, which could make it a tempting target for hackers. Also, wouldn't a mobile wireless signal be more available to hackers trying to steal accounts?
The GMailSecure userscript has supplied this functionality for my gmail sessions for more than a year.
Good luck educating the general user population about encryption.
"Mit der Dummheit kaempfen Goetter selbst vergebens." - Schiller
You're browser would warn you about that.
The current RFC's for e-mail, also, don't specify any particular encryption as e-mail goes from hop-to-hop. I've found it somewhat asymmetrical that we demand privacy in our bricks&mortar mailboxes, but not in our e-mail. If I walk over to my neighbor's mailbox and start reading, put in some of my own literature (without a postage stamp), etc. I'm breaking some serious crimes. Credit card companies, utilities, etc. also send private billing, financial, etc. material to me and there's an expectation of privacy in my mailbox. Why the total lack of the same expectation with e-mail? It may well take us in the X- or Y-Gen to reach higher position in government, policy, etc. to make that point. Commerce itself can't be well-suited to basically public or sniffable e-mail.
I monkeyed around with some long-standing applications just this week (after a several year hiatus), gnupg, gpg4win, and the Enigmail plugin for Thunderbird. This stuff should really be "standard equipment" on everyone's desktop at this point. My problem is that my stodgy Boomer relatives can't overcome the barriers in setting this stuff up, and most other people just don't care. There's a sort of digital nudist culture out there, showing very little interest in a little privacy.
In fact, 0.6.3.7 fixed it already, but the latest version also sorts out some account switching issue... and while you're restarting Firefox, why not update your NoScript and Flashblock extensions as well.
Should invading one's peaceful neighbours be opposed, or rewarded with trade deals?
So basically, to secure my users, Google Apps want me to pay $50 per user, per year. I have 5 users that use my domain, so this is $250.00 per year. Just to give me SSL which they give to their non-domain users for free.
This is on top of limiting how many aliases I can have per user (and trust me, the + aliasing solution is pretty useless with the number of big name sites who do not accept it!)
So... can anyone recommend a replacement for Google that will give me mail and calendars?
and i am surprised more email providers haven't done the same. Why hasn't google made ssl for every action the default and allow people to opt out if they need to be using unsecure for some reason?
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion
Comment removed based on user account deletion