Re: Shared System Certificates followup: Packaging Guidelines?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux