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

CACert

[Anonymous Coward]

try it....

Re:CACert

[zerOnIne]

Seconded. go here [cacert.org].

Re:CACert

[Anonymous Coward]

Which doesn't answer the question as their certificate isn't supported in Firefox.

Certification crap

[Anonymous Coward]

First of all, what does this certification crap prevent?

I go to randommalwaresite.com, I get a certificate for randommalwaresite.com!

HURRAY!! Everybody is happy. WTF?

Re:CACert

[sakdoctor]

The cert isn't included in any browser your are likely to use.

http://cert.startcom.org/

[Anonymous Coward]

or create your own CA with a link on the http site to install that root cert on the browser.

Try Godaddy

[tedhiltonhead]

Godaddy has a very simple SSL cert option that only validates that the certificate issued matches the domain registration info, which is super cheap.

IE7

[airedalez]

Why is this being brought up now as something new? IE7 has been doing practically the same thing since it was released. I agree that there should be something "open source", but this is far from new...

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:CACert

[rufus t firefly]

It isn't *included*, but it's definitely *supported*. Just go here [cacert.org] with Firefox to install their root cert.

Re:Certification crap

[qbwiz]

First of all, what does this certification crap prevent?

I go to randommalwaresite.com, I get a certificate for randommalwaresite.com!

AFAIK, I believe it prevents man in the middle attacks from happening:

You go to mybank.com, but you actually access randommalwareip, which gives you a phony certificate from mybank.com.

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 [rapidsslonline.com]

And unlike godaddy that on is not a chained cert.

Secure DNS can help

[John.P.Jones]

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?

How can anyone possibly establish that a given certificate is associated with a given domain without first proving that they do indeed have the (ownership) rights to establish said association?

What you are asking for can be accomplished via SecureDNS, you can enter the hash of the certificate in the DNS entry and Secure DNS ensures that only the authorized party can enter that association and verifies that it was not changed. SecureDNS facilitates a lot of these kinds of authentication issues by extending the rooted hierarchy of DNS names to securely dissiminate information, whether it be IP addresses of servers or public key commitments. See my paper "Layering Public Key Distribution Over Secure DNS using Authenticated Delegation" (ACSAC 2005).

Re:No

[Anonymous Coward]

Counterpoint:

I basically run the IT division for our organization. If we purchased for-sale SSL certs it would cost us thousands of dollars per year on something that I can generate, for free, for the various secured services we provide (both internally and externally) for the employees of this organization. There's simply no reason to do so, especially when the reason for the SSL cert is for the sole purpose of encrypting traffic between client and server.

Instead, we use a self-signed CA cert and deploy the public part of the CA cert to all machines that use the services. That way, even Firefox 3.0 doesn't care. I don't see why you couldn't provide a similar service where you could make the site's self-signed CA cert available before signing into the SSL-encrypted part of the site.

StartSSL is free or cheap, as you prefer

[petard]

They offer certs with domain validation for free. There are gentle attempts to upsell you to higher levels of validation, but their domain validated certificates work without errors. Look here [startssl.com].

If you want certs that are validated to your business' identity (instead of just your domain) and don't indicate in the DN that they were free, there is a small charge.

Re:Try Godaddy

[bigtangringo]

Sorry, but you have no idea what you're talking about.

GD gives you a full blown SSL cert that works just like what you would get from Verisign.

$30 for a standard cert, $200 for a "wildcard" cert which lets you SSLize all your subdomains.

Re:Try Godaddy

[jagilbertvt]

Untrue.

You can get a chained cert for very cheap from godaddy (and others) that will use your own domain name (www.yoursite.com).

Re:Not the first one...

[nine-times]

I wasn't willing to shell out $100 (about half my yearly profit!) for the stupid certificate.

It's not quite as bad as all that. Namecheap offers "RapidSSL" for $13 a year. They even have a deal [namecheap.com] where you can get a free SSL cert with registration or transfer of a domain. Still, yeah, SSL certificates are kind of a racket.

Re:I've expirienced this myself.

[duffbeer703]

In your case, it's probably appropriate to ask your uses to add CACert or a self-signed certificate to their browsers. This isn't rocket science.

Re:CACert

[noa]

No.

I have bought a few "commercial" certificates from vendors in a capacity as consultant, and I use cacert certificates for my private work and their verification of domain is very similiar. You need to have access to the email sent to at least one official looking email address associated with the domain in question (you may choose from a short list of names like root@domain, hostmaster@domain, postmaster@domain etc.)

In other words, you couldn't get a cacert certificate for a domain you can't read the email for. The security of the process is not perfect, but it is no worse with cacert than it is with the other certification authorities.

Re:Such a thing?

[mistapotta]

My mother is a non-technical firefox user. Meaning, I got tired of cleaning up her machine, so I installed firefox, put the little IE icon on her desktop to link to the FF executable, and have had much fewer reasons to go over and "clean up her computer."

Re:I doubt it will happen.

[bigtangringo]

I wasn't involved in the auditing process when the company I worked for started it's CA, but I believe that assessor is WebTrust. The fees are... significant; as are the physical and technical security requirements.

CA signed certificates aren't quite a license to print money, but almost.

Complying with SOX, PKI, and PCI security requirements all at the same time was an interesting experience.

Re:CACert

[mindstormpt]

Actually you can only get a certificate from CACert if you've been assured with enough points, and that's only supposed to happen after in-person ID verification by multiple members. The certificate includes the verified identity of the member, or the organization if that's the case.

You can debate if this web of trust model is acceptable, but it's been used by Thawte for some time now, and its certificate is included in every browser.

Re:No

[Anonymous Coward]

where i work we purchased a wildcard certificate (*.domain.com) from netsolssl.com for 419$.

while id like it to give us the ability to sign our own cert from it, limited by the CN component, right now we just deploy the same cert to our different servers (admitedly for a bit more risk, but still very low considering our overall exposure)

Re:CACert

[theodicey]

StartCom [startssl.com] is free and already supported by Firefox.

Mozilla just wants CAs to offer some level of accountability and identity verification. Their CA certificate policy [mozilla.org] 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.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:Certification crap

[bigtangringo]

Certificates don't do that, they guarantee you're talking to the domain you expect to be talking to. CA signed certs prevent man in the middle attacks.

That's it all certs do. If the box you're talking to was hacked, tough. That's outside the scope of SSL certs.

Re:StartSSL is free or cheap, as you prefer

[Anonymous Coward]

True I know this is slashdot but if anyone took the time to read through the list of CA's, startssl has its CA listed in FF3. And it offers free ssl certification.

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.

Re:No

[Aliencow]

Get a wildcard certificate or a UCC. UCCs let you have multiple hostnames on the same domain, and they aren't so expensive.

Please. Don't give money to GoDaddy.

[weston]

http://en.wikipedia.org/wiki/GoDaddy#Controversies [wikipedia.org]

This is to say nothing of a number of lower profile controversies and the fact that their entire site is a usability nightmare that seems largely designed to trick marginally informed customers into buying (and cause more savvy customers to explode in frustration).

Re:You've missed the point

[rufus t firefly]

It looks like someone has already started the process [mozilla.org] for Firefox, at least.

Re:CACert

[NNKK]

If by "several" you mean "several owned by VeriSign", you're correct. They operate under multiple brands and have purchased a number of other major certificate authorities over the years.

Re:CACert

[noa]

And my point was that there are commercial certificates (RapidSSL springs to mind) accepted by IE and Firefox that doesn't require any authentication besides having control over the domain. You won't get a meaningful name in the cert, except OU=Domain Validated, but you will get an SSL connection without browser warnings

IE7 / StartSSL

[bunratty]

IE7 is worse, because its user interface does not ask the user if they want to add the site as an exception as Firefox 3 does. The end result is you get the big, scary warning in IE7 every time you visit the site, but you get it only once in Firefox 3 because you need to add the exception before it will let you proceed to the site.

Anyway, get a free cert from StartSSL [startssl.com] and the problem is solved.

Re:Not the first one...

[bradgoodman]

>> I'm pretty sure I paid more in taxes out of one paycheck a month than you've collected in 4 years at $200/year.

I'm sure you do. Irrelevant.

>> Again, FF's fault how?

Its not - it has to do with root CAs...like the title of my post implies (let me clarify) [Firefox is] "Not the first one..." [Google Checkout does this too]

>> It's not like it's impossible to accept a self-signed cert, and for all the "scripting" you've done, why don't you mention a quick blurb about FF3's advanced certificate security and validation mechanisms and how a user might go about accepting your self-signed cert.

I agree. Not impossible. It's a source of confusion for those who don't understand, and a just pain in the ass for those who do. And 99% of the time, your not securing financial transactions, your encrypting pages on the bug tracking database at work, or something mundane.

Re:CACert

[Crayon Kid]

If anybody can get an SSL certificate that will be accepted by Firefox, for free, no questions asked... then the entire point of having CA authorities goes down the drain. You can't simultaneously have a certifying entity AND let everybody in. Because if that happens we might as well forget about CA use in the browsers and just use SSL for encryption.

Re:Will Firefox do anything about it? No.

[StartCom]

That's pure nonsense. No CA ever paid a dime to the Mozilla Foundation or Mozilla Corporation (as opposed to the days of Netscape). Poke around http://groups.google.com/group/mozilla.dev.tech.crypto/topics [google.com] to get a clue about how Mozilla handles inclusion of CAs.

Comment removed

[account_deleted]

Comment removed based on user account deletion

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

[Cyberax]

It's much more stricter now. For one thing, they don't sell certs to individual, only to companies. And they also physically mail you a USB signing device for driver signing, not just a certificate.

Re:CACert

[the_olo]

How does this compare to other authorities like Verisign? How frequently does Verisign revoke a certificate? If it's not very often, should they be revoking more than they do?

Well, let's have a look.

Verisign has a much more complex pki hierarchy, so there are much more different CRLs. I've visited my local bank's site and had a look at their cert's chain. There were 3 levels of Verisign CAs above their x.509 cert and two of them had CRL distribution points specified (the top one, Verisign Class 3 Public Primary Certification Authority, had none, but I think it didn't need one since it's highly unlikely that the lower ones like Verisign's Class 3 Public Primary Certification Authority G5 will ever be compromised. They still have a 3rd level below and their 2nd level private keys are probably used only in high security, do-everything-manually-inside a-vault-by-a-highly-trusted-personnel-group context, not for signing any customer's certificate requests).

So I downloaded both CRLs:

$ wget http://crl.verisign.com/pca3.crl
$ wget http://evsecure-crl.verisign.com/pca3-g5.crl

and then inspected them:

Certificate Revocation List (CRL):
Version 1 (0x0)
Signature Algorithm: sha1WithRSAEncryption
Issuer: /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
Last Update: Apr 29 00:00:00 2008 GMT
Next Update: Aug 14 23:59:59 2008 GMT
No Revoked Certificates.
Signature Algorithm: sha1WithRSAEncryption
a4:ff:fd:d1:4c:b8:e9:70:d5:d3:90:8c:85:64:e4:8e:36:21:
e8:b0:54:1d:2f:31:ac:00:92:9e:c9:42:d7:0f:c4:86:21:a3:
8f:23:f3:8b:e5:2d:5f:48:bd:ab:29:29:39:80:d1:b0:85:59:
ad:84:2a:d5:e9:1e:b1:8a:d4:44:97:5c:44:15:a1:61:64:49:
83:1f:12:b9:08:63:6c:8c:4b:2d:31:61:45:ae:1f:9a:8c:32:
e9:3f:86:1b:15:02:0d:30:9c:ae:d9:53:0c:cc:d1:2c:ec:6a:
57:db:c3:60:67:a4:a6:42:a2:72:37:8d:48:68:84:cf:2c:67:
b2:8f:60:6c:f4:2c:e4:90:71:88:1b:87:31:e5:88:b4:eb:dd:
38:17:7f:9b:f9:02:52:e1:03:b3:3e:7b:9f:1b:8f:5a:81:24:
ba:6d:9f:77:c7:db:53:88:89:8e:f5:b2:ff:79:51:e9:8b:ea:
f2:e2:dd:1c:52:d6:1c:d8:24:2c:f6:ac:a4:11:43:1b:6b:c8:
55:1b:b1:f0:e7:38:a8:f7:41:67:26:be:5b:b4:9f:da:a6:f7:
d0:f5:64:f9:68:83:28:b5:b4:86:90:92:a4:8d:95:36:78:42:
53:92:5f:92:9d:6c:60:95:59:d1:bb:e0:fe:0d:02:a0:31:74:
6f:1a:7c:04

Certificate Revocation List (CRL):
Version 1 (0x0)
Signature Algorithm: sha1WithRSAEncryption
Issuer: /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
Last Update: Jun 5 00:00:00 2008 GMT
Next Update: Aug 16 23:59:59 2008 GMT
Revoked Certificates:
Serial Number: 01761E18E2BC615F3EDEDD32A5B9FD0E
Revocation Date: Sep 24 16:48:23 2002 GMT
Serial Number: 112C147CE97CF5EF8C3CB4E9E46A2099
Revocation Date: Jun 5 17:49:07 2008 GMT
Serial Number: 156079D71A719DDB94BBE7DE9F66681B
Revocation Date: Sep 23 17:14:00 2002 GMT
Serial Number: 1C3F41C5C0161761816E4660A350F0A0
Revocation Date: Sep 23 17:15:48 2002 GMT
Serial Number: 1ED2FBD389179A0C9FFD52A065BD3533
Revocation Date: Feb 7 21:24:58 2001 GMT
Serial Number: 219185AE83A9BB59E5B1B5495369EEE3
Revocation Date: Jul 6 17:14:11 2001 GMT
Serial Number: 242DE0F2497B72DD901816753CE95F2E
Revocation Date: Apr 3 17:22:26 2008 GMT
Serial Number: 26F29D223FB00479A7BA35317D851331
Revocation Date: Jul 6 17:21:18 2001 GMT
Serial Number: 341BA0A1D332DDF1FD107B578DC7F0B5
Revocation Date: Jun 5 17:50:30 2008 GMT
Serial Number: 42F5B783B86305DDB50303E5B7D01BCD
Revocation Date: Apr 11 17:59:10 2007 GMT
Serial Number: 48DC5079C688954ECE8AA7BD2A20E7A9
Revocation Date: Feb 7 21:20:31 2001 GMT
Serial Numb

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.

Re:A difficult and hard to swallow cost?

[the_olo]

I don't see them in my CA collection that shipped with Firefox 3.0.1pre. What's their browser coverage?

Re:CACert

[Anonymous Coward]

Hi Bill,

I can see your CAcert account, yes it is "Lord God" but you just cannot create a certificate with this name as you are not assured by other people verifying you id papers.

in case, please write to support (at) cacert.org

Best regards,

Guillaume (guillaume (at) cacert.org)

Re:CACert

[Anonymous Coward]

Hi,

That is wrong we have an ocsp responder in the root certificate.

and the ocsp responder is working.

You can test
https://bugs.cacert.org/ in the next days.

the certificate has been revoked (and will be replaced asap)

I have only OCSP responder configured in FF3. And you get a message "sec_error_revoked_certificate" + message in french

We'll look at the revocation, maybe in it normal. we've issued 100.000 certs so far since 2003. one each hour is not much (over 5 years, it would be 40%)

Best regards,

Guillaume

Re:CACert

[nog_lorp]

Heap overflows can be just as dangerous as stack overflows, although nontrivial to exploit.

Stack overflows are preventable too though.
Overwriting returns via stack overflows are totally preventable by using a separate stack for storing return addresses (as in Forth).
Data overwrites are preventable in varying degrees with sentry values.