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."
I can't understand... (Score:2, Interesting)
firefox doesn't really make it easy for the users (Score:5, Interesting)
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?
Does NOT work for Slashdot.org (Score:5, Interesting)
Self-signed certs are vulnerable to MITM (Score:5, Interesting)
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.
Re:Default to HTTP? (Score:3, Interesting)
If anyone wants to protect his/her login data, why don't they use OpenID and a secure provider?
facebook (Score:2, Interesting)
slashdot, HTTPS please! (Score:1, Interesting)
Mod parent up.
We know HTTPS isn't "cheap". But seriously, now would be the time for /. to offer TLS.
Re:Does NOT work for Slashdot.org (Score:5, Interesting)
It's not /.'s job to provide a secure means for posting politically sensitive stories. It would be nice if that's possible but that's not what they are in the business of doing, so I don't think it's fair to suggest /. "should know better".
I'm sure they know perfectly well, and I'm sure that the decision support HTTPS this way is also an economic and technological decision. /. is a business, not a charity, and not a public service (although it provides public service as part of its business model). If /. advertised itself _primarily_ as a forum for free, uncensored speech or a forum for communicating with people in less free circumstances then it's a fair cop.
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.
On the other hand, like Microsoft, busting on /. is fun and often justified, so I wouldn't mind piling on. They're such insensitive clods!
Re:Self-signed certs are vulnerable to MITM (Score:4, Interesting)
You are still missing the point. There is no SSL Error, there only needs to be an SSL Warning: self signed certificate.
The users are given certificate numbers as well as user names / temporary passwords. They are instructed to check that the certificate is correct when the browser makes the connection or to install certificate if they can by themselves.
--
Every single person replying to me has completely ignored this issue:
SSLInsecureRenegotiation on
which is a much more important one - regardless of whether the certificate is signed by CA or not, the MITM is still possible and my business model actually fixes this but not technologically, it fixes it operationally.
Nobody is talking about it here at all, looks like they don't get it. IE and earlier FF versions cannot even make the connection unless this flag is on.
Re:Link (Score:3, Interesting)
Re:forcing views of the hompage (Score:2, Interesting)
So you'd rather have extensions updating themselves through their own downloader code than have them just use the Firefox update framework?
Re:forcing views of the hompage (Score:3, Interesting)
Of course I would. The Firefox update process requires a complete restart of the browser. If an extension can update its filter set without requiring a complete extension update and the corresponding browser restart, it should.
In fact, since Javascript is capable of self-modification it’d be nice to see extensions that could update themselves on-the-fly, only updating the actual files on the disk when the browser is restarted.
Re:Does NOT work for Slashdot.org (Score:3, Interesting)
If it's not wrong for them to not do something, then why should they do it?
Wait.. Let me make sure I'm getting your double negatives straight here. Are you saying that the amorality of an inaction robs motive from the corresponding action? It's not wrong for me to not eat a potato chip right now. So why eat a potato chip? Do I have to be arrested for setting the potato chip down before I can omnom with a clear conscience?
Dewd, your world sux! I am glad I don't live there. ;D