Mozilla SSL Policy Considered Bad For the Web 897
Chandon Seldon writes "The issue of digital certificates for SSL and the policies surrounding them comes up repeatedly. I've written an article criticizing the behavior in Firefox 3, which includes a serious comparison of the current Mozilla policy — restricting encrypted HTTP to paying customers — to a violation of net neutrality."
Most clueless article ever? (Score:3, Interesting)
Damn right you are. (Score:2, Interesting)
For some small sites, we need to encrypt traffic to protect consumer data from being "spyed on" by misconfigured switches, WLAN eavesdropping, and so on.
For those sites, buying a certificate is possible, but the costs are high compared to the gains (as this is *only* about protection of the data, not about "being sure this is site XY). Based on the certificate IDs/hash it's possible in this environment for anyone to compare whether the certificate is a trustworthy one, or not. The certificate identification is, in this case, possible.
But it's a lot harder to explain why this really, really scary message (it scares the HELL out of customers) appears now and then, when someone moved to a new computer or something.
The old FF2 behaviour was "better" in this respect.
I also see benefits of the efforts made to clarify this encryption/identification stuff for normal users, like the green address bar. That's really a gift, showing the user "everything all-right with your banking application or amazon store".
But this behaviour marking "self-signed" certificates as something über-evil out of the deepest depth of hell, is crossing a line a bit to far, in my opinion.
A short warning with a better explanation, or even a yellow bar - encrypted, but not "that secure" - might have been a better way.
Well, patches welcome, I hope :)
Still better than just praying the 2012-expected Internet Nightmare 9 misteriously replacing the old behaviour with something worse. You know what I'm talking about, are you? ;)
they provide encrytpion and that matters (Score:3, Interesting)
so you people are basically arguing that because there can be man in the middle attacks, we should be forcing EVERYONE into the lap of verisign ?
how populist, how public minded, how democratic.
Re:One Question (Score:3, Interesting)
I've successfully bought SSL certificates for companies that I had little or no verifiable connection with, from authorities that are trusted by all major browsers. Now, I obtained these with full permission of the companies in question, as a contractor, but as far as the authority was concerned, I was Joe Bloggs.
Same exact experience here. And the thing is that they don't even bother calling anyone to verify anything. I've even used my own credit card to buy certificates.
Re:Bad Article (Score:4, Interesting)
If the purpose of the Firehose is to vet articles, it's not doing a good job.
I don't think the purpose of Firehose is to vet articles. Rather, it's a way for Slashdot to become more Digg-like, and Digg-like content is what we get. Seriously, go back five, even two years ago and try to find front page stories in which some random person writes "I've written a controversial article on X. Click here to see my thoughts". You won't find many, but now you can find them almost daily on Slashdot. And along with the Digg-like content comes the Digg-like users, with all their conspiracy theories, hyperbole, immaturity, and general teenage boy mentalities that has driven away all but said demographic from Digg.
Fortunately, Firehose is only a gateway to the editors, and not a direct route to the front page. Thus, the decline of Slashdot has been more gradual than the decline of Digg. But you'd be hard pressed to find a true geek that isn't longing for the good old days.
And oh yeah, Get Off My Lawn!!
Re:Seconded. (Score:2, Interesting)
The most ideal interface would probably be the one in IE7 but personally, I'll go for Opera... it's the least intrusive.
As for hobbyist systems, they (the site owners) usually tell their less-than-techy friends to access their sites which is installed with self-signed certificates... (can be due to various reasons from hosting a Trac+SVN server to HTTP authentication over SSL, etc) aside from waving your hand to get them to visit your site, you also have to play tech support for them to get past the esoteric error message.
As for unprofessional webhosters, they usually hand out shared certs to keep the cost down but of course, they also give you an option to get a personal cert... at a price... it's not very convenient for people living at other parts of the world (particularly in developing countries). You don't want (or do you?) to shut them out from online business opportunities just because all they can afford is a shared cert.
Re:Seconded. (Score:5, Interesting)
Obviously you don't need encryption very badly if you don't care about man-in-the-middle attacks.
Re:Damn right you are. (Score:5, Interesting)
For those sites, buying a certificate is possible, but the costs are high compared to the gains (as this is *only* about protection of the data, not about "being sure this is site XY).
If my data needs encrypted, you'd better be sure as a client I want to know it's going to the right place. As the server, you probably don't care (but you should). You don't want to spend $$ to get a cert with a browser pre-installed CA? Fine, but please provide a way to contact your company through the yellow pages or some other non-website contact info that allows people to call a real person and verify the SSL cert. 99.999% of people won't, but sysadmins will.
Re:no it does. (Score:2, Interesting)
Re:One Question (Score:3, Interesting)
stolen credit cards can be easy to detect... but can also be very easy to miss. If the charge is less than a certain amount, most CC software processes it directly (and if it turns out to be stolen, too bad, the acquirer refuses and the merchant takes the few dollars hit). The idea is that the cost and time of processing the small amounts aren't worth the bother. I think the acquirers also mandate it - possibly not nowadays in the super-fast always-on networks we have, but in the days when authentication was via dial-up they'd have been saturated with connections for every $5 transaction.
The other factor is that sometimes stolen cards aren't marked as stolen for some time - if I lost my wallet this morning, I wouldn't know about it until I came to pay for lunch.
So, considering you can get a certificate via bogus means, how does this apply when it gets revoked shortly afterwards. I mean, you do have all up-to-date CRLs installed on your browser don't you? Or use OSCP. IE6 doesn't support it, but IE7 does... but only on Vista. There were problems with OSCP on FF2 (and the advice was turn it off), so I don't know how many FF3 installs there are with it still turned off (just check... mine included!)
Re:Seconded. (Score:2, Interesting)
Thats what they said about IE6 - you don't HAVE to write your web pages twice (once for standards and once for microsoft) but if you don't, you're cutting out a huge portion of your audience ;)
Users conditioned to click to accept everything: (Score:3, Interesting)
SSL certificates provide honesty-box security
- People will come to your site
- People will come to your site
- People will come to your site
- People will come to your site
- People will come to your site
The whole PDF is a highly recommended read full of sad truths.
Unfortunately, it is VERY hard to recondition users. I don't blame Mozilla for
trying (in fact I completely agree with the change), but it will probably fail.
Re:One Question (Score:2, Interesting)
Does it guarantee the identity and trustworthiness of the entity? Not absolutely
So again, what's the point with CAs?
As you said, it doesn't guarantee the identity of the remote site. An attacker can buy a certificate for www.yourbank.com (easier if he's an insider and has a mail @yourbank.com), poison your ISP's DNS cache and redirect your SSL traffic to his site.
I'll trust CAs a bit more when they'll come to my office to deliver my servers certificates. They're pretty useless until then.
To the modders: IMHO this thread is't mean to be a flamebait.
Re:Seconded. (Score:3, Interesting)
The outcome is that every dammed web that uses https gives me that f*ing warning with sec_error_unknown_issuer, cos of course the issuer is the proxy at my job, and the web domain does not match the issuer.
I have reduced the number of clicks required to add the exception to just 3 instead of 4 by editing the config file so it pre-loads the certificate when you click on the "add exception" link. But it's still a PITA.
I wouldn't mind if it was the default behavior but you could change the setting to a less paranoid one. But the fact there's no way to override this setting makes me angry. I want to be able to decide what do I want to trust or not.
I have to disagree... (Score:3, Interesting)
In a world where phishing is a considerably bigger problem then someone snooping your connection, I have to agree with how Firefox functions here. Self-signed certificates provide no way to authenticate the website which is even more important these days after the recent DNS exploits.
I think Mozilla's large "Failed!" message is much better than a default-accept of self-signed certs with a small warning message that would be ignored by 90% of users. Besides, Firefox will still allow self-signed certs after manual intervention.
Re:Seconded. (Score:2, Interesting)
I really don't support anyone that says paying through the roof for a trusted certificate is better than a self-signed certificate. With exception of business validation (which often comes as a joke) trusted certs are really no better than saying this person paid money for a brand name. It's like A&F jeans versus Walmart jeans.
The problem with FF3 is that it denies you access to websites with self-signed certificates until you explicitly install the certificate (as an "exception"). Odds are you're only visiting such a site once in your life, so installing the cert is by far a larger security risk than allowing the user to temporarily accept. This is up there with Vista's annoying security policy.
I can see more businesses paying for certificates from Verisign and the like, but it's a punch in the face of net neutrality when you see how this is hurting small business owners. They end up charging more to their customers and the customers leave for a cheaper big-box solution which kills little guy and eventually the local economy.
This also makes rush/trial/beta setups very annoying where the client has not shelled out their cash for a trusted cert. They want their website out there immediately but they've only paid for part of the package. If you give them a temporary self-signed cert, it gets put on the FF3 exceptions list and then it sits wasted on the machine once the trusted cert comes around. And you also have to waste time explaining to them how to install the cert.
You probably won't, but I'd support a net-wide protest against trusted certs and see what Mozilla does about their stupid policy after everyone spends half an hour of their day configuring exceptions in their browser. At least IE lets you temporarily accept, but I hate IE.
Re:One Question (Score:3, Interesting)
Not really, you can easily buy 'legitimate' certs certifying you are a company you have nothing to do with.
Certs don't verify you are talking to who you think you are in reality. Certs should verify you are talking to the DOMAIN you think you are. But a self-signed cert is better than no cert so there certainly shouldn't be more stringent notifications than there are for completely unencrypted pages. Further, open and free ca like https://www.openca.org/ [openca.org] should be in the root trust of the browser, since they verify domain ownership.
Re:Seconded. (Score:4, Interesting)
I think you point out clearly the point. Ideally, every webserver should be providing SSL access, but it's certainly not necessary for every one of them to buy a certificate. Most of the time, an ssh-style system of simply accepting the first presented certificate and caching the server's public key is sufficient.
I would suggest that a browser not display the warning you are showing always, but only if the user is being prompted for data. That, or we need to make the three levels of security more clear to the end user. However, I'm not a big fan of putting more requirements on the user.
In my opinion, the problem is the strict hierarchical nature of the SSL certificate system. It needs to make use of existing information contained in social networks. I think some of the information Google holds could be of great use here.
Re:Seconded. (Score:3, Interesting)
"If a little yellow bar like the "remember password" bar came down and said "this site is encrypted, but its identity cannot be authenticated. Be aware that, like any normal (http) website, this one may not be from who it says it's from" then it would be completely different. Instead they interrupt the browsing experience with a very unfriendly message that non-tech people will not have a chance of understanding."
I agree. I think it is appropriate to warn the user, and it should be made clear this is unnacceptable on a site where banking or credit card info is involved. But completely alarming the user is overboard.
I use self-signed certs every now and again where I am trying to protect passwords, but there is not a big security risk.
That said, a godaddy cert is pretty darn cheap these days, so I do it fairly rarely now.
Re:Seconded. (Score:4, Interesting)
No: if you train your users to ignore "[this certificate isn't signed by a know authority]" warnings, then you makes them substantially MORE vulnerable to man-in-the-middle attacks and, indeed, increases their susceptibility to phishing across the board.
As a web admin you will of course also have to maintain the certificate store, but that may be very easy if you only have a handful of clients. And if you have a handful of clients you may install the root certificate in a controlled situation on the clients, so not even there you have a big problem with insecurity.
didn't you just defeat your own protest to this 'feature?' If you're going to install the cert/root on your clients, then they won't encounter this message, and there's no problem.
Where i DO see a problem is making it very very cheap and and easy for people to register believable certs for
cittibank.com
citibnak.com
citybank.com
citibanc.com
Cost of entry keeps attacks like these targeted, removing that would open things up immeasurably... or do you think the phishing problem is overblown and just a commercial stunt too?
One of the points of SSL.. (Score:2, Interesting)
Is non-repudiation. I think the 4 clicks is excessive, but one of the whole points behind SSL is to prove that the site you're talking to is the one you want to be talking to. Especially today with phishing, dns cache poisoning, etc it's pretty important to be communicating with a site that has a valid certificate.
Self-signed certs are fine for development or personal use. If you're using it for that purpose, you have to only accept the certificate once and you're done.
Anyways, SSL certs aren't expensive now, so if you have a need for one on your site, just go to godaddy and cough up the 30 bucks and quit complaining.
Could the browser not use DNS records? (Score:2, Interesting)
I am not a DNS expert so feel free to correct me if I am jumping to any wrong conclusions here..
It seems to me that the problem (as TFA discusses it) revolves around the use of third parties to tell your browser whether to accept the certificate in terms of authenticity.
If the concern of browsers is to ensure the server providing the certificate is the real one, why are they/we not using something like the SSHFP or CERT [wikipedia.org] DNS record types. If my reading of those two is correct the system could work thus:
- user requests www.foo.com
- browser is presented with a certificate by the www.foo.com server
- certificate cannot be validated by signing authorities so
- browser validates this against the DNS/CERT and/or DNS SSHFP entries
If by this point the browser still cannot verify the authenticity of the server providing the certificate it can throw up a warning to the user. Okay so a MITM attack could provide false DNS records for particular/any domains but they could the same now and redirect a cert lookup to their own spoofed "certification authorities".
Re:Seconded. (Score:1, Interesting)
Additionally, you've trained them to accept self-signed certs from people who actually have real accounts. Over the next week, their Paypal account, bank information, and credit card details are stolen, all because you convinced them it's a "commercial stunt."
I believe it is you who trained them, by providing that warning.
The rest of us just want a trivial amount of protection for our fucking BB login, and we'd be happy if the browser didn't even mention it was SSL at all.
You're really not grasping this, are you? People complaining don't want to run damn bank sites or storefronts or anything you'd need signed SSL for.
We want to take things currently with no encryption at all and put a cheap SSL cert up there so that we're not sending cleartext passwords. Things like slashdot. Half the stuff is on shared IPs, so we couldn't even get a real cert for it, because we need a * one.
The joke is, for the longest time, browsers have provided visual clues that a site is SSL. Why are those clues not enough? Why not simply remove those clues for self-signed sites? Why popup bigass warnings?
The actual truth of the matter is that people don't use those clues. Half the time they don't look at their damn address bar at all. And because they don't use those clues, almost all phish attacks don't even bother with SSL, which sorta makes the whole 'people might be tricked by unsigned certs' argument look rather dumb.
Re:This is stupid (Score:2, Interesting)
confidentiality and authentication are 2 separate protperties, so how do we design a GUI which does not mislead him.
Let's do it with alert boxes.
LMAO
Seriously though, just split SSL in two. Encrypted connections can be called "Private" and Authenticated connections can be called "Trusted". Users can understand that, and browsers can make rules about Private being required for all Trusted connections.
Re:One Question (Score:3, Interesting)
That depends. I'd argue that it's actually worse if it give the user a false sense of security.
Let's say that we implement the trust system that you propose (self-signed certs appear as more secure than plain sites, and less secure than trusted certs). This would do nothing to prevent against phishing attacks. In fact you'd have just as many attacks, but all the phishers would start using self-signed certs so that their sites appear as "more secure" than a regular website.
As firefox gains market share Mozilla has to abandon the assumptions that their userbase is tech-savvy and has web "street-smarts". I agree that this policy is onerous and it has affected me personally for some sites that I'm using self-signed certs on.
Ultimately I think that Firefox 3's policy is the only one that will make a dent in phishing, but there is collateral damage. I think the author's attempt to liken this to a violation of net neutrality is wrong.
Re:Seconded. (Score:3, Interesting)
This prevents those sites from using HTTPS, as it makes entering them pretty hard and obvious.
And preventing them from using https does what exactly? The users don't get that great big warning screen that they supposedly require. There's just a missing padlock in the status bar. It's hard to justify a full screen alert with a multistage exception procedure when it's this easy to go around.
Mission solved.
Accomplished. It's mission accomplished and problem solved. Except it isn't.