On Wed, Oct 12, 2016, at 03:17 PM, Kevin Fenzi wrote: > Sure, but they won't. They will complain that we have an invalid cert > and we will need to explain to them whats going on. ;) I still think this would be mostly covered if the yum repo files and the ostree remote config had a comment like: # This URL is ca-pinned, see https://fedoraproject.org/wiki/CAPinning But: > Instead of shipping a fedora-ca that you verify against, why not do > what chrom*/firefox do and have a hardcoded list of hashes that must be > in the cert? > > https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning > > https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json The Chrome and Firefox implementations seem different - Firefox hashes the certs, but Chrome seems to have a CA whitelist, which is actually a lot easier to read. Anyways, there's a higher level question here - you're arguing for pinning to Digicert rather than a custom CA. That seems good enough, but I think we need a recovery mechanism in case Digicert explodes. So I'd propose pinning to a 3 set of CAs: - Digicert - Some other well-regarded CA vendor - A Fedora-infra custom CA (doesn't have to be deployed, just a backup plan) And as for a specific implementation mechanism, we'd have just those CAs in /etc/pki/tls/certs/fedora-infra.crt or so, and that file would be in the fedora-repos package. The argument for this again is that librepo and ostree already have all of the code for this, and so does curl etc. Doing the hashes of the certs like Firefox does is certainly possible, but it requires custom logic in the HTTP layer, and there's no standard configuration file formats for the data, etc. > Also in the same file chom*/firefox set a list of sites to assume ssl, > which would also be nice to hard code. Yeah, we could follow up with this adding Fedora sites to the browser lists. Chrome's version seems saner to me. _______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
