Shared System Certificates followup: Packaging Guidelines?
kaie at kuix.de
Wed Jan 8 17:54:07 UTC 2014
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
> (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
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
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
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.
More information about the devel