savannah-hackers-public
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Karl Berry
Subject: [Savannah-hackers-public] CAcert, IceCat, and savannah
Date: Tue, 7 Oct 2008 18:40:57 -0500

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]