×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

HTTPS Everywhere Gets Firesheep Protection

timothy posted more than 3 years ago | from the mitigating-malicious-mutton dept.

Firefox 77

coondoggie writes "The Electronic Frontier Foundation today said it rolled out a version of HTTPS Everywhere that offers protection against 'Firesheep' and other tools that seek to exploit webpage security flaws. Hitting the streets in October, Firesheep caused a storm of controversy over its tactics, ethics and Web security in general. Firesheep sniffs unencrypted cookies sent across open WiFi networks for unsuspecting visitors to Web sites such as Facebook and Twitter, and lets the user take on those visitors' log-in credentials."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

77 comments

Anonymous Coward. (-1, Offtopic)

Anonymous Coward | more than 3 years ago | (#34330184)

fIRST

Do Not Use Unsecured Wireless (0)

Anonymous Coward | more than 3 years ago | (#34330216)

As simple as that.

And the ISP will sniff you. (2, Informative)

Anonymous Coward | more than 3 years ago | (#34330296)

There's no substitute for end-to-end encryption.

Re:And the ISP will sniff you. (1)

tepples (727027) | more than 3 years ago | (#34335090)

here's no substitute for end-to-end encryption.

I agree. But practically, even with a source of cheap or free TLS certificates, how does one establish end-to-end encryption for passwords on blogs, forums, and the like without paying extra for a hosting plan that includes a dedicated IP address? Name-based virtual hosting on HTTPS doesn't work with pre-SNI clients such as Windows XP.

Re:And the ISP will sniff you. (1)

Lennie (16154) | more than 3 years ago | (#34342612)

Don't use passwords, use OpenID ? I guess you can still hijack sessionids, so that is useless.

But SSL/TLS isn't perfect either. Any root-CA or sub-CA can issue any certificate.

We would atleast still need something like DNSSEC to validate what is stored in DNS. So that we can store in DNS, not just the A- or AAAA-record, but also which CA is allowed to sign your certificates.

Even then, if you choose an external CA, it has pretty much been proven that governments can still get certificates from them.

Do you trust the government of the country where you get your certificates from ?

For the next couple of years, without a DNSSEC-validating client in the browser and some protocols to support it, we are pretty much fucked.

RFC 4398 (1)

tepples (727027) | more than 3 years ago | (#34342898)

We would atleast still need something like DNSSEC to validate what is stored in DNS. So that we can store in DNS, not just the A- or AAAA-record, but also which CA is allowed to sign your certificates.

But by the time you're using DNSSEC, the domain registry is already acting as an ersatz CA by signing the CERT record (RFC 4398 [ietf.org]) that you have added to your domain. So I agree that DNSSEC is the real answer to TLS PKI.

Re:Do Not Use Unsecured Wireless (0, Offtopic)

Logic Worshiper (1480539) | more than 3 years ago | (#34330508)

I don't give a rats ass if somebody else in the cafe also wants to know the weather, or also wants to read about Linux concepts...

Don't use unsecured wireless for sensitive stuff.

Re:Do Not Use Unsecured Wireless (1)

Anonymous Coward | more than 3 years ago | (#34331148)

This is the kinda post someone who does not live outside their own box and doesnt understand how the rest of the world works, and who doesnt understand the the majority of people have zero idea how technology works.

Re:Do Not Use Unsecured Wireless (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34331180)

I don't give a rats ass if somebody else in the cafe also wants to know the weather, or also wants to read about Linux concepts...

Don't use unsecured wireless for sensitive stuff.

All stuff is sensitive. Would you like to have e.g. your windows updates guid sniffed and used by some middle east or wherever guys later? Then you=them in terms of tracking by certain agencies, etc.

windowsupdate.microsoft.com: To provide you with the best possible service, Windows Update also tracks and records how many unique machines visit its site and whether the download and installation of specific updates succeeded or failed. In order to do this, the Windows operating system generates a Globally Unique Identifier (GUID) that is stored on your computer to uniquely identify it.

Re:Do Not Use Unsecured Wireless (1)

MachDelta (704883) | more than 3 years ago | (#34330916)

B-b-b-but how am I supposed to get on teh intertubes at school? :(

Re:Do Not Use Unsecured Wireless (-1, Troll)

Anonymous Coward | more than 3 years ago | (#34331018)

What kind of school provides only unsecured wireless? How stupid can an admin be?

Re:Do Not Use Unsecured Wireless (2, Informative)

Anonymous Coward | more than 3 years ago | (#34331526)

It's actually pretty common, and possibly even the norm.

You can't just use a pre-shared key, so you have to use WPA enterprise. (a PSK is only slightly better than open, for privacy, if everyone knows it, and not terribly useful for regulating access to the network if you only want school affiliates to use the wireless resources).

Often times you can't use the more common EAP types because the authentication data isn't stored in a way that's friendly to your radius servers.

So now you have to write all sorts of documentation like "download this application that will take over your laptop's wireless card and you'll lose all your old network configs" or "Look for how your wireless card's supplicant configures EAP, and chose EAP-TLS, and then if it asks, select from the list of trusted certificate authorities verisign." Now get this information to all the users without standing around with out hiring a town crier, and hope that users actually read *and understand* the information when they don't even know if they've got a 32 of 64 bit system...

So, while it is simple for you to configure your linksys wireless network at home, it isn't nearly as easy in the real world.

Re:Do Not Use Unsecured Wireless (0)

Anonymous Coward | more than 3 years ago | (#34331948)

In my country all to me known schools and universities only provide secured wireless, wpa2 + mac-filter. Yes, you need an admin for that. And yes, it's worth it.

Re:Do Not Use Unsecured Wireless (2, Informative)

Anonymous Coward | more than 3 years ago | (#34332640)

Enterprise or Pre-shared key WPA? Pre-shared keys are only marginally better than open, if everyone knows the key. If I know the PSK, I can force you to rekey your session then your traffic is unencrypted to me and I can use firesheep on you.

And the fact that they use "mac-filter" leads me to think it is just PSK.

That isn't to say these mechanisms are completely worthless, but they're not super-valuable.

And I stand by my initial statement -- enterprise WPA in a university setting where you don't manage the end stations is hard.

Re:Do Not Use Unsecured Wireless (0)

Anonymous Coward | more than 3 years ago | (#34339700)

My uni uses WPA2 Enterprise with PEAP, and so do several other major institutions in Australia. Our connection details are stored in the staff+students database (I assume this holds all the different hashes needed for different services).

Configuration doesn't seem to be a major issue: there is a collection of how-to guides for different OSs, and with the summary of the configuration details, it is pretty easy to use the GUI tools most OSs provide anyway.

Re:Do Not Use Unsecured Wireless (4, Informative)

bunratty (545641) | more than 3 years ago | (#34332222)

It's not as simple as that. The traffic is encrypted only during one part of the way from your computer to the server, so cookies can be sniffed anywhere from the wireless router to the server. But it is as simple as using HTTPS. Then all traffic is encrypted all the way from your computer to the server, and you also have the stronger guarantee that your computer is talking to the server you think it is, so you cookies cannot be sniffed by third parties. StartSSL offers free SSL certificates to allow any site to encrypt all of its traffic.

Windows XP does not support SNI (1)

tepples (727027) | more than 3 years ago | (#34335114)

StartSSL offers free SSL certificates to allow any site to encrypt all of its traffic.

But you will need a separate IPv4 address for each certificate, which usually means a separate IPv4 address for each domain. Will all Windows XP clients be upgraded to an OS that use Server Name Indication [wikipedia.org] before ARIN runs out of IPv4 addresses? I don't think that's likely.

Re:Windows XP does not support SNI (1)

yuhong (1378501) | more than 3 years ago | (#34340046)

To be more precise, XP's built-in crypto library do not support SNI. While IE uses it, I don't think Mozilla uses it, instead they use NSS instead.

Re:Windows XP does not support SNI (1)

tepples (727027) | more than 3 years ago | (#34341980)

Chrome and Safari also use Windows's built-in crypto library. So unless you want to make your HTTPS site exclusive to Firefox and Opera, or until Microsoft finally shuts down the activation server for XP in 2014, each certificate still needs a separate IPv4 address.

Re:Windows XP does not support SNI (1)

Lennie (16154) | more than 3 years ago | (#34342640)

Chrome does support SNI on Windows XP, they still use the same Windows certificate store, but I don't know if they hacked around the Windows library or just use a different library.

Does browsing wikipedia work now? (1)

CryptoKiller (78275) | more than 3 years ago | (#34330224)

Does wikipedia work with HTTPS Everywhere now? I had to disable it because of all the 404 error messages I was getting.

Re:Does browsing wikipedia work now? (1)

somegeekynick (1011759) | more than 3 years ago | (#34330994)

I did not have problems with accessing Wikipedia, ever. However, the suggestions feature in the search box for Wikipedia as well as Google stopped working ever since 0.2.2 (for me, anyway). 0.9.0 has not rectified this situation.

Re:Does browsing wikipedia work now? (0)

Anonymous Coward | more than 3 years ago | (#34333124)

That was a feature.

Duh? (2, Funny)

girlintraining (1395911) | more than 3 years ago | (#34330302)

Wait, unencrypted signals sent over the air with your password and login is bad? If only someone had told me... /snark

Seriously though: Unencrypted. Open. Network. Come'on guys.

Re:Duh? (4, Informative)

The MAZZTer (911996) | more than 3 years ago | (#34330326)

Firesheep never used login credentials. It never needed to. Session cookies were enough to impersonate another user... so any visit to any HTTP page on any site allowed a Firesheep user to impersonate you on that site in theory (of course if you're logged out this is of limited use, but if you're logged in they can impersonate you without login details).

Re:Duh? (2, Informative)

leptechie (1937384) | more than 3 years ago | (#34330450)

The extension forces requests to be sent over SSL/TLS for all communication, as long as the site supports it. Works on Facebook, even Google searches, so yes this is a useful countermeasure. Of course, it is wholly dependent on the site supporting HTTPS in the first place.

I've tried similar extensions, and Facebook gladly connects over HTTPS when manually instructed to, but reverts to normal HTTP on pretty much any click, this just keeps the connection on HTTPS regardless of the link target. The only downside, specifically on FB but certainly similar problems on other sites: no chat. So there are compromises, but probably worth it.

Re:Duh? (1)

moonbender (547943) | more than 3 years ago | (#34334740)

Does that work for Google, too? In other words, can you simply use the session cookie sent when performing a Google search to log into a Gmail session? The former is typically http, the latter https. I'm aware that you can use https for searching, too, I'm just wondering. Isn't there some kind of policy that segregates https cookies from http cookies?

Re:Duh? (1)

Bucky24 (1943328) | more than 3 years ago | (#34335904)

Having used firesheep myself, I can tell you that it doesn't work to login to gmail. I was able to sniff my own google account (using a separate computer), but was not able to get past my iGoogle homepage. Attempting to go to gmail prompted a login, even using the firesheeped session cookie. I think I may have tried google docs too, and it also required a login, but I am not sure about that one.

Re:Duh? (1)

Lennie (16154) | more than 3 years ago | (#34342662)

Their is also a bug in Chrome when you start up it will connect to the google.com-domain to check for updates and do so over HTTP and the problem with this is, it will also send the normal cookies associated with google.com. Which might give the attacker enough information to get into your igoogle/gmail account.

Re:Duh? (4, Informative)

blueg3 (192743) | more than 3 years ago | (#34330386)

Many of the sites that Firesheep attacks use HTTPS for their login, so you don't send your credentials in the clear, but fall back to HTTP for delivery of content. The point Firesheep attempts to make is that this is not sufficient -- your unencrypted HTTP requests contain the session cookie that your encrypted login obtained. The session cookie is just as useful, as long as you make use of it "soon".

Probably breaks lots of web sites (2, Interesting)

defaria (741527) | more than 3 years ago | (#34330358)

Stated simply, many web sites just can't handle https.

Re:Probably breaks lots of web sites (4, Informative)

oodaloop (1229816) | more than 3 years ago | (#34330468)

Um, no. That would be pretty dumb. IF the site has an https page, it directs to that. If not, it doesn't.

Re:Probably breaks lots of web sites (1)

budgenator (254554) | more than 3 years ago | (#34334482)

HTTPS take more processing power to encrypt and decrypt the traffic, frequently enough traffic flowing through marginally usable server will completely crash and burn if all of the traffic were encrypted; it's like normal traffic would cause a site to be /.ed.

Static vs. dynamic (1)

tepples (727027) | more than 3 years ago | (#34335148)

HTTPS take more processing power to encrypt and decrypt the traffic

This might be a valid concern for static web pages. But the sorts of web sites with which one would use TLS are more dynamic, to the point where they might be called web applications. How much processing power does HTTPS use compared to what the PHP/Python/Perl/Java app and the database use?

Re:Static vs. dynamic (1)

budgenator (254554) | more than 3 years ago | (#34335614)

it's always in addition to what the PHP/Perl/Python/Java uses. On say slashdot you have multiple servers sliced horizontally so each section can be on a separate server if desired as well as vertically so you have web-servers on the outer layer, Database caches in the middle, and the database itself on the inside; or on other sites you have the web-server and database server all on a host shared by ten or twelve virtual hosts. The load that a slashdot can service probably wouldn't be much of a problem going all https, but a shared host would easily get into crash and burn situations.

In addition by how much? (1)

tepples (727027) | more than 3 years ago | (#34336200)

it's always in addition to what the PHP/Perl/Python/Java uses.

But how much addition? Would HTTPS increase the CPU load of a typical PHP blog, forum, or wiki engine by 1%, 10%, 100%, or more?

Re:In addition by how much? (1)

budgenator (254554) | more than 3 years ago | (#34336876)

SSL uses strong cryptographic encryption, which necessitates a lot of number crunching. When you request a webpage via HTTPS, everything (even the images) is encrypted before it is transferred. So increased HTTPS traffic leads to load increases. Why does my webserver have a higher load, now that it serves SSL encrypted traffic? [apache.org]

All servers will display an increased load how ever

In my experience, servers that are heavy on dynamic content tend to be impacted less by HTTPS because the time spent encrypting (SSL-overhead) is insignificant compared to content generation time. HTTP vs HTTPS performance [stackoverflow.com]

yet with web 2.0 type stuff with lots of ajax

Many, very short sessions means that handshaking time will overwhelm any other performance factors. Longer sessions will mean the handshaking cost will be incurred at the start of the session, but subsequent requests will have relatively low overhead.HTTP vs HTTPS performance [stackoverflow.com]

all of the connections are going to kill you. The short answer is 10-20% but YMMV. No idea what happens when you start adding in Google adsense and other third party crap.

Re:In addition by how much? (1)

Lennie (16154) | more than 3 years ago | (#34342722)

Yes, a higher load, but the load will only be increased by a very, very small marinal number. Just have a look at what the Google study had to say about it.

With the right extension we could even speed up loading of the webpages:

http://www.chromium.org/spdy/spdy-whitepaper [chromium.org]

Because HTTP does not currently do multiplexing of multiple streams over the same TCP (or TCP/SSL) connection. The only solution that is has is to open several connections and because we need to use TCP-slowstart it can't utilize the available bandwidth.

Re:Probably breaks lots of web sites (1)

spidr_mnky (1236668) | more than 3 years ago | (#34336388)

That sounds like a big opportunity for a man in the middle to tell you your site doesn't support ssl. That's still fine against passive listeners, but wouldn't it make more sense to it like flashblock and noscript do? Force ssl by default, and if that doesn't work ask the user if he wants to go with plain http. That would at least give you the opportunity to say, "Gee, gmail usually has ssl ..."

How does HTTPS Everywhere do it? (2, Interesting)

Bromskloss (750445) | more than 3 years ago | (#34330360)

Does it parse the webpage you are on and rewrite every link to use HTTPS or, better, does it intercept every request Firefox makes and rewrite that before it is sent?

The reason I'm interested is that I want to create an extension that does rewrites in the latter way described, but don't know how to do it.

Re:How does HTTPS Everywhere do it? (1)

Logic Worshiper (1480539) | more than 3 years ago | (#34330474)

It's pretty simple, you can often force https simply by typing it in the address bar, if the site has some kind https cert set up, it'll bring you to a secured version of the site. https://twitter.com/ [twitter.com] works and brings to twitter securely, as it does for many mail sites. All you have to do is add a character the html string, which isn't that complicated. For it to really be secure, the server administrator has to secure their site.

Re:How does HTTPS Everywhere do it? (0)

Anonymous Coward | more than 3 years ago | (#34334242)

For it to really be secure, the server administrator has to secure their site.

That's one of the things it helps to fix. For sites that are sending content or links to other pages beyond your initial page that you type in https, it tries to force all content as https first.

Re:How does HTTPS Everywhere do it? (1)

Kozz (7764) | more than 3 years ago | (#34330512)

If you don't find your answer in forums, there's nothing stopping you from looking into the extension yourself, in most cases. Take the XPI file,change the extension to .zip (presuming you're in windows) and extract its contents. View source of the .JS files, and there you have it.

Re:How does HTTPS Everywhere do it? (0)

Anonymous Coward | more than 3 years ago | (#34330874)

The latter. They complained that Chrome does not let them hook into the networking component, so a similar add-on is impossible for Chrome. It may rewrite links, too, but that would not protect against external/manually typed in URLs or requests made via Javascript.

Re:How does HTTPS Everywhere do it? (1)

Bromskloss (750445) | more than 3 years ago | (#34341014)

The latter. They complained that Chrome does not let them hook into the networking component, so a similar add-on is impossible for Chrome. It may rewrite links, too, but that would not protect against external/manually typed in URLs or requests made via Javascript.

Excellent! What is the documentation for learning how to do this? Or, as a backup, where in the code for HTTPS Everywhere is the relevant piece of code?

Re:How does HTTPS Everywhere do it? (1, Insightful)

Anonymous Coward | more than 3 years ago | (#34331606)

It does the latter. Requests are intercepted and converted according to pre-defined and user-definable rulesets before being sent.

Apps? (-1, Redundant)

Anonymous Coward | more than 3 years ago | (#34330434)

I use an iPhone - how safe am I when using the ebay or Facebook apps
Do iPhone apps use encryption by default or will firesheep pick up login information from these as easily as it would if I accessed the site using safari?
Or is encryption something that is optional for the app developer - and in that case is there any way of telling which are secure?

Re:Apps? (3, Insightful)

pyster (670298) | more than 3 years ago | (#34331234)

If you are using an open wireless you have the same http/https issues everyone else has, regardless of the device you are using.

Re:Apps? (1)

Don_dumb (927108) | more than 3 years ago | (#34331534)

Thanks but I am unclear do the apps use http or https to communicate?
Is there any way of knowing what security the apps are using to communicate with the service.
This is important to consider as I haven't seen an iPhone app have an option of securing their connection with remote services. Most people use apps for things like facebook and are entirely at the liberty of the apps' security. There is no 'use https' choice if it doesn't do so.

rtfa (0)

Anonymous Coward | more than 3 years ago | (#34330458)

it just forces https on the server (like that other firefox plugin, "Noscript".)

CA's are the problem, not the crypto (1)

muckracer (1204794) | more than 3 years ago | (#34330484)

SSL = Great
SSL + some 600 MITM-Orgs your browser "trusts" = Bullshit

Use HTTPS Everywhere anyway. Great plugin. But forget your much-touted "sense-of-security" because it can't exist in light of the above.

Re:CA's are the problem, not the crypto (3, Insightful)

Logic Worshiper (1480539) | more than 3 years ago | (#34330552)

A self signed certificate would be fine for most of what HTTPS Everywhere does.

End to end encryption is for stuff that really matters, not facebook and other crap that's public to the internet anyway.

Re:CA's are the problem, not the crypto (1)

Steeltoe (98226) | more than 3 years ago | (#34334722)

You can be fired over someone cracking or spoofing your Facebook identity. I would consider that important.

Who decides what security is important, really?

Re:CA's are the problem, not the crypto (1)

tepples (727027) | more than 3 years ago | (#34335184)

A self signed certificate would be fine for most of what HTTPS Everywhere does.

But then how would your users know that your self-signed cert is authentic before installing it into their browsers for the first time? MITM in the wild is a reality [mozilla.org].

Re:CA's are the problem, not the crypto (1)

Lennie (16154) | more than 3 years ago | (#34342738)

DNSSEC is the solution for that, but it will take years before we'll have validating resolves in the browser.

In studies it has been shows, even many DSL-routers block DNS over TCP or large DNS-packets.

Re:CA's are the problem, not the crypto (0)

Anonymous Coward | more than 3 years ago | (#34336178)

The problem is, by only encrypting "stuff that really matters", you're pointing a finger at that data and saying "this is the important stuff". Meaning, an adversary can devote all of his/her time to cracking that and ignoring the unimportant bits. Worse, this doesn't protect you from traffic analysis. Encrypting everything is the correct answer, not picking and choosing.

Re:CA's are the problem, not the crypto (0)

Anonymous Coward | more than 3 years ago | (#34332590)

Yeah, certs are mostly a scam, the better way to go would be to pick 15 random FF clients and read the cert for the page you are going to, if all 15 match (or 12 of the 15, let 3 of them be actively MITM'd) then you are unlikely to be being MITM'd or the MITM attack is so widespread as to be ubiquitous. This way FF only has to trust itself (and its copies on other people's machines). Then Self-Signed certs wouldn't be an issue (unless the site itself is fake (eg. welllsfargo.com).

Re:CA's are the problem, not the crypto (2, Interesting)

Onymous Coward (97719) | more than 3 years ago | (#34334088)

Here's a way of handling certs which doesn't rely on those organizations: Perspectives

http://www.cs.cmu.edu/~perspectives/ [cmu.edu]

Re:CA's are the problem, not the crypto (1)

Lennie (16154) | more than 3 years ago | (#34342778)

I don't know and who validates the response from the Perspectives notaries (the agents in the networks which store this information) ?

And what about my privacy ? Do they store the information about the sites I visit (they probably say they don't).

Maybe Certificate Patrol is a good start:

https://addons.mozilla.org/en-US/firefox/addon/6415/ [mozilla.org]

It works like SSH, everytime you connect it will tell you if something changed since you last connected. It also will tell you what changed.

Exactly the reason Firesheep was created (0)

Anonymous Coward | more than 3 years ago | (#34330676)

This was exactly why the author released this tool, so that some one would fix the security shortcomings within current authentication.

Actions you must take for firesheep protection (2, Informative)

Fnord666 (889225) | more than 3 years ago | (#34330744)

According to the release notes, there are specific actions that you must take to enable some of this protection:

The 0.9.0 release of HTTPS Everywhere is a new beta version designed to offer improved protection against Firesheep. Most notably, it can provide much better protection for Facebook, Twitter and Hotmail accounts, as well as completely new protection for bit.ly, Dropbox, Amazon AWS, Evernote, Cisco and Github. Unfortunately, in order to obtain maximum Firesheep protection, especially on Facebook, you must take two extra steps:

  • Turn on the "Facebook+" rule. You can do that in the Tools->Add Ons->HTTPS Everywhere->Preferences menu. It isn't on by default, because it can cause Facebook Apps to raise errors. We're still waiting for Facebook to fix this, and the chat problem :(.
  • Install the Adblock Plus Firefox extension too, and use it to block the insecure http:/// [http] adds and trackers that Facebook (and other sites) sometimes include.

Re:Actions you must take for firesheep protection (1)

pyster (670298) | more than 3 years ago | (#34331404)

The release notes maybe incorrect, or dated, as it was on by default for me. the amazon rule is not, and has (buggy) next to it.

Most average users don't use addons (0)

Anonymous Coward | more than 3 years ago | (#34330896)

It's back to the problem that most people don't dick around with addons. If you're too lazy to go to https instead of http, I'm betting you don't use addons. 95% of the time I see an average user with addons, it's some stupid facebook or yahoo "toolbar" that they didn't even know they where installing and is now mucking up their system.

  This should have been defaulted years ago. Bandwidth and CPU power are both cheap enough these days that the extra overhead for encryption is a moot point.

14 minutes 58 seconds...... (0)

Anonymous Coward | more than 3 years ago | (#34331276)

Seriously, has this thing hit it's time limit for being a "hot" story yet???
Sidejacking.... NOT new
Use encryption.... NOT new
Time till this story hits a fever pitch with the world and some security researcher (read as some monkey who took an already developed, tested, and researched idea and made it a PLUGIN)starts screaming "OH NOES THE INTERWEBZ HAS THE FAILXORS!!!" ... About another 2 years, just like last time.

All this ranting and raving over this is about the equivalent of saying:
"Hey, you know people can get into your house if you leave the door unlocked?"
OMG. NO, REALLY????
"For real man, every place that has a door can have this problem"

It's stupid, this story is WAY past old, the technology is old, the method is old, there's already been publicly available tools (that are stupid easy to use, on both widows and *nix) out that handle this for like 2 years. Can we please PLEASE stop acting like this is in ANY WAY, SHAPE, OR FORM news? /rant

welcome to: http://www.famalegoods.com The websi (0, Offtopic)

falas105 (1946722) | more than 3 years ago | (#34331504)

welcome to: W W W ( famalegoods ) c o m The website wholesale for many kinds of fashion shoes, like the nike,jordan,prada,****, also including the jeans,shirts,bags,hat and the decorations. All the products are free shipping, and the the price is competitive, and also can accept the paypal payment.,after the payment, can ship within short time. free shipping competitive price any size available accept the paypal W W W ( famalegoods ) c o m jordan shoes $32 nike shox $32 Christan Audigier bikini $23 Ed Hardy Bikini $23 Smful short_t-shirt_woman $15 ed hardy short_tank_woman $16 Sandal $32 christian louboutin $80 Sunglass $15 COACH_Necklace $27 handbag $33 AF tank woman $17 puma slipper woman $30 W W W ( famalegoods ) c o m

Secure cookies (1)

fulldecent (598482) | more than 3 years ago | (#34331542)

Assume sites want to prevent firesheep, and do not want https everywhere. Does secure cookies fix this?

Login via HTTPS, get secure cookie ("the token") . Then on each page load, use this token to sign your request.

This can be done with existing technology, but requires Javascript.

Re:Secure cookies (0)

Anonymous Coward | more than 3 years ago | (#34333870)

They say that there is a security flag you can set so the browser will not send cookies over a non encrypted link. Never used them myself.

If you can access those in javascript then you can use a bigmath javascript library to sign a random number or string the server hands out for each request, then send it back to the server as part of same.

Would noticeably increase back-and-forth traffic and increase time spent signing tokens, because doing security-related math in javascript is slow.

I donno, give it a shot.

Why not HSTS? (1)

Anonymous Coward | more than 3 years ago | (#34335032)

The HTTP Strict-Transport-Security (HSTS) header and its predecessors, X-Force-HTTPS and X-Force-TLS, enable HTTP sites to declare that and how they want to be accessed over a secure connection.
The HSTS header is not recognized by Firefox 3.x. Firefox 4 supports it but without an UI. The extensions ForceTLS and STS UI deal with that, respectively.
These extensions should be merged with HTTPS Everywhere. It's unreasonable to expect people to manually enter all the sites they use, and it's equally unreasonable to rely on the EFF for maintaining a catalog of the web. We need automatic discovery, and we need manual entries too -- for sites that don't use the header, and to avoid that first insecure connection to retrieve the header.

ipod (1)

religious freak (1005821) | more than 3 years ago | (#34338822)

I need to look this up, but does anyone know how to use this on an unjailbroken ipod, or how about the facebook application on the ipod?

I know the dangers and concerns, but I still use unencrypted wifi like all those that don't even have a clue. I suppose I'm the worst of all... but I bet I'm not alone. It really is amazing how a system with so many vulnerabilities manages to stay together and grow for decades :-P

https://twitter.com almost works... (1)

yuhong (1378501) | more than 3 years ago | (#34339812)

https://twitter.com/ [twitter.com] almost works, but I sniffed the packets using Wireshark and unfortunately they still make one HTTP request, which because the session cookie is not marked secure is sent insecurely along with it. I remember reading that it was made using XMLHTTPRequest.

Re:https://twitter.com almost works... (1)

yuhong (1378501) | more than 3 years ago | (#34339902)

Ah, I think that was from days ago. I just checked today using Wireshark again and they fixed it, which means https://twitter.com/ [twitter.com] should be safe now.

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...