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 think it is. Half of SSL is about encrypting a connection, the other half is about knowing whether you can trust the other side. What the article suggests (that SSL connections when the other side uses a self-signed certificate should give no warning) would completely destroy security of the Internet.
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.
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? ;)
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
In four mouse clicks I've added that site to my exceptions list. It warned me, I read and understood the warning, I acted. I saw the https page and the web site owner didn't have to pay for a certificate.
So, the article is wrong:
"Mozilla Firefox 3 limits usable encrypted (SSL) web sites to those who are willing to pay money to one of their approved digital certificate vendors"
please add 'or click four times to add the site to an exception list'.
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...
"we are programmers and developers, and as a community we think this is the right thing to do" - this does NOT fly. public accepts what they like, they refuse what they dont. this is as simple as that, REGARDLESS OF what they accept or refuse may be good, or bad.
it is utterly stupid to go overly jacobin and enforce something on people 'for improving the security on the web', in an open source project that is made by people FOR the people.
a lot of websites, service owners, businesses using vpn and their clients and their users are going to experience hell lot of problems due to this extreme self righteousness forced upon them, if they go for firefox 3.
to be honest, despite im fighting for free and open internet, linux, open source by the means available to me as much as i can, i will be advising friends and clients to stay away from ff3 because of that certificate issue.
Read radical news here
I suppose you could just add an exception for the site you want to access. (Four clicks?) Or your corporate IT people could add their signing certificate to the version of Firefox they distribute.
I don't understand the "antifeature" accusation at all.
>north
You're an immobile computer, remember?
As mentioned on the Firehose comments page about this article (http://tech.slashdot.org/comments.pl?sid=634651&cid=24461415):
If the purpose of the Firehose is to vet articles, it's not doing a good job.
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).
-+-
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.
I don't understand this. You want to be sure that the data transfered is protected, but you're happy to have it redirected to any site.
As to the cost/benefit, how about a cert from startssl? This has the cost of $0 and the benefit of being supported by Firefox. It's not supported by IE unless the user installs a root cert by hand, but then it wasn't IE you were complaining about. Firefox actually seems to be ahead of IE in this regard.
EVERYthing on the web is susceptible to various attacks. yet, we are not mandating anyone to pay to some 3rd party source for a 'fix' in any of them. yet, it is the case of ff3 and the self signed certs. how come ?
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.
Read radical news here
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.
I can't speak for IE, but safari pops up a sheet telling the user that the site has an untrusted cert with 3 options: use the cert once (you'll get the warning again,) always trust this site, and don't load the page. i think this is how firefox should behave (perhaps even loading the page and then warning the user)
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.
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
That was my implied point, the author of the article should be complaining about the trustworthiness aspect of the SSL, and not mozilla's policy about accepting self signed certificates. As things stand today, SSL means 2 things a) encryption and b) trust (i.e. the site is what it claims it is). And to provide the part b, it relies on the concept of CAs. Now whether this is a good thing or just a money grabbing policy by the big CAs is a totally different thing, but what Mozilla is doing is nothing wrong. May be they can have a easier way to import a self-signed certificate, rather than having to go through 3/4 clicks as it stands now, but I sure wouldn't want that warning to go away the first time. I am completely aware that all it takes to buy a certificate is money, but that is not mozilla's or SSL's fault, it is rather the fault of the companies behind the CA business.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
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.
Our school uses a self-signed certificate for the courseware. We won't get freaked out because we're CS students (but it's really, really, REALLY annoying, especially if you access public terminals) but I bet the rest of the student population will.
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.
Obviously you don't need encryption very badly if you don't care about man-in-the-middle attacks.
They don't call it "auto insurance" for nothing!
I'm going back to Telnet -- no pesky security certificates to worry about.
But you only have a handful of clients, who know that you're trustworthy, so it's a non-issue for you.
what kind of logic is this ?
1. create your own CA and tell your customers to import the CA by clicking here (before putting them in ssl mode). It's really not much trouble to set up your own CA.
first, you are not in communication with potential customers, and they will never communicate with you and become a customer after they see that horrible ff3 warning. you wont even get a chance to tell them what is going on.
second, same goes for many potential website users that are signing up for a community.
additionally godaddy is one of the shittiest service providers on the web. so if the solution you are offering is godaddy, please, keep it to yourself, and even firefox3 too.
Read radical news here
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.
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?
Our school uses a self-signed certificate for the courseware.
Than tell the admins to fix it. School environments are hard to do, because you have a lot of non-standard clients. So a public cert would probably be better for a school than an internal CA (which would make sense for a company).
Again: Firefox and IE both give a very stern warning that what you're going to do is potentially risky. This is the *RIGHT* thing to do - if that wasn't the case, with the recent DNS issues it would be easily possible to spoof https://www.yourbank.com./
Basically, don't blame Firefox if your cost-cutting measures break on you - it's your own fault.
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.
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.
Not really a problem, just that the self signed certificate is unknown to your browser.
Don't forget that once it is installed it is no different from a well-known certificate and SSH uses the same approach by allowing you as a first-time user to accept the server signature and barf if it has changed.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
I really hate that FF3 behavior. At my job they have a proxy+fw that acts like a man-in-the-middle. It connects to the webs you want to see, and you connect to the proxy.
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.
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.
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.
ÕÕ
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.
In the vocabulary of international politics, we need to "trust but verify." Which means no trust at all.
There needs to be a mechanism where a vendor or site can send you a certificate in a way that can't be spoofed. And can then be verified. Maybe it is an email, maybe it is snail mail?
What I don't like about SSL in web browsers, is that they have ignored the "verify" aspect of trust by abdicating the responsibility to a "pay for trust" regime which is bogus. If they can pay, they are trust worthy, right?
Ideally, I should be able to receive a password in the mail (or some form of communication) to unlock a "key" file sent to me from someone I want to trust. I then unlock and install that key on my system and only keys *I* trust get trusted.
It should be easy and standardized across most platforms. Anything less is broken.
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).
No the author has a grip. If you haven't added the root for OpenCA go to www.openca.org with your firefox 3 and look at what you are presented with.
If you try to go forward it presents you with a HELP GET ME OUT OF HERE button an option to add an exception, then on that exception adding window it blatantly says that no legitimate website would require you to do this. In other words, it blatantly accuses all self-signed sites of being a scam.
Driving is a privilege not a right.
This is unconstitutional statist propaganda. According to the Declaration of Independence and the Constitution, the people create a government and give it limited powers necessary to maintain order and do other important common tasks. Regulating driving is surely one of those tasks. I have no objection to requiring insurance. But the government does not confer privileges on its citizens. It's the other way around.
It's "attack vector", not vendor.
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?
Well...no. 2 also offers authentication if you consider that you signed it yourself (and it's assumed that you trust yourself because, after all, if you don't trust yourself you can you trust)? However, it seems to make sense that since there are no 3rd parties involved why does there need to be a warning? Perhaps people should just install the public certificate of their site into their browser.
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.
* Unprofessional webhosters (good riddance)
The "unprofessional web hoster", that we use at work here in Greece, offers a full spectrum of services (just about anything you can think of, including personal service--you have a problem, you call them and they fix it while you talk, not some person at a help desk who may or may not forward your request) at a rock bottom price. Their competitors have much higher prices and will charge you for anything beyond the basic web hosting package. You want more than the default few MBytes? That's extra. You want a database or php? That's extra, too. You want to park a domain? You need to buy the domain parking package. You want it now? Sorry, it's going to take 24 hours!
If the cost for all this is that we have to connect to the web site's control panel (which the other providers don't, well, provide), using a self-signed certificate, it's good riddance to those other providers!
Thats what they said about IE6
I think comparisons to IE6 count as Godwinning the thread.
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
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.
Sigh. You don't disclose your private key to a third party when you request a certificate. You provide the public key, and the third party signs that with the private key corresponding to a CA certificate. Neither party reveals a private key to the other, or to anyone else.
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.
"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.
The only athletic sport I ever mastered was backgammon - Douglas William Jerrold
Hmm now Microsoft, they're a well-known attack vendor. :-)
Except that unsigned encrypted transmissions are open to man in the middle attacks, meaning that self signed SSL is potentially MORE dangerous than unencrypted as the existence of the encryption layer gives the end user a false sense of security. Hence, the need for certificates in the first place.
I'll never make that mistake again, reading the experts' opinions. - Feynman
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?
-- D-23994, Muff#2613
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
you are missing two critical points:
1.- saying that it is a privilege is not the same as saying that the state concedes privileges, as this is actually tautological. Given the state is an organization built by society to ensure some form of regulation that makes it possible to enjoy certain privileges to all, the existence of the state is a material necessity to the existence of those privileges, and saying that the state is the origin of those privileges is the same as saying that some tool is the origin of the product, when it's the other way around: the tool exists only in the extent in which it is useful to getting the product done. The same thing happens with the state: it exists solely to make the availability of privileges to all.
2.- you have to take into account the rather obvious material considerations that render all this libertarian rants senseless. To enjoy driving, you need a lot of social resources that enable you to do all things related to driving, from getting a car, to using roads, etc. to provide for this resources, we the people have decided to give some other authority to accomplish that which we need to "drive" and that we can not accomplish by ourselves, e g the state. Does this materiallity that makes the state necessary for the enjoying of some (you would say natural, i'm sure) privileges make the state the _origin_ of this privileges?
you have three choices here: 1.- no 2.- yes and the correct one: who fucking cares? this disctintion between the genealogical role of the state and the material role of the state is just a pile of idealistic, liberal (in the proper sense, go look it up), primitive and naive crap.
both points are very similar, but they are two distinct points, nevertheless.
(and don't even get me started on the idiocy of 'granting' privileges to the state. that's like saying that corporate personas have rights!)
---
"america: the only place in the world where 'liberal' means statist, and 'libertarian' means letting the poor die in the streets".
entia non sunt multiplicanda praeter necessitatem
You can give your cert to as many people as you like.
You should NOT give your private key.
Public and private key works together and there's no way to find a private ley from a public key and the reverse (If you find a method, you'll break all the crypto !)
Some CA can generate the private ley for you but it's not a good idea.
Best way is :
- generate a private/public key on your server
- generate a certificate demand (signed with your private key)
- send the certificate to the ca (you can use a safe way as you already know the ca cert)
- the ca check this is you
- the ca sign your certificate demand with it's private key (and I think your public key)
- the ca send you the certificate
- you install the certificate (only you can decrypt with your private key)
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.
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 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".
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.
Firefox users are more tech-savvy than average. The decision to reduce web usability of self-signed sites could potentially reduce the number of non-tech-savvy user. This could damage Firefox, not net neutrality.
The first Certification Authorithy in this scenario is not Verisign, it is Mozilla. I decide to give my trust to Mozilla. If something like big police-iconified warnings occurs for self-signed certificates, I am free to deny my trust to them and change browser.
Besides, I think that Firefox should display a warning as big as that one also anytime you type a password field inside a non-encrypted site. Coherence.
Working to work less.
How long do you think the price will stay at $14.99 when there is an industry that knows that there can be no further entrants?
One round of consolidation will give you a small cartel of companies that will take turns raising the price, just as any other high barrier to entry industry (oil is a good example, as is banking in many countries such as Australia).
I hate printers.
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.
Um, dude. Perhaps you should pay a little more attention. SSH operates via '2'. There's not even such a thing as a signed SSH key. Granted, you can use PPK to keep someone from forwarding the connection, but good luck getting the PPK on without logging in with the password once.
With SSH, the trick is to make the first connection over an internet connection that you trust, and it stores the fingerprint for future reference.
SSL sites that didn't need authentication, that just wanted password protection against cleartext sniffing on login, could trivially operate the same way.
Like it or not, there actually is a very wide range of websites that, right now, use no encryption at all, but would use SSL if it was free, and there is absolutely no way that could make them more insecure. Likewise, there are a variety of circumstances where it is easy to sniff on a user but difficult to intercept and replace their transmission.
Almost all cars can be broken into in about 60 seconds, using a slim jim on the door. However, people still lock their doors. Basically, you're arguing that it shouldn't be possible to lock a car unless it has a full-fledged car alarm, which is a rather...stupid...argument.
If corporations are people, aren't stockholders guilty of slavery?
If you are talking to somebody who poisoned the DNS cache, masquerade the site you want to talk to, using a different self-signed certificate, you are absolutely ignorant about it: your experience will be exactly the same.
Try this use case: Start a web browser that properly supports self-signed certificates. Visit an HTTPS site using a self-signed cert. You get a (minor) warning and accept the cert. Then someone starts poisoning the DNS cache using a different cert. You get a major warning that the cert for this domain has changed.
So a man-in-the-middle attack can succeed only in the case that the first visit to a site uses the poisoned cache entry.
"Customers should just learn not to buy from www.amaz0n.com"
And without a trusted certificate from a third party, they'll have no way of knowing if they're talking to "amaz0n.com" when their browser says "amazon.com", after a DNS poisoning.
I agree that there are both too many CAs and the level of verification the perform is likely not enough, but getting rid of them is not the answer to everyone's problems.
Well, yes. A better metaphor is that car companies shouldn't be allowed to sell cars with cheap car alarms that can, in theory, be disabled in less than five minutes, and should have to either provide much more expensive ones...or they sell it with no alarms at all, like almost all cars. If they sell one with a car alarm that can be disabled in a short amount of time, they need to get the customer to do a lot of paperwork.
There's an arguable position that all car should have to come with car alarms, ones to a certain level, and that customers should be warned if they don't.
There's not really a reasonable arguments that says they can come without a car alarm, with no warning at all, but if you provide a cheap-ass one for a tiny bit more security, you have to give them all sorts of waivers to sign.
Firefox, and IE, right now, pop up enough warnings that make it seem that a web surf allowing an self-signed cert is the most dangerous thing you can do....which results in people not using any encryption at all for quite a lot of stuff. (Like, oh, the login to slashdot.)
People in favor of this talk about a 'false sense of security'. Ha. How about the false sense of insecurity browsers provide? Simply a single message 'This web site uses encryption that cannot be authenticated. Be aware it is no more secure than a standard web page.' would be more than enough. (Or, even better, no warning at all, and simply an unlocked 'lock' icon.)
If corporations are people, aren't stockholders guilty of slavery?
How long do you think the price will stay at $14.99 when there is an industry that knows that there can be no further entrants?
What? I think the price will be under $10 and stay there shortly.
One round of consolidation will give you a small cartel of companies that will take turns raising the price, just as any other high barrier to entry industry (oil is a good example, as is banking in many countries such as Australia).
Oil is a terrible example as the price of that is set by the open market and commodity traders.
You'll have that sometimes...
having encryption without authentication is pointless, because man in the middle attacks are too easy to set up
I strongly disagree. Maybe my surfing passes through Sweden, China or USA?
If I surf encrypted sites there's quite a good chance they won't log more than some traffic from that IP to mine. Unencrypted they'll get the whole URL and cookie history. Yes, they could man-in-the-middle me, but that's likely to remain an exception for some time. For now,"encrypt first, sign later" sounds like moving in the right direction to me.
Any sufficiently advanced libertarian utopia is indistinguishable from government.
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.
Those are my principles. If you don't like them I have others. -Groucho Marx
By the definition of Terrorist in your sig, I was a terrorist in the minds of my athletic opponents back in high school, and Almighty God is a terrorist in the minds of many followers of the western religions including and descending from Judaism. Oh, throw great white sharks in as terrorists too, as being killed by Al Qaeda holds about the same probability as being attacked by Jaws. Yet in this case, the fear of Jaws is likely much greater than that of Al Qaeda.