Hi, a few days ago, the topic of package shipping their own ssl CA bundle was discussed on irc with kiilerix, and the discussion prompted me to add some code to rpmlint to warn people about it. In short, shipping a private key, or a .pem is highly suspicious.
For a private key to be used as default configuration, the reason is obvious, ie it is no longer private if you can find several copy everywhere, and provides a false sense of security. For a certificate, that's slightly more subtle. A certificate alone in a package cannot do much. If there is no private key, then it cannot be used out of the box, except for client side validation ( afaik ). So all .pam certificates we can find would be used to validate another ssl certificates. That's where it start to be funny and security related, because the whole certificate authority idea requires update to be kept secure ( for exemple, when a CA was compromised, like DigiNotar, Trustwave ). And that's something we may not really watch. So this bring the question of : should we do something about it ? There is more than 1 approach : - ban all certificates if used to validate something. That mean patching and could be not practical. We try to not deviate from upstream too much, so that's a while wide scale project. That also mean some code audit, and while it is not a hard tasks, this still requires to read code in various languages. And Fedora may not be the right place for that. - list all problematic packages on a wiki. This way, if a certificate is to be removed, someone can check and open the bug. I imagine that the command to check the certificate should be documented on the wiki, as well as the last audit time. - do nothing. Security is sometime about balance between convenience and the risk. Certificate once revoked by mozilla/google/apple/etc are likely to be unused, so we can guess as a side effect that no one will use the compromised certificate anymore. I would propose to have prop 2 for the short term, and start thinking about prop 1. Prop 1 would need a rpmlint check ( done, but to be completed with other extensions ), and a FPC/Fesco approval. Then once approved as a general idea, decide on the detail, ie what to do, listing ( where ), fixing ( how ), etc, etc. We cannot automate that test, since private key and certificates are often used in tests suite. And as long as this is just used for testing purpose, the certificate should be ok. If people want to look at affected packages, there is # yum whatprovides '*pem' You can see gajim, some python/ruby modules, etc. Another good way is: # yum whatprovides '*cacert* But one side issue is that upstreams can be quite creative in the way they store and name the CA bundle. What triggered to write this mail is review 902503, where I was not able to find a way to inspect the cacert.p7s. I am not able to decipher openssl man pages to do anything with that file ( as a side note, if someone can tell me how to list certificate there, I would love to know ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
