Package shipping their own CA and security

[Tomas Mraz]

On Fri, 2013-02-08 at 12:41 +0100, Michael Scherer wrote: 
> 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
> ).

The cacert.p7s is just S/MIME signed bundle of X.509 CA certificates in
the PEM format - you can manually separate them out of the file and I
suppose the bundle should be directly usable instead of
the /etc/pki/tls/certs/ca-bundle.crt. I did not inspect what individual
CA certificates it contains but I am almost 100% sure that this should
not be shipped and the package patched so the default system CA
certificate bundle is used instead.

Shipping extra CA bundle would make sense only in case it was for some
kind of special purpose application where the servers do not use the
regularly trusted CAs but some special ones. 

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb