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.