[arch-general] [arch-dev-public] CAcert dropped from certificate bundle
Hi all, because I can't send this to the arch-dev-public mailing list I will send this here: In my opinion, only because Debian drops the support for something this doesn't mean that we should do the same. And if you look at the Bugreport you will notice that the Information on which Debian is basing their argumentation is old. For more current information you can see: (sorry I know it's on German) http://www.heise.de/netze/meldung/CAcert-reagiert-auf-Zertifikatsrauswurf-21... Or http://wiki.cacert.org/Roots/EscrowAndRecovery/NRE which isn't so detailed, but should be up to date. Greetings, Neal
Hi all,
Debian has decided to drop the root certificate of CAcert.org they used to ship with their ca-certificates package. As our pacakge is based on Debian's the latest ca-certficates package in [testing] also lack the CAcert certificate.
If we intent to keep it that way we should also remove the patch from our nss package: https://projects.archlinux.de/svntogit/packages.git/tree/trunk/add_spi+cacer...
The Debian bug report can be found at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434
I added the certs to our bundles in 2009. Unfortunately there is no visible progress regarding their inclusion in browsers from Mozilla, Google and Microsoft.
Realistically I cannot vouch for any of the CAs we ship. That's one reason why we push that responsibility upstream to e.g. the Debian project or Mozilla.
What do you think? Imho we should keep follow Debian here. Other solutions would be to patch it back in or ship a separate optional package; though that might be impossible for nss.
Greetings,
Pierre
-- Pierre Schmitz, https://pierre-schmitz.com <https://pierre-schmitz.com/>
On 02/04/14 05:44 AM, Neal Oakey wrote:
Hi all,
because I can't send this to the arch-dev-public mailing list I will send this here:
In my opinion, only because Debian drops the support for something this doesn't mean that we should do the same.
And if you look at the Bugreport you will notice that the Information on which Debian is basing their argumentation is old.
For more current information you can see: (sorry I know it's on German) http://www.heise.de/netze/meldung/CAcert-reagiert-auf-Zertifikatsrauswurf-21...
Or http://wiki.cacert.org/Roots/EscrowAndRecovery/NRE which isn't so detailed, but should be up to date.
Greetings, Neal
Mozilla and Debian have both explicitly rejected including CAcert as a certificate authority Mozilla requires an audit by an unbiased third party in order to show a reasonable proof of security. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs... If and when CAcert ever gets their act together and is able to pass an audit, Mozilla will likely include it. Until then, there are plenty of other certificate authorities with free certificates that are also included in every major browser / operating system. For example: https://www.startssl.com/?app=1 It certainly doesn't help that CAcert seems to be a pile of PHP written in a dialect with little hope of stopping SQL injection, as they're manually building statements and escaping.
According to Daniel Micay: # Until then, there are plenty of other certificate authorities with free # certificates that are also included in every major browser / operating # system. For example: # # https://www.startssl.com/?app=1 I initially became interested in CAcert not only because of its free cost, but more importantly because they employ a web of trust community of assurers for additional validation of certificates. I wasn't aware that StartSSL provided such a validation mechanism, but it appears that they do. I'll be taking a much closer look at this certificate authority. Thanks. ~Kyle http://kyle.tk/ -- "Kyle? ... She calls her cake, Kyle?" Out of This World, season 2 episode 21 - "The Amazing Evie"
Hi, well until now all of this wasn't a problem, so why has it now become one? And well if you have a look at startssl, well they may be offering free certs but only single domain and just use the plain "things". * It doesn't allow commercial usage * "only" valid for 1 year * located in Israel (don't know if this should be good or bad) There maybe still quite a few things that have to be worked on at CAcert but still I currently would say, that I rather trust CAcert signed certs than any other. I mean look at all this fuckup that these firms are doing: ... some have been removed already: * Revoking Trust in one ANSSI Certificate (*.google.com) * Revoking Trust in Two TurkTrust Certificates (*.google.com) * Revoking Trust in DigiCert Sdn. Bhd Intermediate Certificate Authority (week certs) * Fraudulent *.google.com Certificate ... => DigiNotar Removal Follow Up * Firefox Blocking Fraudulent Certificates ... => Comodo Certificate Issue -- Follow Up ... but I still see many problems: * Chromium still has (all|many) of the cert, which I listed above * still including many 1024 bit keys! (*1) * to many CAs have issued other RootCA (like for e.g.: Tekecom > DFN > every fucking university in Germany (*2)) * and how far we still can trust CAs from America, where the NSA seams to be fiddling around in the security of all important firms, I can't really say *1:
/usr/share/ca-certificates/mozilla/Digital_Signature_Trust_Co._Global_CA_1.crt: 1024 bit /usr/share/ca-certificates/mozilla/Digital_Signature_Trust_Co._Global_CA_3.crt: 1024 bit /usr/share/ca-certificates/mozilla/Equifax_Secure_CA.crt: 1024 bit /usr/share/ca-certificates/mozilla/Equifax_Secure_eBusiness_CA_1.crt: 1024 bit /usr/share/ca-certificates/mozilla/Equifax_Secure_Global_eBusiness_CA.crt: 1024 bit /usr/share/ca-certificates/mozilla/NetLock_Business_=Class_B=_Root.crt: 1024 bit /usr/share/ca-certificates/mozilla/NetLock_Express_=Class_C=_Root.crt: 1024 bit /usr/share/ca-certificates/mozilla/Thawte_Premium_Server_CA.crt: 1024 bit /usr/share/ca-certificates/mozilla/Thawte_Server_CA.crt: 1024 bit /usr/share/ca-certificates/mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt: 1024 bit /usr/share/ca-certificates/mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.crt: 1024 bit /usr/share/ca-certificates/mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.crt: 1024 bit /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_2.crt: 1024 bit /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt: 1024 bit /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.crt: 1024 bit
*2: if you ask me, this is just waiting for miss usage, as every university (or person which could get access to there CAs) in Germany could issue a cert for [your-bank.com] Greetings, Neal Am 02.04.2014 14:20, schrieb Daniel Micay:
Hi all,
because I can't send this to the arch-dev-public mailing list I will send this here:
In my opinion, only because Debian drops the support for something this doesn't mean that we should do the same.
And if you look at the Bugreport you will notice that the Information on which Debian is basing their argumentation is old.
For more current information you can see: (sorry I know it's on German) http://www.heise.de/netze/meldung/CAcert-reagiert-auf-Zertifikatsrauswurf-21...
Or http://wiki.cacert.org/Roots/EscrowAndRecovery/NRE which isn't so detailed, but should be up to date.
Greetings, Neal Mozilla and Debian have both explicitly rejected including CAcert as a certificate authority Mozilla requires an audit by an unbiased third
On 02/04/14 05:44 AM, Neal Oakey wrote: party in order to show a reasonable proof of security.
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs...
If and when CAcert ever gets their act together and is able to pass an audit, Mozilla will likely include it.
Until then, there are plenty of other certificate authorities with free certificates that are also included in every major browser / operating system. For example:
https://www.startssl.com/?app=1
It certainly doesn't help that CAcert seems to be a pile of PHP written in a dialect with little hope of stopping SQL injection, as they're manually building statements and escaping.
On 02/04/14 11:31 AM, Neal Oakey wrote:
Hi,
well until now all of this wasn't a problem, so why has it now become one?
It's becoming clearer that CAcert isn't going to be passing a third party audit any time soon. Our only view into it is the open-source code they've made available, and messy wiki documentation. The quality of the code is not exactly comforting - whoever wrote most of it didn't seem to be aware of prepared statements...
And well if you have a look at startssl, well they may be offering free certs but only single domain and just use the plain "things".
* It doesn't allow commercial usage * "only" valid for 1 year
A CAcert certificate isn't trusted in most major browsers or operating systems, regardless of whether Arch ships it. That's a bigger inconvenience and makes it quite useless for commercial usage. This isn't the only example of a free TLS certificate anyway.
* located in Israel (don't know if this should be good or bad)
CAcert is located in Australia. Both are US allies and cooperate with US spying, if your point has something to do with the NSA. It's not like Australia doesn't have an active spy agency.
There maybe still quite a few things that have to be worked on at CAcert but still I currently would say, that I rather trust CAcert signed certs than any other.
You're free to add it if you trust them. Debian and Mozilla don't trust them, and Pierre has made it clear that he's not in a position to vouch for them either.
I mean look at all this fuckup that these firms are doing:
... some have been removed already:
* Revoking Trust in one ANSSI Certificate (*.google.com) * Revoking Trust in Two TurkTrust Certificates (*.google.com) * Revoking Trust in DigiCert Sdn. Bhd Intermediate Certificate Authority (week certs) * Fraudulent *.google.com Certificate ... => DigiNotar Removal Follow Up * Firefox Blocking Fraudulent Certificates ... => Comodo Certificate Issue -- Follow Up
... but I still see many problems:
* Chromium still has (all|many) of the cert, which I listed above * still including many 1024 bit keys! (*1) * to many CAs have issued other RootCA (like for e.g.: Tekecom > DFN > every fucking university in Germany (*2)) * and how far we still can trust CAs from America, where the NSA seams to be fiddling around in the security of all important firms, I can't really say
The US government is far from the only country with spy agencies. The CA system won't protect you from national governments, but it does a pretty good job providing protection from other entities. A certificate authority like CAcert without even a minimum level of security or auditing in place is a liability when it comes to this. Chromium no longer relies on the CA system for Google domains at all, it simply pins the certificates instead. See http://www.certificate-transparency.org/ for an example of the work that's been done on to the CA system. It's a technical solution with Google's political capital behind it. A CA not implementing it will have EV (shiny green bar) revoked, and this happens to be a major source of revenue for them.
*1:
/usr/share/ca-certificates/mozilla/Digital_Signature_Trust_Co._Global_CA_1.crt: 1024 bit /usr/share/ca-certificates/mozilla/Digital_Signature_Trust_Co._Global_CA_3.crt: 1024 bit /usr/share/ca-certificates/mozilla/Equifax_Secure_CA.crt: 1024 bit /usr/share/ca-certificates/mozilla/Equifax_Secure_eBusiness_CA_1.crt: 1024 bit /usr/share/ca-certificates/mozilla/Equifax_Secure_Global_eBusiness_CA.crt: 1024 bit /usr/share/ca-certificates/mozilla/NetLock_Business_=Class_B=_Root.crt: 1024 bit /usr/share/ca-certificates/mozilla/NetLock_Express_=Class_C=_Root.crt: 1024 bit /usr/share/ca-certificates/mozilla/Thawte_Premium_Server_CA.crt: 1024 bit /usr/share/ca-certificates/mozilla/Thawte_Server_CA.crt: 1024 bit /usr/share/ca-certificates/mozilla/Verisign_Class_1_Public_Primary_Certification_Authority.crt: 1024 bit /usr/share/ca-certificates/mozilla/Verisign_Class_1_Public_Primary_Certification_Authority_-_G2.crt: 1024 bit /usr/share/ca-certificates/mozilla/Verisign_Class_2_Public_Primary_Certification_Authority_-_G2.crt: 1024 bit /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_2.crt: 1024 bit /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority.crt: 1024 bit /usr/share/ca-certificates/mozilla/Verisign_Class_3_Public_Primary_Certification_Authority_-_G2.crt: 1024 bit
*2: if you ask me, this is just waiting for miss usage, as every university (or person which could get access to there CAs) in Germany could issue a cert for [your-bank.com]
Trusting CAcert in addition to these certificate authorities will not improve the situation. At least these certificate authorities are competent enough to pass third party audits.
It's becoming clearer that CAcert isn't going to be passing a third party audit any time soon. Our only view into it is the open-source code they've made available, and messy wiki documentation. The quality of the code is not exactly comforting - whoever wrote most of it didn't seem to be aware of prepared statements...
Unfortunately, it's true. But note that you will *never* know if these "profesionally" "audited" SSL issuers are aware of prepared statements or not. I don't want to name the company that I used to use which has an always-failing admin panel where you never know what the button is going to do every time you click it. No docs can help it. I would tend to trust CAcert more than anyone else if only their code was clean. Because it's not I consider them as risky as "professional" SSL issuers where you never know what's behind the scenes. Internets really need commerce-, government- and regulation-free SSL issuers like CAcert. Hope they HTFU and get their code written well some day. -- Kind regards, Damian Nowak StratusHost www.AtlasHost.eu
On 04/02/2014 04:44 AM, Neal Oakey wrote:
What do you think? Imho we should keep follow Debian here. Other
solutions would be to patch it back in or ship a separate optional package; though that might be impossible for nss.
Greetings,
Pierre
I usually agree with Pierre, but in this case "Why would we just want to follow Deb?" Why not continue to provide CAcert with the info in this thread provided as a proviso. No authority is perfect and dropping CAcert seems like a knee-jerk response that accomplishes little for Arch or the users. What would replace that dependency for curl and qt4, or would the functionality just be lost? -- David C. Rankin, J.D.,P.E.
On 02/04/14 06:10 PM, David C. Rankin wrote:
On 04/02/2014 04:44 AM, Neal Oakey wrote:
What do you think? Imho we should keep follow Debian here. Other
solutions would be to patch it back in or ship a separate optional package; though that might be impossible for nss.
Greetings,
Pierre
I usually agree with Pierre, but in this case "Why would we just want to follow Deb?" Why not continue to provide CAcert with the info in this thread provided as a proviso. No authority is perfect and dropping CAcert seems like a knee-jerk response that accomplishes little for Arch or the users.
If CAcert is hacked due to sloppy coding, then Arch users would all be vulnerable to man-in-the-middle attacks using certificates signed by the stolen private key. The certificate authority system is far from perfect, but the ones Mozilla includes need to perform regular audits, etc. CAcert doesn't meet their standards.
What would replace that dependency for curl and qt4, or would the functionality just be lost?
ca-certificates provides the trusted certificate authorities, and it is now simply shipping the upstream Mozilla certificate authorities. CAcert was just one of the certificate authorities, and *not* one of the ones trusted by Mozilla. Debian/Mozilla are the upstream here, and neither wants to include CAcert.
participants (5)
-
Daniel Micay
-
David C. Rankin
-
Kyle
-
Neal Oakey
-
Nowaker