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."
One Question (Score:5, Insightful)
Re:One Question (Score:5, Insightful)
While he may have a valid point, I resent and disagree strongly with the author's implication that there is a profit motive to this. A bad decision, but not one made for profit.
Re:One Question (Score:5, Insightful)
Re:One Question (Score:4, Insightful)
Snooping a connection is a hell of a lot easier and more common than hijacking one. Hell, if someone can arbitrarily hijack connections, they can get themselves a completely valid SSL certificate by demonstrating their (hijacked) control of the domain to some minor CA.
There are no perfect answers to these security problems. But there are wrong answers - and requiring website owners to always sign up and be approved before they can use the HTTPS protocal on a public website is a wrong answer.
Re:One Question (Score:5, Insightful)
If there was any real "trust" component, I'd buy this argument. SSL certificate authorities are supposed to be sources of trust - we trust them to have authenticated that the FooCorp who bought a certificate really is FooCorp Ltd (and not F0oCorpe). However, the only inducement most vendors need to issue a certificate these days is money.
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. They've even realised that now, and introduced the new EV Certificates - now with Extra Validation! Until of course, these get paid off as well, and we need EEV Certificates and so forth.
Using SSL for trust based on the word of companies like Verisign is pointless - you have to do manual authentication. The only use I see for them these days is transport encryption.
Re: (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: (Score:3, Insightful)
This is exactly the point I was going to bring up. If you have access to install a certificate on a web server, you most likely have access to an admin-like email address, which is really all that is needed to get a "trusted" cert. One of the companies I use will validate by email to a domain contact or alternately to root@, postmaster@, webmaster@, admin@, etc. (a list of about a dozen they will accept).
SSL is useless for initial authentication, however, like most SSH implementations, if it were made eas
Re: (Score:3, Insightful)
Agreed. And there is an open CA that the major browsers don't include in their root list either.
It verifies DNS control. That is more than some of the cert whores and really all I need a CA to verify since it prevents man in the middle attacks.
Even a self-signed cert is dramatically better than an unencrypted connection. Security is not an all or none affair, encrypted is better than unencrypted, and encrypted and trusted is better than merely encrypted. The current prompts make it appear as if unencrypted
Re: (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 wa
Re:One Question (Score:4, Insightful)
Sure, but frankly, anyone who relies on the "trust" aspect of SSL certificates today for anything serious needs their head examined. In this world, trustworthy == willing and able to pay.
The encryption is by far the most important aspect of SSL for most applications, and you can use that regardless of any issues with CAs and trust.
Re: (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 the
Re:One Question (Score:4, Insightful)
The question you should ask is why is a website using a self-signed certificate presented to the user as *less safe* than one that is sending all information in the clear?
Re: (Score:3, Insightful)
From TFA:
'This ignores the value of simple encryption. Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents.'
He is right. Since when is security an all or none affair? Security is about making it more difficult to attack with the understanding there are always attacks you can't protect against. An alert saying that 'a secure connection is established but the identity of this website has not been verified by a central authority'
Re:One Question (Score:5, Insightful)
CAs do very little to ensure that the site you're connecting to is really the one it claims to be. So SSL is almost useless for authentication and trust. It's worth using it only for encryption and self signed certificates are as good for that as the ones you buy with money.
As a webmaster and owner of a site that uses SSL I second the author's proposal and more: let's stop pretending CAs can ensure the identity of the communicating parties, shut them down, save money and use SSL only for encrypting data.
Re:One Question (Score:5, Insightful)
No.
Seriously, stop being a retard.
If I'm connecting to my bank, and I get a certificate that matches the domain name and was signed by a widely trusted 3rd party, that gives me much more confidence than selecting some bozo's self-signed certificate.
Does it guarantee the identity and trustworthiness of the entity? Not absolutely, but it's a whole hell of a lot better than just encrypting comms and sending them to whoever happens to be running a man in the middle attack today.
Re:One Question (Score:5, Insightful)
I agree, domain verification is useful and should not be done away with entirely.
I don't agree with the current policy though. A simple notification saying the connection is encrypted but the domain identity isn't verified by a 3rd party with a box to not show this again would be fine. Currently the popup goes as far as to say that the site is not legitimate!
Also, this CA 'https://www.openca.org/' does verify you have control of the domain. Why is it still not included in the browser by default?
Re:One Question (Score:5, Insightful)
The problem with this is that it does not guarantee that your connection is actually encrypted. There is a reason why CAs where created and it has a lot to do with ensuring proper encryption. Basically a man in the middle attack can with self-signed CAs fake the user into accepting their CA instead of the website's CA. You now have the illusion of security and encryption which some would consider worse than no encryption at all. To the end user they would be identical and while there may be a complaint about different keys, if the user went to the site before, most users would probably ignore them (especially after they seem them a dozen times for legitimate sites that for some reason changed their keys).
Re:One Question (Score:5, Insightful)
Reading the article would be good, ya ?
The articles main complain is that the way FF does thing by default a website secured using a self-signed https:/// [https] certificate looks MORE scary and LESS secure than the very same site using http:/// [http] and no certificate whatsoever.
That, the author argues, is wrong. True, a https:/// [https] site *with* a certificate is even better than one without one. But BOTH are more secure than simply using http:/// [http]
So, it makes little sense to make self-signed https:/// [https] look MORE scary that http:/// [http]
I agree.
Re: (Score:3, Insightful)
Re:trust? (Score:5, Informative)
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.
Re:One Question (Score:5, Insightful)
Exactly.
A "secure" and encrypted connection to a compromised or malicious server is worthless.
Exactly! My accountant needs some documents from me. Rather than email them I have them up on a secure site. If my accountant connects to the wrong site I really don't care, he's not going to find the documents he needs so he's going to give me a call and ask where they are.
Self signed certs are for when you want to do the encryption but you're doing the authentication via other means.
I've used this in the past (although not to my accountant).
At the very worst, a self signed certificate is no worse than a plain HTTP connection.
If we didn't have plain HTTP at all then we would consider sites using self signed certificates as secure (or insecure) as a plain HTTP connection.
Tim.
Re:One Question (Score:4, Insightful)
The accountant doesn't have the documents for the man in the middle to intercept (this is a one-way thing, from the poster's description), and obviously he wouldn't find them by connecting to a hijacked server.
I don't think you understand how man-in-the-middle would work here.
His accountant would connect to the fraudulent server, which would give him a self-signed ssl certificate. It would then connect to the legitimate site using his credentials and display whatever the legitimate site would display. Anything available to the accountant would also be available to the man-in-the-middle, by definition - and the site would work just fine from the accountant's perspective, so no suspicion would be aroused.
This is stupid (Score:4, Insightful)
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.
Re:This is stupid (Score:5, Informative)
My parents couldn't get past that message even after I explained it. I had to downgrade FF because they would freak out when they saw that message.
From a usability point of view its terrible.
Re:This is stupid (Score:5, Insightful)
I think that's exactly the point. If you can't understand what a self signed certificate is, you shouldn't be accepting them.
Re: (Score:3, Insightful)
That's a pretty bad point. Are you suggesting that if you can't understand what a certificate is, you shouldn't be using SSL ? If you can't understand what HTTP is, you shouldn't browse the web ? If you can't understand what BGP is, you shouldn't be using HTTP ?
If you can't understand what a self-signed certificate ist, you should only be accepting them once you either a.) learned how to understand it or b.) somebody you trust tells you to or c.) you do not implicitly care about the implications since you a
Re:This is stupid (Score:5, Insightful)
Re:This is stupid (Score:5, Insightful)
The whole point of SSL is to have some assurance that you are connecting to whom you think you're are connecting to.
No. As TFA says, there are 2 points to SSL. 1 is to provide confidentiality (encryption) the other is to authenticate the server to the user. A server with a self-signed certificate provides protection against passing (but not active) snooping. This is worse than what a real, trusted-third-party signed certificate provides, but it is better than no encryption at all!
So why does the firefox GUI make a site with a self-signed certificate appear (to the non-technical user) less secure than a plain HTTP site?
IMHO TFA is very much correct this is a problem. The solution is not obvious, because users are used to the lock icon and may not understand the concept that confidentiality and authentication are 2 separate protperties, so how do we design a GUI which does not mislead him.
Re:This is stupid (Score:4, Insightful)
The people who don't understand this are not IT people who are going to be futzing with self-signed certs, or are IT people who need to clue up and understand the implications of using self-signed certs.
Re:This is stupid (Score:5, Insightful)
Let's do it with alert boxes.
HTTP only: "The communication with this site is insecure because it doesn't ecrypt the data you're sending to it. Furthermore there is no guarantee that it's owned by the organization that it claims to belong to. [checkbox] Don't tell this to me anymore.
Self signed HTTPS: "The communication with this site is secure because it encrypts the data you're sending to it. However there is no guarantee that it's owned by the organization that it claims to belong to. [checkbox] Don't tell this to me anymore."
CA's signed HTTPS: "The communication with this site is secure because it encrypts the data you're sending to it. Furthermore [the name of the CA] guarantees that the site is really owned by the organization that it claims to belong to. [checkbox] Don't tell this to me anymore."
However one has to be really naive to believe the guarantee part of the last statement or that CAs are willing to have any legal responsibility for the claims they're issuing with any certificate. Actually that third alert box might be harmful as it perpetuates the delusion that certificates do anything about authentication.
Eventually it's not a problem of GUIs but a problem of understanding what certificates are really for.
Re: (Score:3, Insightful)
While I like Firefox 3, I find it annoying that I have to accept a self-signed certificate forever. I'd much prefer to accept it from my current session only. Accepting it forever seems a little insecure to me.
Regards
elFarto
Re:This is stupid (Score:4, Insightful)
Except that it's actually the secure thing to do.
If you check the probability that the site you are using will get hacked in the lifetime usage of it that you will do, in most case the first usage of the website will be on the valid one, and you will then learn about a Man-in-the-middle attack when it will say that there's a new certificate to accept (every other time it had not asked you).
If you don't accept the certificate, you'll be clicking all the steps everytime for that website anyway, so you won't notice the different MD5/SHA1 hash, and in fact won't even look at it.
If it happened to you that you first used it on a day with an attack, then the next day or so, when it's fixed, you'll have a new certificate, and know that there's been something wrong (site will most probably talk about it) and you will be able to react fast, since you know you were subject to the man in the middle attack.
Anyway ..
Most clueless article ever? (Score:3, Interesting)
Re:Most clueless article ever? (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
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.
If self-signed SSL sites were indentified similar to "trusted" sites, then yes. But self-signed SSL certificates are a good step up in security over HTTP. For example, anyone only able to wiretap won't get anything at all. Intercepting streams for a MITM is a much more difficult thing to do, particularly if you're talking large volumes in real time. Also you'd get uh-ohs like "This site is now using a different key than last time" and some would compare fingerprints through some other secure channel so mass
This causes real problems. (Score:4, Insightful)
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.
Re: (Score:3, Funny)
Average user and security (Score:5, Insightful)
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.
Re: (Score:3, Insightful)
That makes perfect sense, except, when it comes to things we don't like here on slashdot, we don't allow half measures. If it doesn't 100% eliminate phishing, then all it does is piss off legitim
four clicks (Score:5, Informative)
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'.
Re: (Score:3, Funny)
In four mouse clicks I've added that site to my exceptions list. It warned me, I read and understood the warning, I acted.
Good for you, but people like you - and me and the rest of the people here - aren't "normal". Grandma won't know what the hell to do (besides call you). She might even think "those evil hackers" "got her".
Self-signed certs are a potential problem, but Firefox could have worked out a better way of handling it. A more novice-friendly way.
Basically, we need Bruce Schneier [schneier.com] and Jakob Nielsen [useit.com] to marry and have children. We'd better contact Dr. Moreau [wikipedia.org] to work out the breeding program. :)
Re: (Score:3, Insightful)
"Grandma won't know what the hell to do"
And Grandma doesn't care about getting secure access to your blog.
She cares about reading the news, chatting about knitting on the wool forum, sending email to the grandkids and accessing her bank account. Only the last one requires encryption, and for that you want full third-party authentication.
Streamlining this process or just warning Grandma will leave her with an empty bank account in no time.
Blocking Self Signed Certificates is GOOD! (Score:4, Insightful)
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...
you cant afford to be too jacobin (Score:3, Insightful)
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.
Bad Article (Score:5, Informative)
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.
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:Bad Article (Score:5, Insightful)
<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:
Mozilla is correct (Score:5, Insightful)
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.
No, it is not considered bad for the web.Blogrant. (Score:5, Insightful)
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).
-+-
Accept self-signed certs and I hack you in no time (Score:5, Insightful)
Number of holes in the author's argument (Score:5, Insightful)
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.
T-Shirt (Score:4, Insightful)
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.
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.
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.
The real problem is "trusting" (Score:3, Insightful)
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.
Re:Seconded. (Score:5, Insightful)
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.
Re:Seconded. (Score:4, Insightful)
On the other side of the coin, it subsidizes the CA industry just like compulsory auto insurance subsidizes the auto insurance industry.
Re:Seconded. (Score:5, Insightful)
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.
Re:Seconded. (Score:5, Insightful)
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?
Re:Seconded. (Score:5, Insightful)
Re: (Score:3, Informative)
It's "attack vector", not vendor.
Re:Seconded. (Score:5, Funny)
Hmm now Microsoft, they're a well-known attack vendor. :-)
Re:Seconded. (Score:5, Insightful)
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).
Re:Seconded. (Score:5, Insightful)
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.
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.
You need some warning (Score:4, Insightful)
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.
Re:Seconded. (Score:5, Insightful)
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.
Re:Seconded. (Score:5, Informative)
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.
Re:Seconded. (Score:5, Insightful)
Re:Seconded. (Score:5, Funny)
Thats what they said about IE6
I think comparisons to IE6 count as Godwinning the thread.
Re: (Score:3, Funny)
They don't call it "auto insurance" for nothing!
Re:Seconded. (Score:5, Insightful)
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.
no it does. (Score:5, Insightful)
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.
Re:no it does. (Score:5, Insightful)
SSL isn't meant just for encrypting pages, it's meant for verifying identity also.
There are two solutions to this problem.
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.
2. buy a cheap ass certificate from godaddy for $10. Your domain registration likely costs this much as well, but we don't complain about that, do we? The service is actually worth $10.
Without the above, the ff3 presentation is correct, the certificate is bad and should not be trusted. Otherwise you're in real danger of man in the middle attacks.
Re:no it does. (Score:5, Informative)
As the article says. SSL does both. FF3 in particular makes the first completely unusable for no good reason. The web would unquestionably be more secure if all http servers switched to using self-signed SSL certificates in place of unencrypted connections.
The $10 certificates have essentially no value over a self-signed certificate. The only reason they even exist is that browsers make it so hard to use self-signed certificates.
The correct behavior is to allow self-signed certificates with no warning at all, but not display the yellow bar/padlock that CA verified SSL certificates do. Then they should drop support for all signing authorities that have only an automated check for domain ownership, since they are of next to no value. Warnings should still be generated for expired certificates and probably those signed by unknown CAs.
Re:no it does. (Score:4, Insightful)
Warnings should still be generated for expired certificates and probably those signed by unknown CAs.
Thats exactly what SELF SIGNED certificates are. (signed by unknown CA, namely the certificate holder himself)
Re:no it does. (Score:5, Informative)
WHat annoys about this is that FF doesn't support CACert, which is an 'Open' certificate outfit.
http://www.cacert.org/ [cacert.org]
I can buy a BS certificate from Godaddy.com for $10 and that's OK but a verified cert from CA Cert is no good. Go figure.
I run a small sideline business, and my whole yearly income would barely pay for a cert from someone like MS and the like. So I explain to my clients to click through the certificate BS. I'm after the in-route encryption; my clients know who they're connecting to.
same argument everytime (Score:3, Insightful)
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
Re: (Score:3, Insightful)
SSL isn't meant just for encrypting pages, it's meant for verifying identity also.
By all means, suggest to us a way to encrypt a website that doesn't involve SSL.
There are two solutions to this problem.
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.
Right, so you'd favor asking users left and right to add CA's from potentially very insecure sources (how well does the average website secure their root cert?). If this would actually catch on I'd predict the entire system to crumble in a few years.
2. buy a cheap ass certificate from godaddy for $10. Your domain registration likely costs this much as well, but we don't complain about that, do we? The service is actually worth $10.
Without the above, the ff3 presentation is correct, the certificate is bad and should not be trusted. Otherwise you're in real danger of man in the middle attacks.
I'd agree it's not that costly. However FF3 did go a little bit over the top on self-signed certificates. I need to use those from time to time and having to click through like 5 tim
Re: (Score:3, Informative)
By all means, suggest to us a way to encrypt a website that doesn't involve SSL.
If you're only worried about form values, e.g. passwords, and dont mind if it's javascript-only, you can use a javascript implementation of public key encryption. I used this RSA one [stanford.edu] on our site until we got SSL working.
Re:no it does. (Score:5, Insightful)
Re:no it does. (Score:4, Insightful)
What's the point of encryption if you can't protect against man in the middle attacks? It might as well be security by obscurity at this point... what exactly are you getting out of your encryption if you can't guarantee that no one is sniffing your packets?
Re:no it does. (Score:5, Insightful)
From the article:
'This ignores the value of simple encryption. Snooping a connection (i.e. on a wireless link) is much easier than any of the impersonation attacks that SSL authentication prevents.'
You are acting as if security is an all or nothing affair. There is no such thing as totally secure. Every step just raises the bar.
Also, there is an open CA that Mozilla doesn't include either. It performs the same domain verification that godaddy and others perform, checking that you have control of the DNS for the domain.
Re: (Score:3, Insightful)
Man in the middle still imposes a directed attack on you. In many cases SSL is sufficient to just obscure information like passwords used at public sites like Slashdot.
I someone does a man in the middle on that it means that they really are out to get me and my password, but in that case they have already invested enough to also cause other problems so the Slashdot password is a minor problem. The encryption will do fine to avoid it being snooped while transferred over WLAN.
But of course - I would be pissed
Re:no it does. (Score:4, Insightful)
Is my ISP going to set up a man-in-the-middle-attack just to snoop what I'm downloading so it can provide targeted ads? I really doubt it. MITM attacks are much more sophisticated than the majority of snooping that happens on networks.
I am not saying that users should not be informed that a site is not "certified". I am saying that Firefox should not say that my site is "not legitimate" because I do have encryption, but no commercial certificate.
Re: (Score:3, Insightful)
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.
Find five. There's nothing disastrous in that message. The icon doesn't even have a red exclamation point. It states quite clearly what's gone wrong and offers the option to get past that. If a small business needs to self-sign their certs then a little education of their users prior to switching over to the SSL channel would quickly remo
Re: (Score:3, Insightful)
Find five. There's nothing disastrous in that message. The icon doesn't even have a red exclamation point. It states quite clearly what's gone wrong and offers the option to get past that. If a small business needs to self-sign their certs then a little education of their users prior to switching over to the SSL channel would quickly remove any reservations they might have about proceeding.
that is to you. a registered slashdot user, who is probably working in an i.t. related field, or geeky enough.
i hate to break it to you pal, but we dont constitute the majority on the web. we are at best a noticeable minority. web is comprised of billions of internet users that cant tell firefox from ie, leave aside recognizing that 'there is nothing wrong' with that message.
to average web user, that warning would mean 'youre being screwed, run away from this website asap', REGARDLESS of what technic
You missed a couple of very important points. (Score:5, Insightful)
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
Re:You missed a couple of very important points. (Score:4, Informative)
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.
That's good. I'm fine with that. "Secure by default".
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.
http://projectdream.org/~lb/ie7-unknownca.jpg [projectdream.org]
IE7's error message and behaviour are slightly different - first, accessing the site anyway is a single click. However, that click will be necessary each time you try to access the site. When you want to make the trust permanent, much more convoluted steps are necessary (around 10 clicks through a variety of property dialog boxes, and even more complicated on Vista).
Just because I want to have the possibility of encrypted traffic for visitors to my website
Encrypted traffic doesn't mean much when everyone can go inbetween you and them. MITM attacks against self signed certificates are easy to do.
Most hobbyists websites do not require SSL - if you host a discussion group or anything similar to that, SSL is not required. MITM attacks are still easy, so you haven't lost or gained anything.
Or perhaps you can enlighten me with a use case for a hobbyist website that requires SSL.
Re: (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-loa
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:Seconded. (Score:4, Insightful)
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.
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?
Re: (Score:3, Informative)
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.
Re: (Score:3, Funny)
I'm going back to Telnet -- no pesky security certificates to worry about.
Re: (Score:3, Insightful)
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.
Why not use a startSSL cert then? (Score:3, Informative)
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 [startssl.com]? 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.
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.
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:I'd like to make my own decisions please..... (Score:4, Informative)
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)