Slashdot Mirror
Firefox Extension HTTPS Everywhere Does What It Sounds Like
climenole writes "HTTPS Everywhere is a Firefox extension produced as a collaboration between The Tor Project and the Electronic Frontier Foundation. It encrypts your communications with a number of major websites. Many sites on the web offer some limited support for encryption over HTTPS, but make it difficult to use. For instance, they may default to unencrypted HTTP, or fill encrypted pages with links that go back to the unencrypted site. The HTTPS Everywhere extension fixes these problems by rewriting all requests to these sites to HTTPS."
noscript has a means of doing this on a per-site basis. Wildcards are accepted.
Then again, if you don't trust the NoSript author after the controversy, this might be a good alternative. I figure NoScript is under more scrutiny than any other extension and the author learned his lesson.
For those of you without google ... http://www.eff.org/https-everywhere
Oh wow, this is awesome. I've used greasemonkey scripts with facebook but it's pretty ugly, seems to load the http page before the https page. This sounds perfect. Here's the link https://www.eff.org/files/https-everywhere-latest.xpi which is missing from TFS.
It can't work unless these sites already have an https version. If they redirect all 443 traffic to 80 like /., then it does nothing. It might work for facebook since it has a couple pages that allow https, but I'm sure things like their photo servers are probably http only.
Maybe a link to the addon would be useful in the story?
I don't care about ads on his site.
I care about being forced to update NoScript every few days, each time being forced to load his site. I've got another extension, a Flash downloader that does the same thing. They're both either the world's worst programmers, or they're intentionally releasing updates just to drive traffic to their homepages.
It's also incredibly irritating to get interrupted almost every time I go to restart Firefox!
Please help metamoderate.
That's a subscriber feature.
But most unfortunate thing about FF is how it treats the self-signed certificates. It shows it as an SSL ERROR, to which exceptions must be made for the user to be able to enter the site. Can FF developers think about this fact for like longer than a second? It is not an error to run a site with a self-signed certificate, it is a configuration choice and it provides an important role to the site: encrypted traffic for login and for the data transferred to and from the client.
Why is FF showing this to the users as an error? This is not an error, this is by design and it is a special case of usage.
Because to verify a self-signed cert, every user has to call the site maintainer on the phone. Self-signed certs or Corporate CAs are great for in-house use where the sysadmins can install the certs for everyone, but since FF can't tell whether your unrecognized cert is being used to just feed html data to a user, or if the user is being asked to enter something confidential, it can't make a distinction between a reasonable use for self-signed and a MitM attempt. Since bad admins had been training people to "just click okay on the cert" for half a decade, FF took their warning up a notch and made people jump through hoops before they succumb to a potential MitM.
FWIW, maybe the extra demand will lead to people using free CAs for things like blogs.
It's not just the SSL certificate that costs money. The hosting plan also has to support a unique IP per plan because HTTPS is incompatible with name-based virtual hosting. Specifically, HTTPS requires that the server send the correct certificate before even seeing the Host: header, which means the server has to choose based on the incoming connection's IP address.
1. For classic shared hosting solutions using name based hosting, I can almost guarantee if you hit https:///, you're going to hit someone else's virtual host. Many cheap hosting providers w/ limited public IPs will load up domain names on a single IP/Port, but still provide secure hosting to one domain name (on the same port) for shopping cart checkout under a different domain name. Using such a plugin in this use case would not work so well. Then again, would most "smaller sites" really be worthy of encryption in the first place?
2. Not every site is designed w/ the same content root in http vs https. Switching from http to https may completely break if the file structures under the two virtual hosts (potentially entirely separate in Apache) aren't identical (i.e. pointing to the same directory). I'm not touting that this is a best practice, but would be completely feasable if you wanted to keep specific content from being accessed via http and didn't want to bother with mod_rewrite or equivalent.
To the poster above who says there's little CPU penalty for SSL, SSL may not be taxing on the client, but hundreds or thousands of sessions on a server (especially one hosting an app, DB, and Apache) may be another story. Why is someone's assumed paranoid that someone will see that they're reading about cars or home theater equipment on a forum worth requiring a service owner to scale his hardware to the next level to maintain acceptable performance (assuming this phenomenon is multiplied hundred-fold)?
$ man woman *
-bash:
Facebook's chat feature is http-only. My guess is it was a simple way to keep chat from working on the password reset pages (to prevent chat from stealing focus while typing in a password).
No farking way in hell are our servers going to send you HTTPS responses from our non-HTTPS sites.
Even if there was a way for the client to trick them into doing so, the gateways/firewalls have port 443 closed on those IP addresses.
Stupidest product name ever.
It's one thing to suggest /. _should_ do this (and I think they should, all things being equal), but it's another to say (or imply) it is wrong for them not to.
You might be right. However we do not have to look far (e.g "Thailand Shuts Down 43,000 More Websites", or "FBIs Facebook Monitoring Leads To Arrest In England" both a few stories back) - to see that social network sites like /. are being sniffed, scanned, intercepted and profiles built up for normal citizens all around the world. 43,000 Websites have been shutdown or blocked in Thailand, and it would be naive to think they wouldn' also t sniff plain-text posted on those websites from Thai based IP's to identify problematic Thai citizens, who now may be on government watch list's - just waiting for a visit from local authorities, firing from Gov departments, or any other manner of persecution the regime see's fit to deal out.
It might not be Slashdot's job or responsibility to offer even the most minimum technological security https offers to users - but it may reflect pretty poorly on Slashdot as a technology orientated social networking site - if they do not set a good example in the proper use of technology, who will?
In fact I just researched this, and found a site that sells a cert that 99% of the current browsers accept, for about $70/year (lower when purchased in bulk). Sure, that completely aligns with your statement -- it isn't free -- but your statement sounds more like Jamie Lee Curtis saying "Food costs money, rent costs money, things cost money Louie; you sleep on the couch" than it does "stop buying coffee at Starbucks for a month and it's paid for".
I feel fantastic, and I'm still alive.
Agreed - security isn't all-or-nothing. It is like having a builder refuse to put a lock on a house door, because the house has windows without bars so the lock is just false security.
By all means the browser should communicate the relative security of a connection, but an ssl connection with a self-signed cert is NO LESS SECURE than a non-ssl connection. The errors generated by a browser would imply that the non-ssl connection is actually more secure. Indeed, if you want to mitm a bank you're probably just best off creating a non-ssl connection with the victim, and relaying the traffic to the bank via ssl. I doubt most users would notice the missing https/etc, and the browser won't given them any warnings, since browser designers treat non-ssl traffic as safe - since it is so ubiquitous.