Firefox Extension HTTPS Everywhere Does What It Sounds Like 272
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? (Score:4, Informative)
NoScript has done this for years (Score:5, Informative)
Then again, if you don't trust the NoSript author after the controversy [techjaws.com], this might be a good alternative. I figure NoScript is under more scrutiny than any other extension and the author learned his lesson.
Link? (Score:2, Informative)
For those of you without google ... http://www.eff.org/https-everywhere
Much needed extension (Score:5, Informative)
Re:Link? (Score:5, Informative)
Shouldn't that be https://www.eff.org/https-everywhere [eff.org] ?
Does What It Sounds Like? (Score:5, Informative)
Link (Score:5, Informative)
forcing views of the hompage (Score:5, Informative)
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!
Re:forcing views of the hompage (Score:5, Informative)
From the FAQ [http://noscript.net/faq]:
2.5
Q: I don't like NoScript redirecting the browser on its release notes page every time I upgrade it. Is there any way to prevent this?
A: First time you install NoScript and every time you upgrade it to a newer major version, Firefox opens an additional tab containing the NoScript welcome page, where you can read the release notes, the latest announcements and an introduction to the most important NoScript features (plus a link to this very FAQ...)
If you feel you don't need such heads up, you can disable this feature by clicking the NoScript icon, selecting Options and unchecking "Display the release notes on update" in the "Notifications" tab.
Notice that if the above "fix" doesn't work or, worse, you keep being redirected on the welcome page every time you restart Firefox, chances are there's something (like a buggy extension) preventing your preferences from being saved: you may need to follow this advice, then.
Re:forcing views of the hompage (Score:4, Informative)
He's intentionally driving traffic to his page, but you can disable it easily (it used to require about:config, but it was a boolean that was fairly easy to find).
It is based on NoScript, in fact (Score:5, Informative)
Re:Does NOT work for Slashdot.org (Score:4, Informative)
Re:firefox doesn't really make it easy for the use (Score:3, Informative)
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.
Re:forcing views of the hompage (Score:5, Informative)
set noscript.firstRunRedirection to false
No name-based virtual hosting (Score:2, Informative)
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.
I see two things wrong w/ this... (Score:4, Informative)
1. For classic shared hosting solutions using name based hosting, I can almost guarantee if you hit https:/// [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)?
Re:facebook (Score:3, Informative)
Re:I see two things wrong w/ this... (Score:3, Informative)
No it FARKING DOESN'T (Score:1, Informative)
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.
Re:Does NOT work for Slashdot.org (Score:4, Informative)
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" [slashdot.org], or "FBIs Facebook Monitoring Leads To Arrest In England" [slashdot.org] 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?
Re:noscript? (Score:2, Informative)
No, noscript can't do this. Noscript just changes http to https. If you want more complex rewriting like
http://en.wikipedia.org/wiki/Main_Page
to
https://secure.wikimedia.org/wikipedia/en/wiki/Main_Page
then you need something like this extension.
Of course, it's useless in the case of wikipedia, because no images at all are available from the secure server. The extension will let images through unencrypted, so it's very easy to tell what page you're looking at. You can just go to the image pages and scroll down to "what links here," and the page that appears in every list is the page that the person is looking at.
You can block unsecure content with noscript but articles are unusable without the helpful diagrams and pictures.
Re:CPU overhead (Score:3, Informative)
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".
Re:I see two things wrong w/ this... (Score:3, Informative)
A curious question, that. You're asking what it is worth to the user of a site to justify the demands placed upon the operator of the site. You pose it as "demands upon the server", yet simply visiting a site creates demands upon the server. More people, more demands.
How is asking for HTTPS different from asking for "reasonable page load times", or "video feeds without compression artifacts"? On the user's side, one has little to no influence over (or even knowledge of) OTHER traffic to the site. The answer for the user is, "MY demand on the server is small, what's the problem?".
The only answers on the operator's side are "I want your traffic", or "I don't want your traffic".
The loads on the web server are a bit higher for HTTPS encryption than just passing fat content created by a developer without any common sense of bandwidth consumption.
Now if you're referring to server-side generated content contributing to page load times, then HTTPS isn't helping that provided the same server that is generating is the one doing the encryption.
Re:Self-signed certs are vulnerable to MITM (Score:3, Informative)
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.