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)
Re: (Score:2)
Does NOT work for Slashdot.org (Score:5, Interesting)
Re:Does NOT work for Slashdot.org (Score:4, Informative)
Re:Does NOT work for Slashdot.org (Score:5, Insightful)
That's a subscriber feature.
So to narrow down people posting politically sensitive stories (say, whistle-blower type stories) from a country, it is merely necessary to cross check banking records against payments to Slashdot. Slashdot should know better.
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:Does NOT work for Slashdot.org (Score:5, Insightful)
Every time I hear "is is a business, therefore it doesn't have to care about anything besides profit" I turn a little more to the left. Seriously, did CEOs mistake Soviet propaganda as instruction manuals or something?
If it's not wrong for them to not do something, then why should they do it?
You're not dealing with this right. (Score:3, Insightful)
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 pr
Re: (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
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?
CPU overhead (Score:2)
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 advert
Re: (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: (Score:2, Insightful)
please. there's nothing that goes on on
I didn't know either (Score:2)
...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.
It is based on NoScript, in fact (Score:5, Informative)
Re: (Score:3, Funny)
Re: (Score:3, Funny)
I got the Onion reference. This would have been an Epic FP.
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.
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).
Re:forcing views of the hompage (Score:5, Informative)
set noscript.firstRunRedirection to false
Re: (Score:2)
I can see why noscript has frequent updates, since it's in an arms race with malware writers
So is AdBlock Plus, and it manages to provide a delivery system that doesn’t require frequent updates to the extension itself.
Furthermore you innately don’t need to update a whitelist as often as a blacklist.
Re: (Score:3, Insightful)
AdBlock Plus and NoScript are doing different things -- ABP is basically a filter engine, and the rules are the only thing that (normally) needs to be updated. NoScript is blocking things based on various algorithms, so it's procedural rather than data-driven. It's not surprising that NoScript's engine needs to be updated more often than ABP's.
Re: (Score:2)
I’m going to have to call bullshit on that. Citation needed.
http://noscript.net/features [noscript.net]
Show me which of those features requires frequent updates to NoScript’s actual engine.
Re: (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: (Score:2)
That's what I've never understood. All Noscript has to do is disable scripting across the board. Then enable it on a Site by Site (Whitelist) basis. What's so f""ing hard about that? That's my settings by default. It blocks everything except those websites where I must have scripting enabled and I use the same settings for my 70+ mum and my 50+ sis (both of them are Noobs)
Re: (Score:2)
So how do you handle multiple tabs, some where you want to allow javascript, some where you don't?
Noscript's whitelisting approach handles this cleanly and easily.
Default to HTTP? (Score:5, Insightful)
Geez. What kind of poorly written site would do something like quietly defaulting to unencrypted HTTP on a HTTPS request.
https://www.slashdot.org/ [slashdot.org]
Cipher CPU use, caching, and Google Custom Search (Score:3, Insightful)
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:
Re: (Score:2)
Maybe its because they want more control over what clients are doing? Using SSL consumes more CPU you know, on both the client and the server side.
As a sysadmin for a web hosting provider, I see lots of these types of extensions that are written with no consideration of the server side of the equation. The people writing them seem to think that the server side has infinite CPU, RAM and bandwidth, which is just not true.
Re: (Score:2)
Poorly written because it defaults to HTTP? I disagree. Programmers like myself avoid using HTTP for delivering things that simply don't need to be encrypted. Why? Because it's more resource intensive on both the server and the client. We use the optimal solution - HTTP.
Re: (Score:3, Insightful)
It's only the optimal solution for you. If the client choose HTTPS and you change back to HTTP then *you're* deciding that their content shouldn't be encrypted, even if they think it should be. You can choose not to offer HTTPS if you think the burden is too high on your end, but you're lying to yourself by calling it the "optimal" solution for both sides.
You might not care that your web browsing is encrypted. But I might be on a monitored network and don't want my overlords to know that I downloaded a chee
Re:Default to HTTP? (Score:4, Insightful)
You're shit out of luck because _we_ pay the bills here and _we_ build the websites so yes it's not being out of line to think that we should control how it's delivered. Take your entitlement to someplace that honors that currency. I'm a hacker too, but this whole "I want everything in the world my way" shit is getting old. Live with it, or don't. But it's not an "issue" in any way as far as I'm concerned. Don't like it? Go elsewhere.
Re: (Score:2, Insightful)
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?
I eagerly await your response.
Re: (Score:3, Interesting)
If anyone wants to protect his/her login data, why don't they use OpenID and a secure provider?
Re: (Score:2)
Surely that still results in a cookie that can be snooped over the HTTP stream and used as a login token?
Re: (Score:2)
Why would I do that. You do realise that security isn't black and white.
There are levels of security.
My online banking details are something I wouldn't send over HTTP, and yet I'm perfectly willing to send my slashdot details over HTTP.
It's possible to get my online banking details, they are not perfectly secure. It is just more difficult than if I logged into my bank via HTTP.
It's possible to get my slashdot details, they are not perfecctly secure. It is just more difficult than if I posted them in a slash
Re: (Score:2)
The nice thing about the extension is that it WILL lead to more demand of HTTPS from users because it makes clear to them when the HTTPS option isn't there. They are bound to think more about the sensitivity of their various browsing activities on a page-by-page basis, so the desire for security will find greater expression.
FWIW, maybe the extra demand will lead to people using free CAs for things like blogs. Maybe even EFF could eventually become a CA...
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.
Re: (Score:2)
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.
Not True [wikipedia.org]
Re: (Score:2)
And if you read that page you'll notice that a large part of the world has no support for it (most browsers don't support SNI on Windows XP).
Re: (Score:2)
"Internet Explorer 7 (Vista or higher, not XP) or later"
This is a sticky point. Everyone still uses XP because Vista and 7 suck.
Some hosting co's will let you use a shared cert (Score:2)
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.
Re: (Score:2)
Maybe even EFF could eventually become a CA...
I've seen this suggested multiple times. Any idea what the EFF's position is on this?
Re:Default to HTTP? (Score:5, Insightful)
O RLY?
Try using Slashdot (or most other sites) all day in an airport or at a cafe with your laptop, then see how long it takes for someone to start F-ing around with the Javascript that your browser is receiving in the clear. And then there are those lovely residential ISPs that screw with your web pages for not very different reasons.
The EFF wants to see the web prepared for an assault that looks likely to intensify.
BTW, there is such a thing as being too cheap.
Link? (Score:2, Informative)
For those of you without google ... http://www.eff.org/https-everywhere
Re:Link? (Score:5, Informative)
Shouldn't that be https://www.eff.org/https-everywhere [eff.org] ?
Re: (Score:3, Insightful)
In an ideal world, every web request could be defaulted to HTTPS
I say:
In an ideal world, you wouldn't NEED to use HTTPS.
Re: (Score:3, Insightful)
There are realistic ideal worlds, and there are unrealistic ideal worlds.
Much needed extension (Score:5, Informative)
Re:Much needed extension (Score:5, Funny)
Hmm... if you are trying to encrypt your communications with *Facebook* something tells me you are worrying about the wrong people getting their hands on your personal data.
Re: (Score:2)
I'm sorry, but while OP may be concerned about Facebook, it's naive of you to think that s/he has separate passwords for other sites vs. FB - remember, we're talking about someone on the internet. I even use the same password in some places, but regardless it's either SSL login or no login or, if its somewhere I really want to login (/. for example), I use a username/password combo that I don't use anywhere else. Security's role shouldn't be diminished just because of the site you're going to - if there is
Re: (Score:2)
if there is a login box, HTTPS should be offered
The certificate company and the hosting company charge annual fees for HTTPS. These are a cost of doing business if you're deriving a significant chunk of revenue from the site. But how should the operator of every little blog and forum afford the annual fees for HTTPS?
Re: (Score:2)
While a very valid point, there is nothing to stop someone from self-signing a cert. Of course, having something signed by a CA carries a lot more weight, but if I trust the site and the owner/author makes it clear as to why they self-signed and provided a means of ensuring some amount of trust, I would feel much better. And like I said, at least use a different username/combo for those kinds of sites than something you use in more secure situations.
Man in the middle (Score:2)
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.
Re: (Score:2)
There is also nothing to stop someone from performing a man-in-the-middle attack on a self-signed HTTPS connection
There's an extension that fixes that: http://www.cs.cmu.edu/~perspectives/ [cmu.edu]
Re: (Score:2)
While a very valid point, there is nothing to stop someone from self-signing a cert. Of course, having something signed by a CA carries a lot more weight, but if I trust the site and the owner/author makes it clear as to why they self-signed and provided a means of ensuring some amount of trust, I would feel much better. And like I said, at least use a different username/combo for those kinds of sites than something you use in more secure situations.
This was a great suggestion until the major browsers added the "super scary warnings". I've had to walk so many people through exactly what to do in order to get past those. Especially the type of people that say I typed in my password ROSEBUD just like I always do and I got this message. Those errors are too scary for the average user, and require too many clicks.
Re: (Score:2)
It also stops MITM attacks of course - while it's unlikely that anyone would intercept my latest status update or message and change it in flight, with HTTP it's possible.
(Not that I care, but that's one reason why the OP might.)
Parent's comment isn't really apt (Score:2)
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 perio
Link to the article (Score:2)
Here's the link https://www.eff.org/files/https-everywhere-latest.xpi [eff.org] 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 [eff.org]
Does what it sounds like... (Score:5, Insightful)
Re: (Score:2)
It probably has to be hardcoded per site - so it can be everywhere, if you help.
Re:Does what it sounds like... (Score:4, Insightful)
It can't be *everywhere* as not every site provides HTTPS access. You could go through a proxy, but that would only encrypt traffic between you and the proxy (and would of course introduce a potential bottleneck if it was a general-use proxy)
Re: (Score:2)
Everywhere, when the website supports it, obviously.
I can't understand... (Score:2, Interesting)
Does What It Sounds Like? (Score:5, Informative)
Link (Score:5, Informative)
Re: (Score:3, 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?
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: (Score:2)
It is still not an error of SSL or of the site, it is a configuration choice.
Re: (Score:2)
Re: (Score:2)
This is not an error of ssl or of http, this should come with a warning from a browser, no question, but my users will know the site and the cert.
I completely disagree that this should come with a label 'Error'.
It should come with some label like: 'Warning, the certificate is self signed, you better know what it is'.
However you skipped completely the part of my post, where I am talking about the real issue:
SSLInsecureRenegotiation on
which is in itself prone to MITM type of attack, regardless of whether the
Re: (Score:2)
With effort, and sometimes a trivial amount, one can invade on another's privacy. But we've all made a social agreement to respect privacy; all it takes is a humble token, like a window curtain, to remind us of this. The curtain is just cloth, but it does an excellent job of affording us privacy, because it asserts our intent. That way, if we're able to detect it, we can be certain in knowing that our privacy is violated -- otherwise, any access we didn't think to deny (but would regret later) might accidentally intrude upon us -- and with no ill will from the innocent onlooker! How foolish of us, that we didn't draw the curtain when we had the chance!
Re: (Score:2)
A self-signed certificate may be unsafe but it does imply an intent of privacy.
So in other words, a self-signed certificate is security theater [wikipedia.org]. Online criminals by definition don't respect the "social agreement" that you mention. (By the way, whom are you quoting?)
Re: (Score:2)
Lawyers are more expensive than SSL (Score:2)
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.
Re:Self-signed certs are vulnerable to MITM (Score:5, Insightful)
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.
So that just means that the site isn't secure. Fine. FF shouldn't display the lock icon, or color the address bar. But that's no reason to treat the connection as an error. The appropriate thing to do is to present the site as insecure (which it is), but to go ahead and encrypt the link. Ideally, FF should go one step further and use SSH-style server key history. Silently (or with a small "new key, do you want to accept it?" dialog) accept and use the self-signed certificate, and then puke hard if the certificate ever changes without good reason (i.e. old cert expired or was replaced with a proper certificate).
By making these small changes, browser makers could significantly increase the average security of the web, so that sites that will otherwise have to go with unencrypted HTTP can use HTTPS -- even if MITM attacks are still possible, and if security shouldn't be relied upon, this sort of "opportunistic" encryption can make casual snooping significantly harder. That's a good thing.
Re: (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 j
Re: (Score:2)
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: (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
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
if the user knows the certificate
How would the user know the certificate on the user's first visit to the site?
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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 [cacert.org].
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3, Insightful)
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
mod this guy up (Score:5, Insightful)
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?!?
facebook (Score:2, Interesting)
Re: (Score:2)
Re: (Score:3, Informative)
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: (Score:3, Informative)
Re: (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.
Extensions on third-party sites: Use the Google. (Score:2)