-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/08/2014 12:54 PM, Kai Engert wrote: > On Mi, 2014-01-08 at 12:32 -0500, Stephen Gallagher wrote: >> but what about package-specific CAs? For example, I have a >> pattern I was thinking about adding to the tog-pegasus that >> causes it to do the following: >> >> 1. Create an x509v3 certificate and key with the CA extension 2. >> Create a new service certificate for tog-pegasus locally 3. Sign >> it with the CA certificate. 4. Store the public CA certificate in >> the system's trust store. 5. Destroy the private key so that it >> cannot be used to sign other certificates. >> >> (The effect here being that a user on the local system can >> connect to an SSL socket on localhost without being challenged or >> having to ignore the verification) > > You are listing yet another scenario that I hadn't considered in > my previous message. > > As I understand it, in your scenario, you intend to dynamically > create a new CA at installation time. That CA wouldn't be > controlled by someone else, because the packager wouldn't have > access to the key that gets generated at install time. > > You're argueing it shouldn't be a problem to make that locally > generated CA trusted for all applications on the system, as nobody > else controls it. > > One could think of tricks to abuse that ability. > > For example, someone could make a package that implements a dynamic > MITM capability, by installing a local proxy that uses the locally > trusted CA, which can dynamically generate appropriate server > certificates for any site a user wants to visit, and by installing > a (localhost) proxy configuration into browser's network > configuration, thereby enabling the package to incercept all > outgoing connection TLS connections without getting noticed. > > True, when granting permission to install a package on a system, > you're granting that package full control over your computer > anyway. However, maybe such a MITM functionality might be difficult > to detect, and allowing global CA installation would make such > tricks possible. > > Of course, I'm constructing a hypothetical worst case scenario for > brainstorming purposes. I don't know if it's realistic that a > clever MITM tool, which only activates itself based on certain > condition, that hides inside a game package, would be noticed > during package review. > > In order to find a compromise between the extreme positions "find > a solution" and "be careful", maybe it should be a requirement > that locally generated CA certificates must contain a domain name > constraint extension, that limits for which sites it is valid. I don't really see this being more likely than an existing application just bundling a wrapper script for certificate generation and 'update-ca-extract' and quietly running that as part of %post. Just as easy to miss and equally effective (with much less trouble). I don't think that we can really write policy that eliminates the risk of a determined abuse of the available technology. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlLNmzgACgkQeiVVYja6o6MgeQCeKjtocZ//P0ATt17fM/3OMq4R qZwAn3n9qUcOboZcwwUSYlgxtopv2KEA =+yxY -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
