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 ).
On 02/08/2013 12:41 PM, Michael Scherer wrote:
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.
Embedding a certificate in a RPM is fine because we can handle revocation/key rollover through an RPM update—especially if it's not a configuration file. We might eventually get a better mechanism, but until that happens, it's not so bad.
(This assumes that we own the certificate in question. Obviously, it won't do to download the certificate from the Internet, bake it in, and hope that it won't change until it expires. That's just not going to work.)
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.
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.
Hello, On Fri, Feb 8, 2013 at 12:41 PM, Michael Scherer misc@zarb.org wrote:
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.
There's also the system administration impact - an application that ships its own CA bundle will not be affected by admin's changes to https://fedoraproject.org/wiki/Features/SharedSystemCertificates .
- ban all certificates if used to validate something.
I think this is too strict; there may be legitimate cases of service-specific CAs; there even are projects that use the X.509 certificate format for something completely unrelated to the global CA universe. Requiring an exception or an independent review may be fine.
- list all problematic packages on a wiki.
Well, not necessarily a wiki, but a list of all potentially problematic packages, and eventually an analysis of them, would make a potential policy decision much easier (and would make it more likely that the chosen policy will be the right one).
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.
Wouldn't this be handled by only checking the binary packages, and allowing private keys/certificates in SRPMs? Shipping test suites is usually not that valuable (... speaking as an owner of a package that does ship a test suite :) It will be dropped soon).
If people want to look at
affected packages, there is # yum whatprovides '*pem'
That's quite a few :( Don't forget about other formats - .der, .p12 at least; possibly also the native NSS and Java formats. Mirek
Le vendredi 08 février 2013 à 16:54 +0100, Miloslav Trmač a écrit :
Hello, On Fri, Feb 8, 2013 at 12:41 PM, Michael Scherer misc@zarb.org wrote:
- ban all certificates if used to validate something.
I think this is too strict; there may be legitimate cases of service-specific CAs; there even are projects that use the X.509 certificate format for something completely unrelated to the global CA universe. Requiring an exception or an independent review may be fine.
Of course, when i mean "ban all", I mean "unless exceptions". And finding those potential exceptions is also one reason to have this thread :)
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.
Wouldn't this be handled by only checking the binary packages, and allowing private keys/certificates in SRPMs? Shipping test suites is usually not that valuable (... speaking as an owner of a package that does ship a test suite :) It will be dropped soon).
Usually, the test end in %doc, so maybe that's something that can be used. Sometimes, that's also used as example ( see the various perl modules shipping a cert ). Even if I can imagine people using the example to setup a service and end with a non private key. Not sure if we whould prevent that or just let darwin do his job...
If people want to look at
affected packages, there is # yum whatprovides '*pem'
That's quite a few :( Don't forget about other formats - .der, .p12 at least; possibly also the native NSS and Java formats.
I will add .dev and .p12. For the native formats, I am not a certificate specialist, so I will have to look and see what can be done.
Michael Scherer wrote:
Le vendredi 08 février 2013 à 16:54 +0100, Miloslav Trmač a écrit :
That's quite a few :( Don't forget about other formats - .der, .p12 at least; possibly also the native NSS and Java formats.
I will add .dev and .p12. For the native formats, I am not a certificate specialist, so I will have to look and see what can be done.
It's .der, not .dev!
Kevin Kofler
On 2013-02-08, 17:42 GMT, Michael Scherer wrote:
Of course, when i mean "ban all", I mean "unless exceptions". And finding those potential exceptions is also one reason to have this thread :)
I will try to take a look at gajim ... https://bugzilla.redhat.com/909625
Matěj
On Fri, Feb 08, 2013 at 12:41:29PM +0100, Michael Scherer wrote:
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 ).
This worked for me: openssl cms -verify -noverify -in cacert.p7s
HTH,
Nalin
Le vendredi 08 février 2013 à 11:08 -0500, Nalin Dahyabhai a écrit :
On Fri, Feb 08, 2013 at 12:41:29PM +0100, Michael Scherer wrote:
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 ).
This worked for me: openssl cms -verify -noverify -in cacert.p7s
Sorry to not have been clearer, what i want is the clear text version of the certificate. IE, there is 79 certs in the file. Who do thy belong is diginotar in it, etc, etc.
( but this command is still useful to know, as it was non obvious at all )
On Fri, Feb 08, 2013 at 06:40:05PM +0100, Michael Scherer wrote:
Le vendredi 08 février 2013 à 11:08 -0500, Nalin Dahyabhai a écrit :
This worked for me: openssl cms -verify -noverify -in cacert.p7s
Sorry to not have been clearer, what i want is the clear text version of the certificate. IE, there is 79 certs in the file. Who do thy belong is diginotar in it, etc, etc.
( but this command is still useful to know, as it was non obvious at all)
Each of those can be piped, individually, through a command like "openssl x509 -noout -text" or "openssl x509 -noout -subject" to get something more human readable.
So, maybe something like this, though YMMV:
#!/bin/sh tmpfile=`mktemp` if test -z "$tmpfile" ; then echo Error creating temporary file. fi trap 'rm -f "$tmpfile"' EXIT incert=false openssl cms -verify -noverify -in cacert.p7s | while read line ; do case "$line" in *-BEGIN*) echo "$line" > "$tmpfile" incert=true ;; *-END*) if $incert ; then echo "$line" >> "$tmpfile" openssl x509 -noout -text -in "$tmpfile" cat "$tmpfile" incert=false fi ;; *) if $incert ; then echo "$line" >> "$tmpfile" fi ;; esac done
Cheers,
Nalin