What Would It Take To Have Open CA Authorities?

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?"

Comments

CACert

[Anonymous Coward]

try it....

Re:CACert

[zerOnIne]

Seconded. go here.

Re:CACert

[pablomme]

Or even better, go here, since the above address is an https and Firefox won't accept its self-signed certificate..

Re:CACert

[theodicey]

StartCom is free and already supported by Firefox.

Mozilla just wants CAs to offer some level of accountability and identity verification. Their CA certificate policy is explicit in its requirements.

I don't see the point in having Verisign certificates eveywhere, but I also don't see why you should blindly trust a Robot Certificate Authority like CACert, without further assurances.

Re:CACert

[Anonymous Coward]

Given the general security principle, espoused by most web browser makers, of "Trust nobody unless it's a secure connection, and even then be careful"...

Actually, the principle espoused by most web browser makers seems to be "Trust anybody if your connection is unencrypted, but if you wish to encrypt your traffic, trust no-one unless they've given a wad of cash to a CA."

It seems to me that a user using an unencrypted connection to an unidentifiable web site (that is to say, all http web sites) should receive even more warnings than a user using an encrypted connection to an unidentifiable web site. But somehow, that's not the case.

This Firefox scaremongering isn't just driving people into the arms of Verisign, it's also driving webmasters away from using encryption, even where web forms might be involved. Too bad - encryption is a good thing.

Re:CACert

[tha_mink]

Have you ever applied for an SSL certificate? It's a PITA, because you do have to provide the issuer with a load of documentation (usually comprising of some legal documents such as your employer's charter et al, plus evidence you do, actually, work for them) to confirm you're who you say you are.

What are you talking about? I buy SSL certificates ALL THE TIME, and it couldn't be easier. It's easier than buying the domain name. It's automatic and happens in seconds these days. I have no idea where you get your certs from but yo, you don't seem like you know what the hell you're talking about.

Re:CACert

[jjhall]

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.

Re:CACert

[darkfire5252]

Why do you need identification to transmit a PUBLIC key (aka SSL cert)? Note: The moderators in this discussion who nuked my other post, like the parent, seem to not understand the difference between public and private keys. Crypto is complicated, but those who don't understand it should not be moderating a crypt discussion!

Nor should they be posting in it. You do not understand the difference between a key and a certificate, nor do you understand the purpose of a certificate authority.

In public/private key cryptography, the public key ensures that one can have a secure conversation with the holder of the corresponding private key. It does not address the problem of verifying who the holder of that key is. So, if Alice and Bob desire a private conversation using asymmetric (public/private) key cryptography, the first step is for them to exchange public keys. However, during the exchange, Mallory intercepts Alice's public key and supplies Bob with Mallory's public key. Mallory can now read the messages between the two and no one is the wiser. Enter the Certificate Authority. The CA's job is to act as a foundation for trust. The CA's key is provided to Alice and Bob securely (i.e. when installing an OS or browser). Alice and Bob can then go to the CA, prove that they are Alice and Bob, and they receive a certificate. The certificate for Alice consists of Alice's public key cryptographically signed by the CA's private key. Bob can then take the CA's public key, which he received previously, and verify the signature on Alice's public key. Bob has then proven that the CA is stating that that public key does in fact belong to Alice.

So, if the CA isn't actually verifying that Alice is Alice or that Bob is Bob, then Mallory can get a certificate that states Mallory is Alice, and we're back to square one.

Re:CACert

[jd]

All possible attacks against certificates are purely hypothetical at this time. These would include:

• A poor, seeded PRNG being used where the seed is somehow exposed or part of the key - such as a simple hashed value of the same information that is made public, where the PRNG algorithm can be determined and reproduced in some way
• Someone has figured out a solution to the factoring problem, breaking RSA
• The effective key length is so short that the private key can be brute-forced

There are also two attacks against infrastructure which can compromise a key:

• The machine generating the key pair has been compromised in advance, with private keys intercepted and copied elsewhere
• Any machine subsequently storing the private key has been compromised, allowing the private key to be stolen

Of all of these, the last one is the only one anyone needs to take seriously. Even then, there are plenty of ways of making directories and files very secure, and making sure that potential exploits like buffer overflows are blocked in advance. (Just use a malloc replacement that prevents them.) The other attacks are so improbable that you can ignore them.

This leave one other attack vector:

• Social Engineering

This, according to reports, was used to obtain Microsoft's private keys from Verisign. Most reputable cert vendors have established better practices now. Simply choose one that will only deliver keys to an authorized contact point and only after a call-back check or some other authentication scheme.

Not the first one...

[bradgoodman]

I have been using PayPal for many years for automatic payment processing on my web site for shareware I sell.

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...

No

[squiggleslash]

One entire point of SSL is to ensure that the user can trust the site they're connecting to. If I register citicardbank.com, my inability to get an SSL certificate for it without being traced by my phishing victims severely undermines my ability to rip people off.

The only way to get what you're asking for is to get a secondary protocol, somewhere between HTTP and HTTPS, that would provide privacy for the communication link but wouldn't promote the notion that the end domain is what it says it is. Whether such a thing is a good idea is open to question, even if it is desirable.

If push comes to shove, the only problem with the present regime is that it's expensive. There's increasing amounts of competition in that space, so you should expect prices to come down over time. Wait. .com domain names once cost more than what many SSL certs do today.

Re:No

[squiggleslash]

First of all, that's not in any way, shape, or form, a counterpoint.

Are you using different top level domains for all your systems? Because if you're not, you should be able to make do with a wildcard SSL certificate, which generally runs to a few hundred dollars per year, not $1,000. Just saying.

In any case, your particular set of circumstances means you have control over who would need the self-signed certificates. In particular, you can legitimately create a CA of your own and import it's certificate into the web browsers of your users, because that CA (you) is accountable to you and your users.

This is very different from someone outside of the organization trying to get "secure access" to your systems, not knowing for sure that they really are connecting to you (and not a typosquatter.)

Monopoly?

[nonpareility]

The fact that there are "compan*ies* such as Verisign" means Verisign is not a monopoly. In Firefox, go to Tools, Options, Advanced, Encryption, View Certificates, Authorities. These are all valid CAs according to Firefox. As for being cheap, a quick check at GoDaddy's says you can get one from them for $30/year.

Re:A difficult and hard to swallow cost?

[cstdenis]

Don't buy from GoDaddy. There are better and cheaper alternatives.

$14.95 - http://www.rapidsslonline.com/rapidssl-certificates.php

And unlike godaddy that on is not a chained cert.

Certification trust levels

[davidwr]

The certification authorities really need to get together with the web browser vendors so the big scary warnings can be made trust-level-appropriate.

For example:

Domain confirmed: [green][yellow][red]
Responsible Party Identity Confirmed: [green with seal][green][yellow][red]

Where "yellow" meant unconfirmed or self-signed and not whitelisted SSL or an easy-to-fake or -steal ID such as a credit card, "red" meant revoked, expired, or invalid credential, and "green" meant a valid SSL or hard-to-fake or -steal personal ID such as a driver's license backed by a notary. "Green with seal" meant a financially-backed guarantee, something big banks would probably get.

Most small-time web sites would be either green/yellow or yellow/yellow, depending on if they had self-signed certificates.

The cost of a "no identity confirmed" green/red certificate shouldn't be much more than domain registration. A "yellow/red" self-signed certificate would remain free.

If people expect "green with seal" when dealing with major financial companies, "green" with most businesses, and "yellow" for personal web sites, they'll give the appropriate level of trust.

A Trust Web for Victory

[Doc Ruby]

Instead of relying on centralized CAs, and implicitly trusting these privileged monopolies, we could shift to trust webs.

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.

Does No One Understand English Any More?

[Illbay]

The O.P. mentions "...monopolistic arms of companies such as Verisign."

Okay, look. The word "monopoly" has as its prefix the stem "mono-," from the Greek, meaning "one." That means there can only be ONE "monopoly."

A phrase such as "monopolistic company LIKE Versign..." is absurd on the face of it. If there are other companies LIKE Verisign, then there is no monopoly.

Is it REALLY that hard to understand?

This is an example of how the rising generation is so used to "buzz words" chosen for shock value, etc., and has gone completely away from clarity of speech and writing. What the O.P. means to say, really, is "I don't want to pay the going rate for this service, so I'll call Verisign 'a monopolistic company' because everyone knows 'monopolies' are bad, and that will communicate the 'badness' of 'companies like Verisign.'"

Oddly, the word "rhetoric," also from the Greek (rheteros, "a speech") used to be a positive appellation for the study of good, clear communication of thoughts and ideas. But it has also succumbed to the buzz-word dementia, and now usually means "empty words."

How sad.

Re:Certificates ARE about ENCRYPTION

[Rakishi]

The problem as I understand it is that self-signed certificates are NOT as secure. Specifically a man in the middle attack can easily fake a certificate because your site needs to send the public key to the user in an insecure way (ie: third party intercepts public key, send their own public key, to you they look identical).

The point of a CA is to prevent this by having a public key come pre-loaded on your machine so there is no possibility of successful interception (ie: the replaced public key would be rejected by the CA).

Re:Certification crap

[jd]

Let's start with a Man-in-the-Middle attack. Attacker finds an unpatched DNS and points www.somebank.com to their proxy that has SSL support. A user connects, thinking it is their bank. It looks like it, because it really is the bank's website that is being displayed, and the URL is correct. The user enters their account login information, because it's a secure site. The proxy, of course, decrypts the inbound user SSL traffic, stores username/password information, re-encrypts using the bank's SSL session and forwards to the bank. The bank never knows it's not the user - it's encrypted, after all, and it is all correct.

The idea of certificates is to authenticate the connection, make it impossible to someone in the middle to pretend to be the server to the client, and the client to the server. Actually, it would be better to require users to have certificates as well, in many cases, as passwords tend to be too trivial.

Now, the price of certificates is horrendous. The passport office provides a document as good, or better, than many certificates, but it doesn't cost many hundreds of dollars to obtain a passport. In fact, as digital certificates are essentially the same as a passport with electronic information, it might be better if the passport office issued digital certificates along with physical passports as a combined package. The added cost to them would be practically nil, and the certificates would have a much greater credibility level than those by most corporations, at least for personal certs.

I think FF3's cert thing is lamer and lamer

[arete]

I think FF3's cert thing is lamer and lamer

I've been thinking about this... and I'm happy to have FF3 mark the unsecure, secure, and EV-secure sites differently. But it's really, really lame to say that any self-SSL site is WORSE than a random non-SSL site. It's only the same. If they're going to go through the trouble of getting people used to trust markings, they should just mark the self-SSL sites like they mark the unsecure sites. Changing the URL bar to say:
(unverified) https:///

Would be enough, if they were changing the color/style of the secure sites. (Sure, don't give the self-SSL a lock icon. Fine.)