On Mon, Aug 04, 2014 at 10:10:01AM +0000, Uri Simchoni wrote: > We have a conary-based system with an online update server. I don't > understand the trust model of updating a conary-based system from a > repository server. I can see that username/password or entitlement strings > can be used for client authentication and authorization, but I can't figure > out how the server proves its identity and/or how the client determines that > the downloaded content is genuine. It seems like in our setup, conary does > not verify the server certificate. > > Can anyone elaborate on that?
Sure. Rather than trusting a connection certificate, Conary is designed to trust the signatures on the packages themselves. The server itself doesn't prove its identity, as the server identity is intentionally transient. Instead, the PGP signatures on the packages themselves prove their content is genuine. This protects the client from malicious content even if connected to a malicious server. In order to enforce that, of course, there needs to be a PGP web of trust. Conary is set up to honor delegated trust in PGP signatures. So back when rPath existed, we had a root key (kept in a bank vault) that had ultimate trust. Then several responsible security officers carried (encrypted) keys signed by the root key and each delegated with 1/3 the necessary trust for a package. Those keys were the "designated signing keys" that were used to sign ultimate keys that were either assigned to individual developers to sign their source commits or to release engineers to sign the binary packages that might be installed on a system. The source-signing keys had a longer lifetime; the binary-signing keys had a short (3-month) lifetime, so we regularly had to assemble at least three of the security officers to use a dedicated off-network computer to create new binary signing keys for release engineering use. Then at least the rPath customers who cared got documentation on how to duplicate this process to sign their own commits. I know that there was at least one such customer for whom this chain of trust was imperative. Yes, as you imply, this does leave the potential for a MITM attack to compromise the client entitlement information. This was due to a long-standing lack of certificate enforcement in Python's SSL support. Fixing that was never highest priority for any rPath customers, though a few were mildly concerned. To the best of my knowledge, all of them who raised the issue were satisfied by the client PGP signature checking and their own license management and were not concerned by the slight risk of entitlement exposure. They seemed to have the perspective that software access entitlements are the kind of information that tends to leak anyway and those who cared implemented license management on top of entitlements. rPath did make it very clear in customer engagements that Conary entitlement management should not be used as an alternative for or share information with license management. Note that certificate enforcement would NOT protect the client from malicious content, because a single repository can have content with multiple "hostnames" in labels; the only real connection between hostnames and the "hostname" in the label is that in the unconfigured case, there is default configuration that uses the hostname to look up the repository to talk to. In most real use, it's just namespacing and clients are configured with proxyMap/repositoryMap. PGP key signatures on content are still required for content trust on the client side. Also, there's a wide open question of whether it makes more sense to do standard certificate enforcement or to enforce against an alternative CA specifically for Conary to handle the whole question of how hostnames in labels aren't actually hostnames... There are arguments both ways. I saw recent discussion of recent changes in state of SSL checking in Python: http://lwn.net/Articles/582065/ Hope that helps... _______________________________________________ Foresight-devel mailing list [email protected] https://lists.foresightlinux.org/mailman/listinfo/foresight-devel
