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."
Like when you read slashdot?
Once you're signed into Gmail: Settings -> Always use https -> Save changes
The password is sent over SSL, the problem is that it will happily send your cookie over HTTP which is for all intensive purposes just as good as a password.
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
Gmail always uses SSL for logins.
Previously if you wanted to maintain SSL for the whole session you had to login via https://mail.google.com/ otherwise it dropped back to http after login. Now you can set it to always use SSL regardless of the URL you visit it from.
Is there any reason to not use SSL every time one sends a password?
Firefox 3, and I think other newer browsers, lie to people by strongly implying that HTTPS with self-signed certificates is far more dangerous than bare unencrypted HTTP.
After me, say it slowly: intents and purposes That way it actually makes sense.
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
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
Mike Perry's site might (or might not) be a better source than some random blog post that doesn't even link to it.
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
That was slashcode fucking up my formatting. It was more obvious when I had line breaks. In addition, I'm aware that making corrections to people's posts causes everyone to immediately jump on your small errors, but actually writing "itensive purposes" is just irritating.
Apparently this is not true everywhere (e.g. Great Britain).
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).
* Q
P.S. If you don't get this note, let me know and I'll write you another.
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.
mutt -f imaps://imap.gmail.com
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.
The Firefox developers are serious security professionals. They have probably attended over two conferences on security, and may even own a copy of "Linux Hacking Exposed". So stop questioning their logic; they have obviously spent centuries longer than you considering this topic.
Anyway, as the article below clearly shows, the only part of SSL that matters is being able to verify the identity of the host. It's way more important than preventing random packet sniffers from seeing your stuff.
http://www.networkworld.com/community/node/31124
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.
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).
Self-signed raise the level of complexity from "passive snooping at any point along the data path" to "active interception of traffic, either directly or via a secondary exploit".
Saying that self-signed certificates are worthless is like saying that a fence at a prison is worthless unless it's electric -- sure, the electric fence is better, and it provides additional security, but the plain old fence is a good place to start, and I don't think a lot of wardens would call it "worthless" just because it can be climbed.
That's not to say that users shouldn't be warned about the lower level of security, but it's a little disingenuous to pretend that a MitM attack is significantly more likely that say, someone getting a perfectly legitimate, CA-signed certificate for a typo-squatting site.
My big beef here is that unencrypted traffic produces no such warnings. If I didn't bother to provide a certificate for my website we'd be talking in the clear, and your browser wouldn't even mention it to you (other than maybe that one-time warning about sending data). Meanwhile if I offer a certificate from an authority you don't trust your browser will act as if I'm trying to steal from you rather than protect you. Email clients are just as bad -- regular email has no integrity guarantees, but S/MIME-signed messages are flagged as bad if the CA is untrusted, in spite of the relatively good security compared to messages with no signature.
The long and the short of it is security is more complicated than an on/off indication, and users will eventually have to deal with that if they want to be secure. I'm not suggesting grandma needs to know how SSL works, but if we replaced with lock with a multi-level system to indicate "plaintext", "signed", "signed and authenticated", "encrypted", "encrypted, signed, and authenticated" -- still a pretty small number of states, all of which could be described in a short hover tooltip -- users could make more informed decisions about the security in place and whether or not is is sufficient for the task at hand.
Correct. The British rule is essentially that unless the quote is a whole sentence the punctuation goes outside the quote marks. But the GP was correct to call foul on the GGP for an attempted pedantic correction that wasn't necessarily true.
Quidnam Latine loqui modo coepi?
There is no fundamental incompatibility. A solution to this was proposed back in 1993. Bizarrely, it's still not a standard. Happily, the "server_name" Hello Extension (which lets the server pick the right certificate for the right virtual host) hasn't changed in years. Internet Explorer 7 supports it. There are patches for Apache that support it, but I don't know if it's in the mainline yet. And I don't know about firefox.
In summary, you can definitely support multiple https virtual hosts on a single IP using IE7 and patched Apache. And the situation may be better than that.
This used to be true, but not anymore. Now there's Server Name Indication - RFC3546, that would allow this. However, OpenSSL (and by extension, mod_ssl) does not support it. GNUTLS does, however (and there's a corresponding mod_gnutls for Apache.
Why is it that everyone piles on this guy for saying "intensive purposes", yet when someone corrects the incorrect usage of "begs the question" English is all of a sudden a descriptive language with meanings that evolve?
Give me Classic Slashdot or give me death!
Actually, it is historical, normal usage to put the period (or comma) inside the quotes, even if the period wasn't in the original quotation. This was originally done for typesetting reasons: putting a period outside the quotes caused type blocks to break. The period inside the quote was better mechanically--less breakage.
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.
An SSL Certificate can match multiple hostnames in SSLv3 and TLS, which are both old enough to be in use everywhere.
There are two methods, depending on what you want (and your level of paranoia): wildcards (match *.example.com) and "Subject Alternative Names" which can match any from a list of domain names.
The subject alt name is incredibly useful, as the certificate for a physical host can enumerate alternative names for each of its virtual hosts, even if they aren't subdomains of the host's domain.
You are mixing up security and identity.
Not really. Had you said that he was mixing up encryption and identity, I'd have agreed, but for secure communication with some other party you need to both secure the channel (encryption) and verify that the other party is who you want to talk to (identity). Without that identity verification step, you're very vulnerable to man-in-the-middle attacks.
There are many ways to handle the identity problem (e.g. by using a shared secret key) but SSL is elegant in that it uses public key cryptography to set up a secret session key and ensure that the other party is who you think they are. That all works great and is straight-forward if you know each other's public keys, but that really doesn't scale. Think about it: how do you find out my public key and ensure that it really is my public key? You've probably not got the time or resources to meet me in person.
There are two solutions to this, both of which rely on adding cryptographic signatures to public keys to allow you to determine whether someone you trust knows the key is right. PGP and GPG use a "web of trust" scheme, and SSL uses "certificate authorities". When done properly, CAs are an excellent solution since they can require really strong proof of identities before signing anything, and there are CAs about who do this sort of thing for real. (HTTPS uses an additional check over basic SSL in that it requires the server to have its DNS name signed into the public certificate, which stops additional types of spoofing peculiar to some types of web interactions.) Web browsers are seeded with the public certificates of CAs believed (through analysis of their published policies) to be well-run.
The problem is that not all CAs are scrupulous. OK, a black-hat operated CA will always be bad, but some others are looking more and more grey due to their pursuit of the almighty buck at all costs. In effect, they're breaking their own policies and hoping that nobody will notice. The only solution for this is to revoke the trust of those CAs who do this, either by getting their master CA to revoke the signature (why do you think CRLs/OCSP is important?) or by removing a particular trust root from browsers. That last option is very much the "nuclear option" since it will harm a lot of perfectly innocent bystanders, but I reckon that unless and until someone is publicly crucified like that, the siren call of the extra cash will win more often than it should.
(Yes, I know I've simplified things a lot. This message is long enough!)
"Little does he know, but there is no 'I' in 'Idiot'!"
"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