Slashdot Mirror
Mozilla SSL Policy Considered Bad For the Web
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."
wouldn't implementing what the author suggest, defeat the very purpose of having a CA ? SSL is not just for encryption you know. There is a little thing called 'trust' which pays a big part in it too.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
The whole point of SSL is to have some assurance that you are connecting to whom you think you're are connecting to.
While the model of paying a CA to assure your identity is not perfect by any means, ignoring the issue isn't either. Many slashdotters seem to have a hard time getting this.
IMHO, the system in Firefox 3 is superior. While self-signed sites are blocked by default, it is not easier to explicitly trust a self-signed SSL site. In the past, most people would just click past the nag dialog when it popped up.
Conformity is the jailer of freedom and enemy of growth. -JFK
I encourage all of my users to use Firefox by including it on our PC images, showing them it's cool features, and letting them know about how it's more secure. I've been running into problems with self-signed SSL certificates though.
I run a router/firewall based on the Untangle software, which in turn is a modified Debian/Knoppix setup. It also does VPN, based on the open source openVPN software, and it uses self-signed SSL certificates for it. While I don't mind adding our firewalls to a safe list, my users freak out with all of the warnings and aren't sure what they should do. I've been telling them to use Internet Explorer, but it makes my skin crawl to say it. Hopefully the Mozilla team will reconsider their position to make their software more open-source friendly.
The average user doesn't notice any security feature unless it is in their face.
Given the number of phishing sites out there, it could be argued that every additional slap to the face that a user would have to get through in order to get to a phishing site (known phishing site, self-signed SSL, acknowledge that you are a fucking retard for bypassing the last two warnings, etc.) may be worth it.
Just remember that just because the precepts of net neutrality (all bandwidth is equal) means that we should let a user shoot themselves in the head doesn't mean that we shouldn't at least make a passing effort to put a safety on the gun they are using.
RomSteady - I came, I saw, I tested. GamerTag: RomSteady / http://www.romsteady.net
This is bullshit.
It's not like Firefox makes it impossible to access a web site with a self signed certificate. It just makes it very obvious that something is wrong with the certificate, and tells the user that he shouldn't trust it to much.
Now, who uses self signed certificates or certificates signed by an internal CA?
* Test environments (not an end user scenario)
* Unprofessional webhosters (good riddance)
* Companies with their own CA (they can preload the certificate)
* Hobbyist systems (they can reconfigure their browser)
In the end, the only ones hurt by this are unprofessional webhosters - and i don't think anyone should care about them.
I'm not sure what the problem here is - If a website claims that it isn't part of the malware revolution with a self signed certificate, it isn't any more authentic than NOT having one.
The only real use for a self signed certificate is for large institutions that already have the trust of the user (ie: universities) - but you have to assume that they havn't been compromised, because it would be easy to have a second certificate, signed by the owner of the hijacked site.
Anyways, firefox 3 does a great job, and it isn't hard to add an exception - and it isn't annoying like UAE...
There is a "warning," and then there is a "WARNING: YOU MUST CLICK FIVE TIMES TO SEE THIS PAGE." A simple bar across the top of the page with a warning that the sites identity couldn't be verified, but that the connection was still encrypted would work just fine.
Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
On the other side of the coin, it subsidizes the CA industry just like compulsory auto insurance subsidizes the auto insurance industry.
Don't call me back. Give me a call back. Bye. So yeah. But bye our, well, but alright we are on a shirt this chill.
I think the author makes Mozilla's case for them, by not appearing to understand the risks, especially at a time when DNS cache poisoning has become unusually feasible. E.g., the statement
is simply not true for clients of unpatched DNS servers. It's much easier for an attacker to get a remote user's traffic redirected to a host of his choosing than it is for him to snoop on that user's traffic. Volume-based attacks on DNS become increasingly easier as bandwidth increases, and people who operate botnets have a good chance of poisoning a cache even on patched nameservers, simply through brute force. Meanwhile, that smaller class of attackers who are in a position to actually snoop on traffic are also in a position to use an arp spoofing attack. Encryption is simply not useful without knowing whom you're encrypting to.
If you're feeling lucky, you can always add the exception. You can also sign your certs with a CA cert, and import that into your certificate database. Of course, anyone who trusts that CA cert also trusts you not to generate bogus certs for bankofamerica.com, etc... The solution to the problem is not to make the browser more trusting by default; it's to migrate away from X.509 to a PKI that allows domain owners to generate certs at no additional cost, such as a DNSSEC-based PKI.
I think Mozilla has it 100% right.
I originally meant to post this as a comment to the blog post, but apparently the author does not care about testing their commenting feature. This alone should already tell you stories about how much thought he puts into this stuff.
-+-
Why in the world are you singling out Mozilla in this ? Every browser has this policy.
Every browser has avenues to add new root certs, too (I can just create my own CA, offer the certificate file on the web, and let users install that; all future communication with a site that has a certificate signed by that CA will not be bothered with these error messages). This may not be 100% convenient, you are correct. But it's not as if it was hard to do if you want to give your users the option of using encrypted sessions.
Oh, and there IS a way to get your shiny new non-profit CA into the main Firefox builds. All you need to do is comply with their procedures and requirements -- which include policies on how you verify the identity of the certificates you sign, how revocations work, etc., and requiring specific minimum requirements in these. If you think you can run a proper CA for free for everybody with proper identity checking and day-to-day operations, do it and get it added !
The default position Mozilla takes is quite simply that the CA should verify the identity of the entity the certificate is being issued to. You may not think that it is important for this to be such a prominent user interface feature, but many people do. Every user can add an exception for your site, you can add a CA of your own, you can get certified by a nonprofit CA (good luck finding one; I agree that most of them are scumbag operations that try to extract as much money from you as possible, but I have yet to see a proposal which both ensures identity checking and revocation management while being completely free ... Maybe you'll find a way).
This has nothing to do with network neutrality. Nothing at all. A more proper comparison would be comparing this situation with that of 2nd-level domain names. You can't get a .com domain for free, either. Nor a .net or .org or most of the country TLDs. You can open up your own Registrar (but will still have to pay dues for domains registered), just as you can open up your own CA. It'll be a rocky road, and it'll not be free -- least of all in work required.
My sites work just fine with SSL certs signed by my very own CA. Firefox displays them just fine (either by adding the root cert of my CA to it, or by simply adding an exception). All other browsers work fine, too. If you have visitors or customers that require validation of your certificate by a third party, you are SOL. But then again, you also would be were the warning worded differently (and there SHOULD be a warning for a certificate that is not signed by a trusted CA or one which you explicitly told the browser to trust. No matter what. Self-signed certs are alright for encryption, sure, but I want my browser to have a default setting of warning me when something is happening that very well could be an attack; especially when I have taken care to add a specific trusted CA (say, the one by my university).
-+-
When do people finally realize that self signed certificates don't work? If I share your WLAN access in a public cafe it's really no big deal to play man in the middle and exchange the presented certificate for my own. Ok, it's more work than without, but not much (about 5 minutes). The only case where self-signed certificates can be secure is when you manually verify the validity of a certificate beforehand and save it in your cert store. If your first check of a certificate's validity happens to be while I'm attacking you (maybe because you are visiting the site for the first time) you will "verify" my hacked one. And don't tell me about hashes on webpages. Maybe 1 in 1000000 users checks this once in a while for pure curiosity, but not more.
It's not like Firefox makes it impossible to access a web site with a self signed certificate. It just makes it very obvious that something is wrong with the certificate, and tells the user that he shouldn't trust it to much.
there close to a billion people on the net that wouldnt tell what to do when faced with such a disastrous looking warning as ff 3 prints out when met with a self signed ca.
also there are equally many people that would rather skip visiting/subscribing to a site when they see the hassle ff3 puts out.
therefore many small service providers, businesses, communities that would not afford a decent certificate will be hurt in all respects, not to mention many users.
excuse me, but this is a very stupid, self righteous and jacobin move.
that is the EXACT kind of thing slashdot criticizes almost EVERY government, country, organization, corporation for, yet, you people are actually applauding it in this case.
Read radical news here
A.) You don't need to buy certs from Mozilla, you can buy them from any number of CA's, for as little as $10. There are some free CA's, as well.
B.) This isn't in any way related to network neutrality.
Interested in open source engine management for your Subaru?
Except that there is nothing compulsory about ff. You are free to trust any certificate you want, the browser merely warns you that it could be a bad idea to do so.
On the other side of the coin, it subsidizes the CA industry just like compulsory auto insurance subsidizes the auto insurance industry.
Driving is a privilege not a right. Unless you have the money to cover any damages you may cause, it is absolutely necessary to have insurance. The cost of barebones liability coverage is not that high assuming you have a relatively clean record and if not, you probably shouldn't be driving. It seems that today the idea of personal responsibility is falling out of favor.
I'm not not licking toads.
<flame mode="on">
In all seriousness, fuck you. No, really, fuck you. I am a graduate student. My only support comes from the part time job that I have to pay my tuition and my bills, and a grant for my research. I research computer security. To say what you have said shows zero understanding of computer security, encryption, user behavior, and accountability. Go suck a big fat one.
</flame>
This is the ultimate problem with your post. Before I tear it a new asshole (and I'm going to tear it a new asshole - nothing personal, but I hate posts that masquerade ignorance as wisdom), know that the reason that Mozilla is doing this is because security professionals, by and large, do not build the web and are not the majority of the people. This is why they are so picky about security. I have spoken to security professionals and the overwhelming consensus is that accepting self-signed certificates by default is bad. Very bad. Break the whole security and user trust in SSL bad. If user trust in SSL is broken, then we have ultimately failed.
Community websites can walk users through installing the proper certificate instead of relying on users to override a secure default for certificates. They can teach the users about the importance of verifying certificate fingerprints (to avoid a man-in-the middle). If they release software, they can bundle their certificate with the software. If there are small businesses, they can install their CA on their user's machines. This then becomes a non-issue. In a secure setup, these entities will generate a self-signed root CA certificate (like any other CA), push that to their users, and then sign the certificate for their website with this CA certificate (thus providing the ability to revoke the encrypting certificate should it become compromised and allow certificate updates/refreshes completely hands-off of the client). <flame mode="on">If you knew anything about SSL, anything at all, you would know this. Instead you assume, and make yourself look like the twit you are. Users hurt by this policy? It's the same policy (a bit more stringent, but the same policy) that the other browsers have.</flame>
If they used the certificates securely, understood how SSL worked, and did research, this would be a non-issue. I am not clueless about how people use SSL. I am saying that they are using it wrong, and Mozilla is doing the right thing here. Here's a roadmap for anyone who cares to learn about how to do this properly:
First, I think that the most important line in the article is this one:
But there is absolutely no excuse for it to be significanly less inviting to a normal user than an unencrypted site.
The FF3 behaviour will make most normal users just think, "Oh, the website is broken. I guess I can't go there." They won't even read the error message: they'll just see that there is one, and give up.
Or, depending on IE's behaviour (which I do not know in this particular case), they'll see, "Oh, I can't get to this website in Firefox. But hey, it works fine in Internet Explorer! I guess Firefox is broken, and I won't use it anymore."
Second, and probably more importantly, either you missed a very, very important demographic among those who use self-signed certificates, or otherwise don't want to pay the extortionate fees charged by the corporate CAs, or you severely misunderstand and underestimate the importance of "unprofessional" and "hobbyist" webmasters.
Just because I want to have the possibility of encrypted traffic for visitors to my website doesn't mean that I'm bringing in loads of money by said website, or that I want to spend some not insignificant sum on a recurring basis for what is, for me, just a fun hobby, for which I'm already shelling out a not insignificant sum for hosting.
I'm seriously hoping that your definition of "unprofessional webhosters" means "people running for-profit websites (that actually make a profit) who are just too cheap to actually buy a certificate," and not simply "amateurs," because it is on the backs of those amateurs that the web was built.
Dan Aris
Fun. Free. Online. RPG. BattleMaster.
You buy a purple T-Shirt and 6 months later purple is out of fashion. Clearly the manufacturer's fault, right?
Yes, SSL Certificates from a CA *are* expensive. Yes, you can encrypt with a self-signed cert. But that encryption is worth nothing at all. Because anyone (latest DNS vulnerabilities for instance) can easily forge these certificates, you don't know who you are communicating with in the first place. Of what use is point-to-point encryption if the man in the middle is undetectable?
Yes, it 4 clicks to define an exception rule are a pain in the ass. But because it's that painful it will cause people (like the author) to think twice before they use a self-signed cert next time. So making the web safer in the end. Don't make it too painful (will hurt adoption of product), but painful enough so that decision makers get worried. I think FF3 behaves perfectly in that respect.
It's hardly a "mere" warning; it's a gigantic stop sign.
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.
This is bad because, as the article says, some sites will end up having to buy certificates when in fact they don't need one, and others will end up not using encryption when in fact they should be.
Bear in mind the three levels of security:
1) no-ssl: offers neither encryption nor authenication
2) SSL(self-signed): offers encryption
3) SSL(3rd party signed): offers both
why is that that no.2, which is a significant improvement on no.1, generates such a severe warning message?
If you run a self-signed certificate you still can get the man in the middle protection.
There is no difference there, the only difference is that you don't have to pay for a certificate from a well-known root CA. The "insecurity" of not using a well-known CA is only a commercial stunt.
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.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
This is a well known attack vendor: Make a web page that looks like a real bank site and trick people into visiting it. This prevents those sites from using HTTPS, as it makes entering them pretty hard and obvious. Mission solved. The collateral damage is admins who don't want to spend the time to properly set up their CAs. Nothing to see here, move along. As to subsidizing the industry, if you feel you can do a better job being a default CA, please contact the Mozilla foundation and prove it.
Problem is that your "2" doesn't exist... the way SSL (and most other secure protocols, as SSH) is designed, having encryption without authentication is pointless, because man in the middle attacks are too easy to set up.
With SSL, the real 3 options you have are:
1- no ssl
2- "1 way authentication" SSL (usually only the server has a certificate: this ensures the client it is reaching the right server, but the server cannot trust the client)
3- mutual authentification SSL (aka "strong authentication": server and client have a certificate)
I think TFA is completely out of topic and blatantly ignorant: what would you think if SSH wouldn't warn you when the host you're trying to connect to has changed ?
The problem about SSL isn't to warn or not about self signed certificate (you HAVE to be warned about self-signed, and strongly, else anybody can easily get "average user's" bank account info, for instance). What is at stake is the lack of competition among public SSL Certification Authorities.
In general, don't try to solve a political/competition problem through technical/IT means, this won't work. Solve such problems through political/competition means (such as laws, regulators or open standards).
number 2 is _not_ a significant improvement over number 1, simply because from a security standpoint, you have gained almost no security by encrypting if you don't know whether you're communicating between the person you want to or perhaps some fake site that looks similar, or a man-in-the-middle attack.
the only improvement is in the case of a purely-passive eavesdropper -- not much of an improvement at all. For eavesdropping purposes, if you can passively eavesdrop, you can probably actively eavesdrop and interrupt or manipulate the connections, because you've got physical access to some wires or routers or just have a laptop running airsnort software in a cafe.
furthermore, having people get used to using self-signed certificates is bad, because it lends man-in-the-middle attacks more apparent legitimacy. so of course eve couldn't fake the signature of the real key, but if any signature will do...
i don't like the existing certificate authorities ($50-$100 per year for a row in a table? sheesh!) much either, but they're needed to have trust between people who have not met before.
the privacy of one's mind is important.
you do have something to hide.
2) SSL(self-signed): offers encryption
But unless there is some warning about invalid certificate it is subject to man in the middle attacks. Also, unless you check the certificates every time, allowing self signed certificates would allow man in the middle attacks even against sights that have secure signed certificates.
Problem is that "2" doesn't happen.
Think of this example: I "encrypt" some confidential data. However, I've encrypted it so that I don't know who will be able to decrypt it. Does that make any sense?
Why was I encrypting it? So a criminal couldn't steal my credit card number? What if I had just encrypted it directly to that criminal? Oops! This encryption didn't help me at all.
If I want to send someone secured data I first have to define clearly and be sure of who I am sending that confidential data to.
With a little thinking you'll find that not authenticating the end users of an encrypted channel is just moving some bits around and is only as secure as your network. Meaning you might as well be sending clear text and save some processor cycles.
Now you can accept self-signed certificates, but you had better have a different way of authenticating the cert than the rest of us use. An example of this would be something from an internal corporate network.
//TODO: signature
Yes, but for a public user there is no difference between your self signed certificate and Harry Hacker's self signed certificate. If your application is to be used just by a finite number of user on which computers you took care of also installing your self signed certificate, then this is ok. But for a publicly accessible site, like your webmail, or your bank's internet banking application, you need a CA signed certificate, otherwise a certificate self signed by the bank looks exactly like one that a middle man can create on himself to impersonate the bank.