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.
Geez. What kind of poorly written site would do something like quietly defaulting to unencrypted HTTP on a HTTPS request.
https://www.slashdot.org/
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.
Saw it on the boingboing and installed it pronto. I use no script, adblocker, and vadalia (tor), along with some conviences addons that I am sure have their own set of security and privacy issues. Not sure why this addon wasnt just a standard feature all this time on all browsers.
"No results found." (returned by Firefox's 'Add-on' search)
"There are 11 kinds of people: those who know binary, those who don't, and those who could not care less!"
...except not "everywhere", just major sites.
... how does this work without risk of compromising the data at the end of the tor route if the webserver won't accept https. I'll be waiting for SPEEDY which looks like a cleaner way of encrypting everything.
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?
What kind of poorly written site would do something like quietly defaulting to unencrypted HTTP on a HTTPS request.
Once the user has logged in, there are three reasons to switch back to HTTPS for any page that doesn't take credit cards or the like:
It can't possibly create an encrypted connection to an unencrypted website, so instead of your connection going client->isp->isp->isp->isp->server(in theory all should be reasonably trustworthy), it is going through somebody elses server first. How is that better?
And what about ssl certificates? They tell the user that an audited organisation has identified that the server is authorised by the owner of the domain. If that system breaks(let's say that HTTPS-everywhere users assume that all https sites are valid without checking each certificate) then it has actively decreased the security of the internet for those users.
So I guess you'd be ok with just telling me your login and password, rather than making me go through the effort to sniff them, right?
So I guess you'd be OK with buying an SSL certificate and an SSL-compatible (unique IPv4 address) hosting plan for every blog, forum, and wiki out there, right?
Firefox itself does not really make it easy for the users or for admins to use https everywhere.
I just made a small site, it's for a business, that runs everything through https, I redirect http to https completely. Firefox 3.6.3 on Windows had no problem running the site. IE on windows couldn't open the encrypted pages, Firefox 3.5 on any GNU/Linux distro couldn't open them either, to fix this, I had to add this to /etc/conf.d/ssl.conf : SSLInsecureRenegotiation on
That fixed the IE and FF3.5 on Linux problem.
Here is the description of this flag from apache mod_ssl directive description page:
SSLInsecureRenegotiation Directive
Description: Option to enable support for insecure renegotiation
Syntax: SSLInsecureRenegotiation flag
Default: SSLInsecureRenegotiation off
Context: server config, virtual host
Status: Extension
Module: mod_ssl
Compatibility: Available in httpd 2.2.15 and later, if using OpenSSL 0.9.8m or later
As originally specified, all versions of the SSL and TLS protocols (up to and including TLS/1.2) were vulnerable to a Man-in-the-Middle attack (CVE-2009-3555) during a renegotiation. This vulnerability allowed an attacker to "prefix" a chosen plaintext to the HTTP request as seen by the web server. A protocol extension was developed which fixed this vulnerability if supported by both client and server.
If mod_ssl is linked against OpenSSL version 0.9.8m or later, by default renegotiation is only supported with clients supporting the new protocol extension. If this directive is enabled, renegotiation will be allowed with old (unpatched) clients, albeit insecurely.
Security warning
If this directive is enabled, SSL connections will be vulnerable to the Man-in-the-Middle prefix attack as described in CVE-2009-3555.
Example
SSLInsecureRenegotiation on
The SSL_SECURE_RENEG environment variable can be used from an SSI or CGI script to determine whether secure renegotiation is supported for a given SSL connection.
I wonder if there are other ways of making this work with my other directives:
SSLEngine on
SSLCipherSuite HIGH:MEDIUM:!aNULL:+MD5
SSLVerifyClient none - I am thinking about switching it to 'require' right now, but will have to test all browsers with it again, but have to do it I think.
Oh, and getting it all to run together with apache httpd with mod_ssl + mod_jk + apache tomcat is quite a hassle.
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. Who is not frustrated by the browser treating self signed certificates as if they are some sort of a disease? They provide an important role - a way to secure communications between the server and the browser.
Can this be looked at, because I am SURE this prevents various sites from using encrypted traffic in the first place and it is a BAD thing, not a good one. All traffic needs to be encrypted, but especially user name/password traffic shouldn't be sent around in plain text.
Name it what it is: an exceptional case of using security to encrypt traffic, a case where the site may not necessarily be what it wants to be seen as, but at least the traffic is actually encrypted. It's terrible if someone comes to your site just to see: SSL ERROR on it, OF-COURSE admins don't want THAT message to be shown on their sites, why do you think so few sites do security properly?
You can't handle the truth.
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.
Tools > Add-ons > Get Add-ons displays only those extensions that Mozilla has vetted. Extensions on third-party sites are not listed there, but they are listed in Google.
Unfortunately. No https for slashdot.org - why not Slashdot? Comments on politically orientated stories from "sensitive" countries does not deserve to be encrypted? You should know better Slashdot
It is not an error to run a site with a self-signed certificate
A man in the middle could insert his own self-signed certificate, decrypting the traffic from your site and reencrypting it with his own key pair, and users would be none the wiser. One workaround is to start your own CA, sign its root certificate with PGP, and distribute that cert to your users to install. But then that starts to depend on the PGP web of trust, which in turn depends on air travel to get keys signed.
...and I use NoScript regularly :)
Still, for those of us who setup systems and browser for other people, a simpler extension like HTTPS Everywhere will help immensely.
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.
Sending your login/pass to an unauthenticated server is not any better than sending it through HTTP. If you have a MITM, he can be faking the website.
If you want secure login, either get an authenticated cert or use OpenID and let the user choose his provider.
Dilbert RSS feed
But this is not an ERROR, this is by design and should come with some warning. But an error? No, if the user knows the certificate and the site this is just a warning.
You can't handle the truth.
It's not an error, it should be a warning. My users will know the site and the certificate number and this IS how I want the site to work, I don't need a CA or an OpenID to do this, it's not wrong to do.
And it is a million times better than sending plain text over any line any day.
You can't handle the truth.
But this is not an ERROR, this is by design and should come with some warning. But an error? No, if the user knows the certificate and the site this is just a warning.
It _is_ just a warning. If the user knows the cert info (maybe printed on paper in front of him), he can verify it and add it to an exception list. I do that all the time for my own test servers. Firefox doesn't prevent people from connecting with self-signed certs, it just makes them think about the ramifications before they do.
Check out this patch if you need to get rid of SSL/TLS errors: link Beware, it was meant to be used on secure isolated networks, it completely disables checking SSL/TLS certificates and will lie to the user telling them all connections are secure.
if the user knows the certificate
How would the user know the certificate on the user's first visit to the site?
Am I the only person getting a 'chat is disabled on this page' bubble everywhere when using this plugin on facebook?
Because of my business case - the site is for users who must be first set up by the site administrator, so nobody can just show up, it's only for known users.
so they will also be notified on what the appropriate certificate is.
You can't handle the truth.
NoScript is overly complex, and so is flashblock for that matter. I view them both as solutions looking for problems.
There is a simple, elegant tool which does either job better, and then gets the hell out of your way: QuickJava. Click the button, javascript off. Same as if you disabled it in the Tools menu, the way it should be. Not "mostly" off, but OFF. Click it again, javascript on. Click the flash button, flash plugin disabled. Click it again, re-enabled.
Now THAT is the correct solution to the problem.
Because of my business case - the site is for users who must be first set up by the site administrator
And you can have all these users install your CA certificate when they sign up.
While a very valid point, there is nothing to stop someone from self-signing a cert.
There is also nothing to stop someone from performing a man-in-the-middle attack on a self-signed HTTPS connection any more than an HTTP connection. You could start your own CA, get the CA's certificate to your users somehow (this is the hard part), and then sign your SSL certificates with that CA's key.
You, sir, are an idiot.
It *is* an ERROR. Your worthless self-signed certificate can be circumvented by a child, therefore your security is non-existent. The fact that people still use insecure browsers is not an excuse. Two wrongs do not make a right. Find another job, you have failed at yours.
The Firefox folks are doing the right thing by not listening to your moronic suggestions. If they did what you asked then users, using the latest version of the browser mind you, would have no idea that the sites they are visiting are completely insecure and can be hijacked by just about anyone.
Stop repeating your nonsense, no one believes or agrees with you. You suck and have no idea what you are doing.
Security should not be made completely ineffective / impotent just so your personal life can be rendered easier.
'nuff said.
Because of my business case - the site is for users who must be first set up by the site administrator, so nobody can just show up, it's only for known users.
Then I suggest you add the self-signed certificate to their computer, something like this.
You can always write your own browser....
Mod parent up.
We know HTTPS isn't "cheap". But seriously, now would be the time for /. to offer TLS.
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.
Here's the link https://www.eff.org/files/https-everywhere-latest.xpi which is missing from TFS.
This is a link to the extension. Here is the link to the article:
https://www.eff.org/deeplinks/2010/06/encrypt-web-https-everywhere-firefox-extension
HTTPS usage is at least as much about preventing surreptitious alteration (facilitating 'unwanted features' and attacks) of web pages. This can happen on unsecured or compromised networks: the 'coffee shop' Wifi scene is a place where people are particularly vulnerable not just to sniffing but to intrusion/infection attacks.
Then again, imagine you've been browsing safe at home and what was this tiny extra ad space that your ISP inserted into the top corner of many web pages became slowly larger over a period of months. Before too long the ads take on a TV-screen appearance and a couple years later you are struggling to keep a 1/8 screen sized virtual television (a subject-sensitive enhancement provided by your generous Cable ISP operator!) from impinging on your browsing. Around this point the basic fact that the TV-thing keeps appearing on so many Web users' screens starts to skew the Web advertising market and what once were many independent sites fall prey to a cycle of consolidation under the umbrella of TV networks.
Sounds great, doesn't it?
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:
Unfortunately far too many admins (and browser developers) seem to be brainwashed into believing CA's are an absolute necessity. Not everyone is as worried about identification as they are encryption/sniffing by governments and ISPs. Some people simply don't like the idea of trusting the security of their site with a third party (who could still perpetrate or facilitate a MITM themselves using the info you entrust them with) or cannot afford a widely recognized one. I understand a warning but it seems like FF goes too far out of it's way to make scare users away from self-signed certs which results in a LESS secure web as admins opt for the unprotected data xfer rather than scaring off visitors. Just like the use of DULs as a spam countermeasure, the end result is a sort of centralized/classist Internet upon which people can do certain things if they have enough extra $$ to pay for them and are willing to forfeit various freedoms/virtues in return - which runs counter to the idea of a Free and Open Internet.
Is there any short summary of how this https redirection works? Is a third party to be trusted?
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. Who is not frustrated by the browser treating self signed certificates as if they are some sort of a disease? They provide an important role - a way to secure communications between the server and the browser.
It is an error in judgment on Mozilla's part. Their increasing institutional-mindedness is causing them to send users always into the arms of the CAs -- preferably with no exceptions. The mindset has blinded them to the fact that is it a relatively straightforward UI design issue. Speaking of which, if I were in charge at Mozilla the first thing I would change about the cert warning dialog would be to display the server's fingerprint so its immediately in the user's face. Imagine if websites could publicize their fingerprints (say, on their company letterhead, business cards, in a voicemail menu option, etc.) so anyone could verify your self-signed cert with a little effort. That and a more ssh-like cert recognition could enable a revolution in security.
you'll have a much easier way of proving ill intent
Proving to whom? Losing something and using the court system to get it back can be too expensive for individuals or home-based businesses. SSL is cheaper than a lawyer.
I'm not saying the demand for HTTPS will fit nicely with all the options we have now. But its healthy to grow the demand for it... then more options will open up.
``This Firefox extension was inspired by the launch of Google's encrypted search option.''
Unfortunately, Google still has a way to go before it can do that. Google still has not secured Google Products, Images, Maps, Finance, Translate (now, there's something that should be secure), Scholar, Custom Search, Earth, Directory, Patent Search, iGoogle, GOOG-411, Alerts, Knol, Sketchup, and I don't know about Talk.
Still, it's only been a few days. I'm sure they'll have those up in no time.
why not Slashdot?
Slashdot is a business. Always was (you never noticed the blatant product endorsements?), always will be.
SSL certs cost money, and SSL connections cost CPU cycles. Remember how fanatical they were about banning people who reloaded the feeds too often (in their opinion)?
Given that this site only just barely adopted CSS in the last year or two, I think you should wake up and smell the coffee: Slashdot is in Coast Mode. FSDN or whoever owns them right now is only interested in advertising revenue, and that's probably so low that any improvements (like implementing SSL) would be a major hit to that revenue stream.
Please help metamoderate.
Firefox is slow enough as it is.
If Google really cared they would fix Android Chrome to reflow text, instead of discriminating
What difference with this make? If security actually becomes effective, it will be outlawed. You already have mandated back doors in much of your hardware.. It won't be much longer until you will be required to use a state issued ID card to use a computer, especially on the net.. (See Burma and Thailand)
Todos mis movimientos están friamente calculados
I only need to send them the certificate number, but at least the site wouldn't show up as an ERROR if FF did this right, but as a warning - self signed certificate.
You can't handle the truth.
You are the idiot - my business model only allows people who are known to the site to log in, because their username/initial password are created by the administrator, then they get their certificate number and instructions to compare the numbers on the first sign on.
You are the idiot with NO amount of imagination.
You are also an anonymous coward replying this way, should I say more?
You can't handle the truth.
Does anyone know when the Chrome version is going to be released?
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.
and force all of my users to use just one browser I wrote? Very good business idea, thank you, I am sure it will work well, you are a genius.
You can't handle the truth.
and they do, and they compare the cert number provided to them to the one showing up in the browser. But this is NOT an SSL ERROR, this is a WARNING. It's very poor UI design here.
You can't handle the truth.
This is one of the few reasons I'm still using Firefox/Iceweasel
That's fine and dandy if you are the only person who ever logs in to your site. But can you get the three-fourths of your customers who don't use Firefox to switch? It works for a blog, but not a blog that requires registration to comment, and not a forum.
No, it's an improvement over using plaintext, because it escalates the situation, requiring the attacker to use an active attack.
The NSA can (presumably) afford to passively snoop and search all plaintext that is passing over a backbone. If you make them MitM a billion unauthenticated encrypted connections, you have just dealt a staggering blow to their budget. You've also improved the chances that they'll get caught, either by someone noticing an increase in latency, or by them incorrectly assuming that a connection was unauthenticated when actually it was authenticated. (Remember: nobody in the middle actually knows whether or not you have checked the identity out of band.)
Self-signed certs are anything but security theater. They are a massive improvement over the status quo.
Oh and if I can get a little futurist/preachy..
If everyone who currently doesn't use encryption, started to use weakly-authenticated encryption, it would draw more attention to the certification problem, since it would be a relevant issue in most connections. Read through the comments here and you'll see people giving reasons for why they use self-signed certifications rather than paying Verisign. Increasing the use of self-signed certs would exert a market pressure to address those reasons.
The solution to these problems (OpenPGP) has been available for a couple decades now. The more we use crypto and therefore the more often the "how can I trust I'm talking to who I think I'm talking to?" question comes up, the more our expectations will start to demand the newer (1988-1990) tech.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
It's not *any* better? I seems about 4000 times better to me.
With plain HTTP anyone in range of my WiFi network can sit passively and catch my credentials without ever even sending a packet. And they could do the same for every single user on my network without any additional work. With encrypted but unauthenticated HTTPS an attacker would need to actively insert themselves into my stream and fake both sides of the transaction to intercept my credentials. And they'd have to maintain a separate session for each additional user on my network.
I agree that protecting against MitM attacks is also a worth goal, but to claim that encryption is useless without authentication is like claiming that locking your door it worthless because anyone with a key could unlock it.
Google also doesn't have HTTPS available on their www.google.co.uk domain; it redirects back to HTTP.
It's official. Most of you are morons.
Oh, what could possibly go wrong with rewriting URLs? Well, plenty, companies have loadbalancers and all kinds of complicated setups. So I hope people understand that rewriting stuff like this might result in unexpected behaviors and errors. You know, there might be a reason why they have it as http.
How ridiculous is it, that people get their bank's identity vouched for by a third party they have never met and don't know anything about, when the bank could just put up a fingerprint sign in their lobby and on their paper statements? And people say using a CA is more secure, and less vulnerable to MitM? Really?!?
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
The user is instructed to check the certificate number during installation to avoid a possible MITM attack.
What's the practical difference between the end user checking the certificate number and the method I mentioned in this post, which Firefox and possibly other browsers like better?
A browser won't throw an error or even a warning if the user installs the CA certificate (which is a separate certificate from the SSL certificate) before visiting the SSL site.
Every site can't have HTTPS until every site has it's own IP address. HTTPS does not support multiple hosts with different names on a single IP.
This, combined with DNS spoofing (which is peanuts), kills almost any security provided by the self-signed cert.
Dilbert RSS feed
Then tell your users to accept the certificate permanently the first time they visit your site after they verify the information being presented by FF during the error.
If the word "error" really bothers you, you can certainly build your own browser that uses something different or does something different and distribute it to your customers for them to use when they interact with your website.
But if your customers choose to use the standard FF, then you need to accommodate and respect your customers choices.
B*tching about how FF works or doesn't work to your liking on /. because you clearly do not have a clue about how PKI actually works isn't really going to change anything.
There are low-cost CAs out there and even a free OpenCA, but the problem remains that the CA that issues anonymous certificates will probably never be routinely trusted on a large scale.
If the deal is that you know that your website is who its certificate says it is, then pony up and get a certificate from a CA that is in your user's browsers. If you don't like the prices from ANY of those CAs, then that's your problem, and not the rest of /. readers or the FF developers issue to solve for you.
Personally, I strongly feel that whatever content is that you have on your site is worth what you're willing to pay for a certificate for your subscribers to be sure that it really is you that is producing this content. That is if you even have the legal right to distribute it, which may be why you don't want to identify yourself in a way that can be verified and validated by any third party.
And I doubt that you're running WikiLeaks or a copy-cat site like it, or you would have already gone down the path of using OpenCA and establishing PGP-based web-of-trusts with your customers.
Using a self-signed cert doesn't protect from them if they really want to spy on you, they'd just mitm-proxy your connections. Using a CA provided can at least make it more difficult, but the only way to be sure in those cases is to manually verify the cert's data.
But I agree that Firefox shouldn't warn against them - only don't treat them as secure as CA verified ones.
Dilbert RSS feed
Neither Facebook nor PayPal worked properly for me with this extension enabled. Facebook Chat seems to be disabled on HTTPS (not a great loss I admit), and a PayPal transaction I attempted just failed.
I didn't read TFA, but something is bothering me.
You can not connect in https to a web server that does not provide https ! Sur you could wrapt the connection in a secure socket between you and a proxy and then the proxy connect in unsecured standard http to the web server.
But that's not https everywhere! it just protect spying between you and the proxy. The whole connexion is not encrypted...
(or should I have read TFA ?)
It's kind of weird that you have to pay someone to get signed. (I never had to pay anyone to sign my pgp key.)
You had to pay the airline when you flew to the key signing party, or someone from another city had to pay the airline when he flew to your key signing party. Disconnected webs of trust, one for each city, aren't too useful.
It's sad that browser makers, rather than users, are making the default choice about what signers are trusted.
They have more resources than individual users to vet the policies of trusted introducers.
Think about all the people in real life that you either have to authenticate to (e.g. showing photo id when you open a bank account)
If governments, which issue these IDs, were to get into the CA business, right-wing pundits would cry "socialism".
Unlike form authentication, digest authentication through CGI also requires access to URL rewriting through .htaccess, to which a lot of hosting providers don't give customers access (AllowOverride None).
seeing as how any admin with two functioning brain cells to rub together will have made sure not to have configured HTTPS on a site unless the site needs it,
AND
the gateways and firewalls will have been configured to block HTTPS on the site's IP address(es) -- because only an idiot opens ports that they don't need -- so the HTTPS is not going to make it to/from the server.
eff.org uses a certificate from a CA that I marked as untrusted during the scandal over certificates issued without verification that Eddy Nigg uncovered in 2008 ( https://blog.startcom.org/?p=145 ). He was able to get a certificate for mozilla.com, no questions asked.
So out of the frying pan and into the fire. Is the link in the OP REALLY from eff.org? Or is it the world's most elaborate phish yet?
We are the 198 proof..
This extension should be do-able in Chrome/Chromium too.
It's silly NOT to expect a business to care about anything other than profit. Profit is pretty much the sole determination as to whether a business survives.
And there's nothing wrong with that. Once you ACCEPT that a business should only care about maximizing profit, then you understand how to get a business to operate in an ethical manner: Make it profitable.
You can do that with consumer pressure, laws, taxes, penalties, subsidies, handouts....
So don't get upset that businesses are only interested in profits. Embrace it and make it work for you!
paintball
When can I get a Chrome version?
"Using a CA provided can at least make it more difficult" The same argument can be made for self-signed certs. They aren't foolproof but they at least make it more difficult for potential eavesdroppers. The big difference is that you aren't forced to entrust your security to a third party who is not only a bigger/riper target but whose interests might [eventually] run counter to your own. Forcing people to choose between "All" or nothing often leads them to choose nothing which isn't a good thing. IMO just about everything on the Web should be ciphered in these days of government and ISP snooping.
I agree that the profit incentive is powerful, but this misses the fact that corporations are constructs of the law, and are
bound by it. A corporation that violates its charter, or violates the law, should expect the "death penalty" in the form of
bankruptcy, or losing its right to do business in my state.
A business isn't a natural person, and corporations require approval (in the form of a charter or articles of incorporation) to exist.
Charters ARE revokable. It doesn't happen often, but I expect a business to follow the law, and if that law says
"corporation must pay taxes", or "corporation must give 10% of its profits to a charitable 501(c)3", then I'm not concerned
about undue putting a burden on them, since every other corporation is expected to play by the same rules.