Re: [Savannah-hackers-public] CAcert, IceCat, and savannah

[Sylvain Beucler]

Hi,

What I mainly understand is that a standard "audit" current costs
several $10000 which CAcert can't afford; that browsers' policies are
not so well defined; that Konqueror is just blindly following IE and
Mozilla; so to sum up: that a lot of things stand against the creation
of a certificate authority based on a web of trust rather than money.

I can't accept arguments such as "it's not pre-included" from people
who support an OS that is essentially never pre-installed. Similarly
restricting the problem to a money issue is like being OK with gratis
student licenses from a priorietary OS vendor.

Savannah isn't the only free-software-related website that supports
CAcert.org. See for example https://www.april.org/

CAcert is also the only certification authority that makes people
_think_ about what trust is, which can't be more in sync with the
educational purpose of Savannah.

Cheers,

-- 
Sylvain

On Tue, Oct 07, 2008 at 06:40:57PM -0500, Karl Berry wrote:
> Hello savannah hackers,
> 
> Giuseppe (cc'd) added CAcert to the root certificates in the last IceCat
> release primarily because of savannah starting to use it.  Reed Loden
> (cc'd) raised several concerns about CAcert.  Messages appended below
> (one from Reed, Giuseppe's reply, Reed's reply).
> 
> Reactions, please?
> 
> Personally, with my (very small, granted) savannah hat on, I think the
> problems Reed is pointing to are pretty significant, and savannah would
> be better off with the other certs that johns already purchased.
> 
> (Of course I realize that whether IceCat includes CAcert and savannah
> uses CAcert are two technically independent decisions, but it would be
> nice for GNU pieces to play nicely together.)
> 
> Karl
> 
> 
> ------------------------------------------------------------------------------
> Date: Mon, 6 Oct 2008 04:35:10 -0500
> From: Reed Loden <address@hidden>
> To: Giuseppe Scrivano <address@hidden>
> Cc: address@hidden
> Subject: CAcert.org's inclusion into IceCat
> 
> On Thu, 25 Sep 2008 00:10:12 +0200
> Giuseppe Scrivano <address@hidden> wrote:
> > In addition, CAcert.org, already used for https://savannah.gnu.org,
> > was added to the builtin root certificates.
> 
> I'm very disappointed by this decision. Considering all the
> well-documented problems with CAcert.org, this seems like a very bad
> choice to be making.
> 
> Just looking on CAcert.org's wiki, you can read some of the following
> pages to find copious amounts of information on why CAcert.org isn't
> ready to be used:
> * http://wiki.cacert.org/wiki/Audit -- Links to various other pages
> concerning CAcert.org's ongoing audit, especially their lack of a
> single completed audit
> * http://wiki.cacert.org/wiki/AuditToDo -- List of things left for
> CAcert.org's first audit to be completed; still a long ways to go until
> the audit is completed
> * http://wiki.cacert.org/wiki/PolicyDrafts -- Note the lack of set
> policies on how assurance is handled; how does one know that the
> certificates issued by CAcert.org for a domain were really bought by
> that domain if there's no set policy outlining how checks and
> validations are made?
> * http://wiki.cacert.org/wiki/InclusionStatus -- Links to several
> places that explain why CAcert.org isn't ready to be included; note the
> number of well-known browsers and operating systems who have yet to
> include CAcert.org because of CAcert.org's current ongoing issues and
> lack of a completed audit
> 
> There is also time in CAcert.org's history for which the security
> of its root cannot be properly accounted. What would happen if indeed
> the private key of CAcert.org were to be leaked out? People could
> create SSL certificates for any domain they liked, and they would
> all be accepted by IceCat without any regards to their validity.
> 
> Also, CAcert.org has issued both assured and unassured SSL certificates
> from the same root, which is insecure and highly not recommended. This
> is one of the main reasons Ubuntu refused to add CAcert.org's root back
> when it went through discussion in 2005. I'm not sure if CAcert.org is
> still issuing certificates this way, but just the fact that they have
> done it at some point in time is worrisome.
> 
> I believe you're doing a disservice to IceCat's users by including a CA
> root that hasn't been properly vetted and whose root cannot be
> accounted for for long periods of time. Users put trust into their
> browser's CA root repository that the SSL certificates they encounter
> will have been properly vetted for a certain level of quality. By
> adding CAcert.org with other vetted roots, you lower the quality of the
> other roots in the browser's CA root repository, as users won't be able
> to know who exactly they can trust.
> 
> If you're looking for free or cheap SSL certificates, CAcert.org isn't
> the only option out on the market. I do know that StartCom's StartSSL CA
> offers free class 1 DV SSL certificates, and there OV and EV
> certificates are fairly cheap, too. The StartSSL CA root has been
> properly vetted and audited, so it can be trusted just as much as a big
> name such as VeriSign.
> 
> Once CAcert.org completes its first audit and meets the basic
> requirements of policies such as the Mozilla CA Certificate Policy
> (http://www.mozilla.org/projects/security/certs/policy/), then I'm sure
> you'll have no problem getting CAcert.org's root added to the
> repositories of many browsers and operating systems. Until then, I
> believe you should remove the root from IceCat so users can remain
> secure and regain the feeling of assurance that by going to a site
> over SSL, they are indeed visiting the actual site and not a site
> using a fraudulent SSL certificate.
> 
> I hope you will take the above information with an open mind and do
> what is best for the safety and security of IceCat's userbase.
> 
> ~reed
> 
> ------------------------------------------------------------------------------
> Date: Mon, 06 Oct 2008 13:20:17 +0200
> From: Giuseppe Scrivano <address@hidden>
> To: Reed Loden <address@hidden>
> Cc: address@hidden
> Subject: Re: CAcert.org's inclusion into IceCat
> 
> Hello Reed,
> 
> Thank you for pointing this problem out, but I think some points were a
> bit exagerated, how we can say the private key were to be leaked out?
> 
> Differently from other CAs their source code is GPL'ed and you can get
> it here: http://www.cacert.org/src-lic.php.
> >From my point of view, it gives users more freedom as you can look
> directly at its source code and how it works, do you know of any case
> that CAcert showed to don't be trustable?  Are audits really so
> important when the software they use is Free?
> 
> I agree with you that the first goal of a SSL certificate is to make
> sure the site you are visiting is really what you requested and safe
> browsing for IceCat users is a very important thing.
> On this ML we discussed the possibility to treat self-signed
> certificates differently than Firefox but now I disagree with this idea
> because I consider the SSL connection itself in second place to be sure
> the resource you got is exactly from whom you wanted.
> 
> Surely I am going to consider it with an open mind, I think to don't
> have prejudices of any sort :)
> 
> Regards,
> Giuseppe
> 
> ------------------------------------------------------------------------------
> Date: Mon, 6 Oct 2008 14:18:14 -0500
> From: Reed Loden <address@hidden>
> To: Giuseppe Scrivano <address@hidden>
> Cc: address@hidden
> Subject: Re: CAcert.org's inclusion into IceCat
> 
> On Mon, 06 Oct 2008 13:20:17 +0200
> Giuseppe Scrivano <address@hidden> wrote:
> 
> > Thank you for pointing this problem out, but I think some points were
> > a bit exagerated, how we can say the private key were to be leaked
> > out?
> 
> I don't think it's that much of a stretch to consider the implications
> if CAcert.org's private key were to get out. It's publicly known that
> CAcert.org has had times in its history where the security of its root
> cannot be verified. They are working to correct these problems by
> moving to a new secure datacenter to house the private key(s) and the
> CA root itself, but until they get to a point where they are 100% sure
> that their root is secure and their private key(s) haven't been
> compromised at any time, CAcert.org should not be added to the CA root
> repository.
> 
> Do note that I mentioned many other problems besides just the possible
> issues concerning CAcert.org's private key. Please re-read my mail and
> consider all the different issues at hand here.
> 
> > Differently from other CAs their source code is GPL'ed and you can get
> > it here: http://www.cacert.org/src-lic.php.
> > From my point of view, it gives users more freedom as you can look
> > directly at its source code and how it works, do you know of any case
> > that CAcert showed to don't be trustable?  Are audits really so
> > important when the software they use is Free?
> 
> Just because CAcert.org's source code is GPL'd doesn't mean it's any
> more secure. I could set up a CA myself, and if I don't protect both
> the hardware and the software (including the operating system) of the
> machine(s) that host my CA's private key, it does me no good that the
> CA-specific software is GPL'd. Having one package "secure" on a box
> doesn't mean the other thousands of packages used to create that box
> are secure, too. Free software != always secure.
> 
> > I agree with you that the first goal of a SSL certificate is to make
> > sure the site you are visiting is really what you requested and safe
> > browsing for IceCat users is a very important thing.
> > On this ML we discussed the possibility to treat self-signed
> > certificates differently than Firefox but now I disagree with this
> > idea because I consider the SSL connection itself in second place to
> > be sure the resource you got is exactly from whom you wanted.
> 
> I would hope you wouldn't ever make self-signed SSL certificates treated
> as trusted by default. I would consider that even worse than adding the
> CAcert.org root, as anybody can create self-signed SSL certificates, so
> your users would never know if a certificate is truly valid for the
> site they are visiting. Firefox 3 did a great service to the Internet,
> imho, by making SSL errors more difficult to get around, as sites need
> to use valid SSL certificates that are configured properly. Users
> shouldn't be trained to just ignore warnings and click-through anyway.
> 
> SSL certificates are more than just security (encryption). They also
> imply a level of identity (validity), which Firefox 3 has tried to make
> better understood by users so that the different levels of SSL
> certificates can be treated differently depending on their uses and so
> that security is put above anything else, including ease/accessibility.
> In today's world, security should be at the top of our priority list.
> 
> > Surely I am going to consider it with an open mind, I think to don't
> > have prejudices of any sort :)
> 
> I'm glad you're considering this with an open mind like I ask, but
> please make sure you consider all the problems CAcert.org currently
> has, not just a chosen few. I really do believe CAcert.org will get to
> the point in the future where it can be trusted and widely used, but
> now is not that time. CAcert.org still has a long way to go until it
> has proven its security and can be trusted as much as a normal CA.
> 
> ~reed