Package shipping their own CA and security

[Haïkel Guémar]

Le 08/02/2013 12:41, Michael Scherer a écrit :
> 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 ?

Good concern, we should take care of that issue.
> 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.
At the very least, it should require an exception from fesco and be
documented in the spec file.

> - 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. 

+1

> - 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. 
everyone should agree that it's not even an option
>
> 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. 

Maybe we could add this item to the package review checklist (yes,
reviewers are already supposed to go through every files during the
review for licensing and library bundling issues at least)

> 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
> ).
>

best regards,
H.