What Would It Take To Have Open CA Authorities? 529
trainman writes "With the release of Firefox 3, those who have been using self-signed certificates for SSL now face a huge issue — the big, scary warning FF3 issues which is very unintuitive for non-technical users. It seems Firefox is pushing more websites in to the monopolistic arms of companies such as Verisign. For smaller, especially non-profit groups, which will never have issues with domain typo scammers, this adds an extra and difficult-to-swallow cost. Does a service such as this need the same level of scrutiny and cost since all that is being done is verifying domain and certificate match? This extra hand holding adds a tremendous cost and allows monopolistic companies such as Verisign to thrive. Can organizations such as Mozilla not move towards a model that helps break this monopoly, helping establish a CA root authority that's cheap (free?) and only links the certificate to the domain, not actual verification of who owns the domain?"
Not the first one... (Score:5, Interesting)
When Google Checkout came along, I figured I'd accept that too - so I started doing scripts on my web site to take Google Checkout payments.
This came to a screeching halt when I realized that Google Checkout payments (or at least automated CGI processing of them) would only be done through web sites with SSL certificates signed by one of the "Major Authorities".
I wasn't willing to shell out $100 (about half my yearly profit!) for the stupid certificate.
This FF3 problem is even worse - if you use SSL, your web browser would be screaming to your end-users that you're probably dealing with some hokey-untrusted individual!
Let's just say that in any respect, I won't be having any little buttons on my site recommending that people use Firefox...
I've expirienced this myself. (Score:5, Interesting)
Certificates ARE about ENCRYPTION (Score:4, Interesting)
it doesnt make a ZIT of difference if the site you are shopping from has a Verisign signed 256 bit certificate or a self signed certificate. almost all certs are encrypted with similar technologies encryption wise. if you are concerned with 'authenticity', you dont know a website or dont trust them or suspect them, you should NOT be shopping there in the first place.
yes, this move of firefox 3 is a VERY bad thing. it really pushes people to the arms of verisign, geotrust (which is verisign) and so on.
not only that, it will also force control panel companies like cpanel, which serve millions of website users through web hosts to have to force users of their services to pay for SSL certs for each server they use or let their users connect to their site control panels through unencrypted connections. that will eventually drive up prices in the high to mid end hosting market. which is BAD, since majority of people host their websites in such small business hosts with $3-4 bucks a month. the overall effect that will have is yet to be seen.
yes, this was a stupid move by mozilla team, unfortunately.
FF3 is right (Score:3, Interesting)
This FF3 problem is even worse - if you use SSL, your web browser would be screaming to your end-users that you're probably dealing with some hokey-untrusted individual!
If you're not willing to lay out as little as $15 for an SSL-Cert that will work on FF3, you are a hokey, untrusted individual!
A Trust Web for Victory (Score:5, Interesting)
Instead of relying on centralized CAs, and implicitly trusting these privileged monopolies, we could shift to trust webs [wikipedia.org].
It's like a social network. You trust who your "friends" trust, and distrust who they don't. With weightings, so some friends' and enemies' associations (and dissociations) count more than others Because some people you trust in their content, but not their judgement of who to trust (and vice versa, but probably more rarely).
Trust webs can perfectly simulate the current centralized trust model. You can just set your trust web to always trust whoever, say, VeriSign trusts, and ignore everyone else, which is what we get by default today. But you could tweak your trust web to say "If my grad student distrusts a site, then ignore whether VeriSign trusts it".
Such a trust web could therefore just ship set up with the current CAs the only trusted authorities, and work exactly the same as now. But we'd each have the freedom (or our sysadmins, who could lock the trust web changes away from normal users) to emphasize whoever we actually trust to influence our automated trust.
Independent authorities could "watch the watchers". So investigators with a reliable track record could become important "second guessers" to the "offical" CAs. People could make their reputation by proving a trusted authority has less than 100% good judgement. And the whole system can become more robust, instead of fracturing as soon as different CAs have different trust levels for different sites.
The technique and some SW is already available, for apps like PGP and others that rely on a Public Key Infrastructure. What's necessary for the critical mass that makes such a system work is for a browser like Firefox to upgrade to a trust web, with an easy and reliable UI with sensible defaults. Then we're as strong as the trust network in which we embed ourselves.
Re:Such a thing? (Score:1, Interesting)
Thats definitely not true. I know several people who only use Firefox after being directed to by a technical friend such as myself and will never got back to MSIE.
I will admit though the first FF3 gave me cert warning I was quite surprised and it took me a bit to understand what had happened.
Re:No (Score:3, Interesting)
If you have no guarantees about the identity of the person on the other end, how do you know that your session is really private, when it could be someone sitting in the middle, pretending to be the web site to you, and pretending to be you to the web site? It could be more private to someone casually eavesdropping, but if you're worried about privacy, you should be more worried about the person that has the resources to be that man-in-the-middle. You can't really have a private data exchange with someone who is essentially anonymous.
An open CA won't solve the real problem (Score:1, Interesting)
Any distributable app with a web interface that wants encrypted communication needs to generate a self-signed certificate. This is a case where having *any* third party sign a certificate is simply not feasible. And most users can't be expected to know how to generate their own cert.
It was bad enough in the past, with the increasingly alarming browser warnings, but now FF3 (in some cases) *refuses* to connect without even giving the option of a bypass. The only solution is to dig through 6+ layers of preference menus/tabs to add an exception via a completely un-intuitive UI.
The *real* solution is to de-couple encryption from host verification. It's silly to jump through all these hoops when all you want is an encrypted connection.
Re:CACert (Score:5, Interesting)
What do you mean CAcert has no accountability? They have a web of trust in place that actually checks IDs person to person. Thats more than Verisign does. All they do is charge a credit card.
A CAcert server certificate does exactly what it says it should, that the owner/controller of the domain is in control of the server. It does not verify the personal integrety of the person running it. Of course a Verisign certificate says exactly the same thing but some money exchanged hands in order to say so. But you're trained to trust it more because "its always been that way."
Personally I think browsers should ship with no root certificates installed at all, and the user can seek out and install the ones they trust. Have you ever looked at the list of default roots in your browsers? Can you verify that every one of them does more verification than CAcert does?
CAcert is getting close to being audited so that their root will be included in browsers by default. Does that change your stance regarding trusting their server certificates? If not you're going to have to start remembering to remove their root from each browser installation. While in there how many more are you going to remove?
It bothers me seeing people put so much blind trust in Verisign and Thawte and the likes. To take it a step further, have you ever gone out to your bank's web site and written down the fingerprint of their signature and attempted to verify it at your bank? 99.9% out there will say no.
The point of an SSL certificate is to secure the communications line, and to ensure the entity you're communicating with now is the same one you communicated with previously. Intentions of the person/server you're communicating with is outside of the scope. No amount of money exchanging hands will change this fact, yet Verisign has obviously convinced a lot of people to the contrary.
You think Verisign et al do that? How? +an idea (Score:4, Interesting)
You think Verisign et al reliably do that? How?
There was a /. story maybe a year ago about all sorts of obviously fake ones... what the major cert providers verify is that your payment cleared. Which is _something_ because there's SOME kind of traceability. But it's not much.
I don't really blame them, though, because the problem is fundamental. There's just no real way for them to verify someone is who they say they are, because we don't really have a definition of who that "we" is. It's not like the gov't issues you a social security private key at birth and each corporation too (not to mention going international)
So the thing keeping them secure IS the payment and the record of the payment, and the fact that so many people fall prey to phishing without a valid cert that no one cares.
*****
In my opinion, the best we can do is issue physically linked certs. Cryptographically identical to existing certs, this changes the people part - The certificate authority a) must require a payment, but there's no minimum they can charge b) mails a physical letter with a code c) makes an automated, repeating voice call with a code d) if both codes are entered and they own the domain, issues a cert for that contact info, which can optionally be used to generate certificates for multiple servers.
Now, the hard part is that you haven't verified IDENTITY at all, you've only verified contact information. So the browser would have to literally display this information, if it was one of these contact-certs (perhaps in a bar just below the URL bar) I say in 'these certs' because for these certs you're not even implying that you can trust anything except the
You COULD set this authority up with a relatively small expense. You might be able to write a FF extension to display the addresses. If you have reasonable internal security, you probably could get FF to add you as a trusted authority, at least FOR contact-certs.
That's not GREAT, but it's the best we can do for simply automation for general-purpose merchants/certs... beyond that it's trying to do credit and background checks the old fashioned way.
My only OTHER idea is that the FDIC/NCUA/etc ought to get together and create a CA for US banks. Then you could even make the bank-trusted bar a DIFFERENT color. And presumably the regulators have a secure way to talk to the banks. (I'm not suggesting that this be legally mandatory for the banks to sign up for or use, but I think there's no one who is more likely to be able to authentically verify the authenticity of a US financial institution than the US regulators...)
Re: Counter to "Recommend Firefox" (Score:3, Interesting)
Re:CACert (Score:5, Interesting)
Actually you are way off base here. Mozilla and VeriSign are both members of the W3C Web Security Context working group where one of the things that we have been working on is how to better make use of self signed certificates.
I always enjoy reading articles on Slashdot describing what they imagine the optimum strategy for a large public company is.
Making it easier to use encryption with self-signed certificates is a benefit to a large commercial CA. People who use self-signed certificates today are candidates for an upsell to a public accredited domain validate cert later.
The basic problem is that people think that a CA sells encryption, that is wrong, we sell authentication and in the case of Class 3 or EV, accountability. I cannot guarantee that the merchant you buy from is honest, or that they will deliver that plasma TV. But I can ensure that they are likely to face consequences if they do.
If people really want to set up an open CA then read my book, the dotCrime Manifesto, I describe what we were trying to do when we set up the idea of CA services in the first place. I think that setting up an open CA would be a bit like setting up an open source effort to do people's taxes for them. But someone might work out a way to make it interesting enough for the participants to have it done well.
Re:CACert (Score:5, Interesting)
They're revoking a certificate roughly every hour, their CRL is 1.9MB in size and from looking at the serial numbers it seems that lots of certificates are pretty close to each other, which means that a significant percentage of issued certs is getting revoked.
This would indicate that their loose verification is being severely exploited by the bad guys.
Now are you completely sure that when you add this CA to your store, you also configure the CRL handling properly? For how often do you schedule download of the CRL? Do you really think it's a good idea to download a 1.9MB CRL every 1 hour (there's no OCSP service for their certs, it seems, at least there's no OCSP URL on their CA certs)?
I suspect that you didn't give a thought to this, as well as the majority of people who install CAcert root certificates in their browser, not suspecting what can of worms from security perspective do they open. They probably don't even know what a CRL is for, not to mention checking the CRL handling settings in their browser after they install CAcert's root x.509.
Re:CACert (Score:3, Interesting)
Sure. You're supposed to trust that your connection between you and the other end of a conversation using that cert will be encrypted.
That's all certs have ever provided; the rest is 100% marketing myth on the part of the CAs, and misunderstood excuses on the part of conspirators like the Mozilla foundation, Microsoft and so on. The fact is that any cert can be compromised within seconds after it is issued, and so can browsers, hosts lists, and a long list of other target; therefore, certs provide NO assurance you're connected to who the URL indicates you are. The idea that doubtful protection against "man in the middle" attacks are worth the cost of the CA infrastructure is ludicrous. But as long as browser manufacturers continue to collude with the CAs, there's no way out for any site that doesn't want their visitors smashed over the head with entirely bogus errors and warnings.
As far as Firefox is concerned, it's open source. Someone should take it and fix it so that it stops with all the consumer warnings and just says "encrypted connection established." Just go AROUND the CAs; they're total scams anyway. You don't need an "open" CA, you need to tell them to take along walk off a short pier.
While they're fooling with FF, maybe they could fix more of the darned memory leaks. After running FF 3 for about 24 hours, it's consuming an obscene 200+ MB here; and it *starts* at about 40 or so, which is also absolutely ridiculous.
Re:CACert (Score:2, Interesting)
Can't you get a short-lived certificate from CACert? Could what you point out be the expiration of those shourt-lived certificates? I thought that they have multiple levels of trust, some levels of which include having trusted people confirm your identification.
I don't know much about this stuff, so I'm not trying to be snarky, just asking.
Re:You've missed the point (Score:2, Interesting)
There's a middle ground, you know. What if I just don't want my user's passwords flying unencrypted over the wireless when people log in to my BBS?
Seeing how the majority of users will use the same password for everything given the chance, everyone benefits by having less unencrypted traffic flying around, even for simple hobbyist pages where the owner don't want to shell out cash.
I'm not aware of any way to get just the encryption without the certification hassle. I think you'd see encryption used a lot more uniformly on the common web if browsers wouldn't raise a scare to your users when you self sign.
Re:CACert (Score:5, Interesting)
Sounds perfectly fine to me.
First, what the CA's actually consider "authentication" before issuing a cert is laughable. It ensures nothing except that your credit card wasn't declined.
Second, most people DO NOT pay attention to who the certificate was issued to. Most people don't even know a certificate exists, much less how to see who it was issued to.
Third, especially because of the previous 2 point, a LOT of people really don't care to try and provide those feature. All they want is SSL, so that info isn't transmitted in plain text. If there were a way to do SSL without a CA, that would be great, but as it is you are held hostage to either paying for a certificate or making your website users jump through hoops to accept a self signed cert.
Re:CACert (Score:3, Interesting)
Re:CACert (Score:3, Interesting)
At last a well researched reply :)
You've probably missed some hypothetical ones.
These are probably the most likely to succeed - especially the second one since the human is usually the weakest link.
Re:CACert (Score:3, Interesting)
Sigh. The point of encryption is to hide what you are saying from some people, while revealing it to some other people. Do you really not understand that you can't do this if you don't know which people you're talking to?
The point of SSL is validation, then encryption. Without both, it's useless. And if you were paying attention to the noise about DNS cache poisoning last week, you should know that, without validation, SSL is truly useless.