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."
Once you're signed into Gmail: Settings -> Always use https -> Save changes
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.
After me, say it slowly: intents and purposes That way it actually makes sense.
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.
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.
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.
This is true, except for every wireless access point the attacker can access -- like the ones where people sit in a coffee shop and check their e-mail.
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
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.
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.