Slashdot Mirror


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

7 of 529 comments (clear)

  1. Not the first one... by bradgoodman · · Score: 5, Interesting
    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...

  2. I've expirienced this myself. by vidarlo · · Score: 4, Interesting

    I run a small norwegian forum, and we use SSL. Since our income is around 100USD a year, which is donated by members, it would be very unfair to spend all of that on a SSL cert. However, how can one explain that there is no security risk involved in creating an exception when the browser so fiercly states that it is a huge security risk? It would be better if you just got a warning like "This site is probably not your bank"...

  3. A Trust Web for Victory by Doc+Ruby · · Score: 5, Interesting

    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.

    --

    --
    make install -not war

  4. Re:CACert by jjhall · · 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.

  5. Re:CACert by Zeinfeld · · Score: 4, Interesting
    ObDisclaimer: Not speaking for my employer here. Yes I work for a commercial CA.

    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.

    --
    Looking for an Information Security student project suggestion?
    Try http://dotcrimeManifesto.com/
  6. Re:CACert by the_olo · · Score: 4, Interesting
    Yeah, right.

    $ wget http://crl.cacert.org/revoke.crl

    ...

    23:04:36 (241.13 KB/s) - `revoke.crl' saved [1911370/1911370]

    $ openssl crl -in revoke.crl -inform der -noout -text | less -in

    ...
    Serial Number: 057FA5
    Revocation Date: Jul 18 13:35:01 2008 GMT
    Serial Number: 057FAA
    Revocation Date: Jul 18 14:54:49 2008 GMT
    Serial Number: 057FB4
    Revocation Date: Jul 18 14:43:07 2008 GMT
    Serial Number: 057FB5
    Revocation Date: Jul 18 14:43:26 2008 GMT
    Serial Number: 057FB9
    Revocation Date: Jul 18 16:12:12 2008 GMT
    Serial Number: 057FBB
    Revocation Date: Jul 18 14:59:13 2008 GMT
    Serial Number: 057FBC
    Revocation Date: Jul 18 17:48:23 2008 GMT
    Serial Number: 057FCE
    Revocation Date: Jul 18 16:13:58 2008 GMT
    Serial Number: 057FD0
    Revocation Date: Jul 18 16:11:48 2008 GMT
    Serial Number: 057FD1
    Revocation Date: Jul 18 17:00:35 2008 GMT
    Serial Number: 057FD3
    Revocation Date: Jul 18 16:18:22 2008 GMT
    Serial Number: 057FF3
    Revocation Date: Jul 18 19:43:57 2008 GMT
    Serial Number: 057FF4
    Revocation Date: Jul 18 19:52:50 2008 GMT

    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.

  7. Re:CACert by LordKronos · · Score: 4, 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.