Shared System Certificates followup: Packaging Guidelines?

Wed Jan 8 18:38:48 UTC 2014

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