Not sure how we should treat this. Filing a bug for the security team therefore. The below information should be treated ~semi-confidential since it comes from the nonpublic kde-packagers mailing list. From: Tom Albers <toma@kde.org> To: security@kde.org CC: "kde-packager" <kde-packager@kde.org>, bradh@frogmouth.net Date: Today 22:08:10 Hi, KDE ships with a set of SSL-certs. A CA has been compromised, so I guess we need to patch out the certs. Sources for more info: - http://hg.mozilla.org/mozilla-central/rev/f6215eef2276#l1.57 - https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion - http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html Since this is probably done by the Iranian government which also controls all the internet traffic, it's difficult to trust revoke lists, but I don't know the ins and outs, so I rather leave the right actions to take to the security experts at KDE and the distro's. Just wants to give you a heads up about this issue. Best, -- Tom Albers KDE Sysadmin _______________________________________________ Kde-packager mailing list Kde-packager@kde.org https://mail.kde.org/mailman/listinfo/kde-packager Reproducible: Always
We in gentoo use system CA-certs instead of those internal ones... (ca-certificates) so iit is up to them to be fixed
(In reply to comment #1) > We in gentoo use system CA-certs instead of those internal ones... > (ca-certificates) so iit is up to them to be fixed @base-system, thoughts?
1. Does KDE properly use the ca-certificates packaged data, or does it bundle it's own set of CAs that we use, like Firefox? 2. Debian maintains the ca-certificates package, when they update it, we can too.
@robin: As I already said in comment 2, we use system pkg (the debian one) :) Taken from kdelibs ebuild: # use system certificates rm -f "${ED}/${KDEDIR}"/share/apps/kssl/ca-bundle.crt || die dosym /etc/ssl/certs/ca-certificates.crt \ "${KDEDIR}"/share/apps/kssl/ca-bundle.crt || die
Ok, so we're blocking on Debian updating ca-certificates. There was an NMU to ca-certificates last week, but it was only for translation fixes, nothing of actual note. Alternatively, we drop that cert in an ebuild revision.
unless i missed something, there is no cert for us to delete. the report upstream claims that no private keys were violated, which means only the random 9 certs were sent out. those get trusted not because ca-certificates ships them, but because they're signed by a cert that is shipped by ca-certificates. i dont believe ca-certificates has a way of black listing certs, which means there is nothing to be done in the ca-certificates package.
(In reply to comment #6) > > i dont believe ca-certificates has a way of black listing certs, which means > there is nothing to be done in the ca-certificates package. The other packages do appear to be blacklisting the particular bad certs, and adding functionality to do that at the same time. If ca-certificates follows suit in their next release, great. If not, well, I guess we'll drive off that bridge when we come to it...
i dont see how ca-certificates could add functionality. it isnt a library, it's simply a set of CA certs (like the name implies), none of which have been comprised (afawk). unless i'm mistaken, it doesnt include any sort of blacklists, nor is it supposed to. there is already an openssl-blacklist package.
vapier: The actions taken by others have basically been to remove some subset of the following CA roots: /usr/share/ca-certificates/mozilla/COMODO_Certification_Authority.crt /usr/share/ca-certificates/mozilla/COMODO_ECC_Certification_Authority.crt /usr/share/ca-certificates/mozilla/Comodo_AAA_Services_root.crt /usr/share/ca-certificates/mozilla/Comodo_Secure_Services_root.crt /usr/share/ca-certificates/mozilla/Comodo_Trusted_Services_root.crt
OK, but my points still stand ... those certs havent been compromised, and the ones that are invalid we dont ship, nor can we blacklist. i dont have a problem with punting Comodo considering their sordid and unresolved history (Bug 252347).
I would consider them to be effectively compromised since they could have had anything issued against them (esp. w/ today's discovery that two more Comodo resellers were exploited in the same manner to the first one). They aren't directly compromised, but since there could be any manner of certs from them already, they cannot be trusted. Yes, Comodo says they are manually reviewing all new requests, but what about all past certificates.
Hi, folks. What do you guys think makes sense here?
(In reply to comment #12) > Hi, folks. What do you guys think makes sense here? jmbsvicetto weighed in via IRC with a +1 to removing Comodo's certs, and suggested we inform users and provide them a (not necessarily easy) way to recover the certs if they are somehow required in their environment.
Bug 252347 is for tracking cert removal. there's nothing we can do wrt "blocking" in ca-certificates, thus there's nothing to do in this bug.
