51–60 of 356 posts
Is there another application besides the FF extension to dump the packets and process them? How does this work? EDIT: Sorry, I asking specifically how this FF extension works.
libpcap http://github.com/codebutler/firesheep/blob/master/backend/s...
Wow, good work. And pretty scary- imagine what one could do with this on any college campus.
This is kind of a big deal. Not a whole lot of people are aware of this vulnerability and among those who are it's likely only a small subset that knew how to exploit it until now. I suspect all of the coffee shops in the college town where I live will have people using this starting tomorrow. I've personally been working from cafes and tunneling everything through SSH for years, but in my experience almost no one el…
To where? I suspect it's to a server, VPS, or similar, and the connection is unencrypted from there to its endpoint. This being the case, could someone with a server on the same subnet be running a browser remotely (or even just tcpdump) and doing a similar thing with your logins?
(This is just some thinking out loud and I may be totally wrong - correct me ;-))
You can slightly reduce the dangers stated here by logging out immediately after you are done doing whatever it is you are doing. This will make the captured session useless. The best solution is of course to get a VPN acct and use it when you are at free/open wifi spots. I use WiTopia (www.witopia.net)
This is kind of a big deal. Not a whole lot of people are aware of this vulnerability and among those who are it's likely only a small subset that knew how to exploit it until now. I suspect all of the coffee shops in the college town where I live will have people using this starting tomorrow. I've personally been working from cafes and tunneling everything through SSH for years, but in my experience almost no one el…
I've personally been working from cafes and tunneling everything through SSH for years To where? I suspect it's to a server, VPS, or similar, and the connection is unencrypted from there to its endpoint. This being the case, could someone with a server on the same subnet be running a browser remotely (or even just tcpdump) and doing a similar thing with your logins? (This is just some thinking out loud and I may be t…
The explanation I've always heard for not using HTTPS 100% of the time is that it puts an substantial load on the server, and for many sites it's overkill. Setting aside the subjective topic of "overkill" ... how much more CPU-intensive is it to serve pages over HTTPS compared to HTTP?
You can amortise the session setup cost by ensuring the HTTPS session caching is enabled on your server (in Apache, the directive is SSLSessionCache). This will let subsequent connections from the same client re-use the same SSL session.
Nice . A solid demonstration to show next time your webmaster doesn't want to set up SSL everywhere. That said, the current cartel-like setup of certificate authorities (protection money and everything!) makes SSL annoying and expensive if you want the browser to not have a fit. Especially for small-scale projects. But there's really no excuse for larger sites.
You can get SSL certificates for free for one domain, and they work with all browsers (except Opera, IIRC). Also, you can use Perspectives for Firefox, which I think is much better than the current system.
This is kind of a big deal. Not a whole lot of people are aware of this vulnerability and among those who are it's likely only a small subset that knew how to exploit it until now. I suspect all of the coffee shops in the college town where I live will have people using this starting tomorrow. I've personally been working from cafes and tunneling everything through SSH for years, but in my experience almost no one el…
I've personally been working from cafes and tunneling everything through SSH for years To where? I suspect it's to a server, VPS, or similar, and the connection is unencrypted from there to its endpoint. This being the case, could someone with a server on the same subnet be running a browser remotely (or even just tcpdump) and doing a similar thing with your logins? (This is just some thinking out loud and I may be t…
What can an end user do to minimize this? This exploit is for insecure Wifi networks- so only using encrypted Wi-fi or Ethernet would seem to remove this attack vector. Is there a real risk that someone (besides the government) can see your cookie?
So remember to logout.
VPN is really the best overall option.
The explanation I've always heard for not using HTTPS 100% of the time is that it puts an substantial load on the server, and for many sites it's overkill. Setting aside the subjective topic of "overkill" ... how much more CPU-intensive is it to serve pages over HTTPS compared to HTTP?
The cpu load can be mitigated with frontend https accelerators or proxies (think nginx as a load balancer doing the https). The real problem is the first connection. Browsers don't fall back to https, if nothing answers on http they'll give an error. If the first connection is over http then a man in the middle attack can succeed.
There are ways to work around this, if the non-https site immediately redirects to the https version and a "secure cookie" (https-only) is exchanged afterwards.