|
|
Log in / Subscribe / Register

Debian and CAcert

By Jake Edge
March 18, 2014

CAcert is an SSL/TLS certificate authority (CA) that seeks to be community driven and to provide certificates for free (gratis), which stands in sharp contrast to the other existing CAs. But, in order for CAcert-signed certificates to be accepted by web browsers and other TLS-using applications, the CAcert root certificate must be included in the "trusted certificate store" that operating systems use to determine which CAs to trust. For the most part, CAcert has found it difficult to get included in the distribution-supplied trusted root stores; the discussion in a recently closed Debian bug highlights the problem.

Adding and subtracting CAcert

Debian has been distributing the CAcert root since 2005, when it was added to the ca-certificates package. That has ended with the removal of the certificates from the package by maintainer Michael Shuler in mid-March. That was in response to a bug filed in July 2013 asking for the removal of the CAcert root certificates for a variety of reasons, but mostly because the organization has not passed an audit of its practices. As one might guess, there are a number of different viewpoints regarding the validity and trustworthiness of CAcert-signed certificates; Debian community members were not shy about expressing them.

At the time CAcert was added, the inclusion of certificate roots was done on an ad hoc basis where popularity and "advocating votes from project members" played a role, according to Thijs Kinkhorst. That has changed to follow whatever Mozilla is doing with respect to which root certificates to include. CAcert itself withdrew its Mozilla inclusion request back in 2007, awaiting the results of CAcert's long-stalled internal audit.

Under most criteria, CAcert fails to provide enough assurance that its processes are secure enough to merit inclusion. In addition, the code it uses to manage certificates (which is open source) has some serious problems, as reported by Ansgar Burchardt. But CAcert is different than other CAs in fundamental ways that make it attractive to include its root certificates. As Kinkhorst put it: "CAcert is a bit of a special case because it's the only real community CA, and in that sense very different from the other CA's, and in that sense also close at heart to the way Debian operates." But even he was unsatisfied with the security of CAcert.

As Geoffrey Thomas pointed out, other CAs offer gratis certificates (GlobalSign for open source projects, StartCom for anyone), which moots the argument that CAcert is the only gratis provider, to some extent anyway. But, Alessandro Vesely was not convinced:

It seems to me CAcert certificates are free, not free-of-charge. The difference is between "free beer" and "free speech", as they say. I see that other providers offer free-of-charge certificates, and I consider those marketing strategies ultimately aimed at improving their sales.

Vesely is referring to the organization of CAcert and that it releases its code under the GPL, when he refers to it as "free as in free speech". CAcert certainly has a different philosophy than most other CAs, which is reflected in the goodwill that many in the free software world are willing to grant the organization.

Given that few other distributions (or any major browser vendors) include the CAcert root certificates, Debian's decision to do so doesn't really help, as several pointed out in the bug. If developers get CAcert certificates for their sites and test them from Debian only, they will get a false sense of what their users will see (i.e. the developers won't see the invalid certificate warnings that will pop up for users). The fact that Debian ships CAcert roots can be seen as something of an endorsement of CAcert, which might be intended, but also of its security practices, which probably isn't. But, as Vesely and others pointed out, the other CAs don't have spotless security records; furthermore we can't even see their code to find the kinds of problems Burchardt reported.

Reaction to CAcert removal

Shuler's announcement that the CAcert roots had been removed was met with a number of objections. Christoph Anton Mitterer complained that there was something of a double standard being applied since there are other "doubtful CAs" included in the ca-certificates package. In fact, that package is essentially just the Mozilla-distributed root store with one addition: the Software in the Public Interest (SPI) root certificate—because SPI runs some of the Debian infrastructure.

Axel Beckert suggested adding the CAcert roots back into the package, but disabling them by default. It had come up earlier in the discussion too. The ca-certificates package is a secure way for Debian users who do want those root certificates to get them. Removing them requires those users to find another path.

But Thomas R. Koll was quite supportive of the removal. He was fairly dismissive of arguments against removal:

Please do not reason against the removal, instead you have to prove (every year in my eyes) that CACert is trustworthy. Inverting the burden of proof, as it has [happened] far [too] often in these CACert discussions, is unacceptable when talking about security.

Daniel Kahn Gillmor doesn't see the issue as so clear-cut. While there are criteria that Mozilla uses to exclude some CAs, they aren't necessarily strictly applied to all:

we don't even need audits to know that groups like verisign and rapidssl have failed to avoid mis-issuing certs, and yet we keep them in the ca-certificates package because of the perverse incentives created by the CA ecosystem. some of these CAs are simply "too big to fail" right now; CACert is not, so they're getting called out for their lack of security, whereas we simply can't afford to drop the other CAs because users would complain about not being able to reach their favorite web sites :(

This tension results in further concentration of business among the "too big to fail" CAs (since they're the only ones who can issue acceptable certs), which ironically results in them being even less accountable to relying parties in the future.

This is not a good long-term dynamic.

He is also skeptical of including the SPI root certificate because it runs some of the Debian infrastructure. In fact, Gillmor said, that's a good reason not to include it as its presence makes it harder to switch away from the Debian infrastructure in the event it gets compromised (or the user is being targeted by someone in charge of Debian infrastructure). "With SPI's root cert, stopping software updates or varying my choice of debian mirror does *not* defend me against malicious use of the CA, and an attack can be much more narrowly tailored and hard to detect."

There are plans to move from certificates signed by the SPI root to those from another CA, Gandi, but Mitterer, at least, is not fond of that plan. It just moves the problem from SPI to Gandi, he said. He suggested that Debian should run its own CA.

While there was a fair amount of support for shipping, but not enabling, the CAcert root certificates, that has not happened, at least yet. As most would agree, the CA system that we have is largely broken in multiple ways, so, to some at least, arbitrarily deciding that CAcert is "insecure" is a bit of a stretch. On the other hand, there is a Mozilla policy that, if followed, would allow the CAcert root into the Mozilla root store (and thus, likely, back into the Debian package), but CAcert has been unable to complete the process for financial or logistical reasons. For now, though, Debian users that want to include CAcert in their root store are on their own.

For the most part, other distributions have not picked up CAcert either. Ubuntu followed the Debian lead for a while and continued that by recently removing the CAcert roots. Perhaps the most significant distributions that include CAcert roots are Mandriva, Arch Linux, Gentoo, and OpenBSD. Some are either descendants of Debian or use the Debian package, so that may change in light of Debian's removal. The best way forward for CAcert would seem to be completing the audit and getting included by Mozilla, but even that doesn't solve the whole problem. One guesses that Microsoft, Google, and Apple might be harder nuts to crack.

Index entries for this article
SecurityCertificate Authorities (CAs)


to post comments

Debian and CAcert

Posted Mar 19, 2014 0:40 UTC (Wed) by cesarb (subscriber, #6266) [Link]

> The best way forward for CAcert would seem to be completing the audit and getting included by Mozilla, but even that doesn't solve the whole problem. One guesses that Microsoft, Google, and Apple might be harder nuts to crack.

Not necessarily. ICP-Brasil, another CA, has been stalled for a long time on Mozilla, but I have read that Microsoft already includes it (I don't have a Windows machine at the moment to check). So we have at least one instance of it being easier to get included by Microsoft than to get included by Mozilla.

Debian and CAcert

Posted Mar 19, 2014 5:14 UTC (Wed) by alonz (subscriber, #815) [Link]

I wonder – has anyone from CAcert responded to these events at all?
I, too, used to use CAcert certificates back in the distant past; but since 2008 I switched to StartSSL as it looked like CAcert's audit was stalled. Unfortunately it looks like the organization's abilities have only gone downhill since then…
:(

argument for DANE

Posted Mar 19, 2014 8:14 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (7 responses)

The argument that Debian should work as much like, say, Windows, in this respect as possible is hopeless. Windows delayed SNI support by many years, was that a reason why Debian software should disable SNI ?

IMO Debian should push hard for DANE, enabling it in software that currently has code but chooses not to enable by default, applying patches that are stuck in limbo, that sort of thing.

For the commercial heavy weights there is no incentive to move on DANE unless/ until we get another batch of popular press stories about the SSL CAs being crooked that make them look complicit. My assumption would be that new item #1 on the budget at Verisign after its last problems was not "internal audits" or "beefed up processes" but "Hire PR consultants to do damage control".

So the impetus has to come from Free Software.

argument for DANE

Posted Mar 19, 2014 14:50 UTC (Wed) by jhoblitt (subscriber, #77733) [Link] (6 responses)

Does anyone know why Mozilla has not enabled DANE? https://wiki.mozilla.org/Security/DNSSEC-TLS-details#Code

argument for DANE

Posted Mar 19, 2014 17:39 UTC (Wed) by yokem_55 (subscriber, #10498) [Link] (3 responses)

From what I understand DANE is still in the Draft RFC stage, so any implementation would still be going after a moving target. On top of that DANE requires a working DNSSEC validation chain to be present - either through the user's DNS servers or entirely in the client and neither are particularly prevalent in the real world.

Then, you run into the problem that DANE simply moves the roots of the trust chain away from CA's to registrars and TLD zone operators. I'm not sure that we would really make any gains.

argument for DANE

Posted Mar 19, 2014 18:10 UTC (Wed) by anselm (subscriber, #2796) [Link] (1 responses)

Then, you run into the problem that DANE simply moves the roots of the trust chain away from CA's to registrars and TLD zone operators. I'm not sure that we would really make any gains.

The main benefit would be that today any CA whatsoever gets to sign certificates for any domain name whatsoever. Under DANE, though, the trust chain goes from only your TLD zone operator to your zone. There is no way for the operator of the .xyz zone (or somebody with influence on that operator) to interfere with your certificates unless your domain is within the .xyz zone, too.

argument for DANE

Posted Mar 20, 2014 0:34 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

Exactly. Today you have the situation where .example can be as well run as any domain anywhere, and yet a company you've never heard of (or a state acting through that company), based in a country you've no plans to ever visit, issues a CA cert that says some unrelated third party "is" your whatever.example domain, and the average person's web browser trusts them silently.

Under DANE the responsibility for securing domains in .example falls to the .example operators, the very same people _getting paid_ by whatever.example. This is a much more satisfying arrangement. Most likely .com will continue to be run very poorly but other domains can choose to do better, which today is futile at least in respect of security.

And as a bonus you get the thing CAcert wanted most of all, which is that everybody can have working PKI at potentially zero cost. That can never happen (as CAcert's experience illustrates) under the current regime.

DANE TLSA RFC

Posted Mar 20, 2014 2:24 UTC (Thu) by draco (subscriber, #1792) [Link]

The RFC can be found here: https://tools.ietf.org/html/rfc6698

argument for DANE

Posted Mar 20, 2014 9:14 UTC (Thu) by gerv (guest, #3376) [Link] (1 responses)

A little searching of Bugzilla reveals:

https://bugzilla.mozilla.org/show_bug.cgi?id=672600

"I would say that this is something we're still interested in, but it has been put on hold due to other higher-priority projects. For more information, you can take a look at https://wiki.mozilla.org/Security/Roadmap (when the DNSSEC-TLS item goes from "Unprioritized" to P1 or P2, it probably means we're actively working on it)."

That Roadmap page shows all the other things Mozilla engineers want to do first.

Gerv

argument for DANE

Posted Mar 31, 2014 14:47 UTC (Mon) by Lennie (subscriber, #49641) [Link]

I've recently seen a talk by someone working on Chrome/Chromium on these kinds of security features.

Basically they seem to have given up on DNSSEC/DANE and gonna keep working on Certificate Transparency.

Debian and CAcert

Posted Mar 19, 2014 8:15 UTC (Wed) by jezuch (subscriber, #52988) [Link] (4 responses)

With respect to the SPI root cert, why not move it into a separate package and tell people interested to install it if they need to access some Debian infrastructure?

Debian and CAcert

Posted Mar 19, 2014 15:19 UTC (Wed) by raven667 (subscriber, #5198) [Link]

Or for that matter any of the certs, including CAcert. I suppose that breaking down the default CA Certificate store into individual packages is a bunch of administrative and packaging overhead on every install for not much benefit on a small number of installs, but maybe with some clever branding you could separate out the commonly validated CA certs from the less common ones into two or three packages only, make the common ones default and allow for easy install of less-common authorities if desired.

Debian and CAcert

Posted Mar 19, 2014 15:28 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

Doesn't the certificate bundle come as a single file? I guess you could have post-[un]install hooks to build one from a directory to remake the bundle.

Debian and CAcert

Posted Mar 19, 2014 21:22 UTC (Wed) by eehakkin (guest, #92008) [Link]

It is a single file but it does not come as a single file. The update-ca-certificates generates the bundle file (containing all certificates) and hash link (for individual certificates) based on certificate files in /usr/share/ca-certificates and /usr/local/share/ca-certificates and user preferences provided by debconf.

Debian and CAcert

Posted Mar 20, 2014 0:28 UTC (Thu) by marduk (guest, #3831) [Link]

The most recent version of Gentoo's ca-certificates package has a "cacert" USE flag thereby making it optional.


Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds