On Tue, 11 Oct 2016 14:31:55 -0400 Colin Walters <walters@xxxxxxxxxx> wrote: > On Mon, Oct 10, 2016, at 01:58 PM, Kevin Fenzi wrote: > > > > But does that not mean anyone going to the same place with a > > browser or command line downloading specific packages will get a > > "sorry, this cert is not trusted" ? Thats not such a big deal for > > ostree's, but for rpms, people do this all the time. > > Yes, there are two things someone could do then: > > 1) Go to any of the many non-ca-pinned URLs > I wasn't proposing switching any of the existing URLs, but adding > a new one, and we should ensure that the exact same view is > available with a regular ca-certificates signed cert > 2) Use curl --cafile or equivalent (or hack it with curl -k etc.) 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. ;) 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 If we ever switched from using Digicert for our certs we would need to change this, but otherwise it should protect from the Rogue CA threat (unless it was Digicert I guess). Also in the same file chom*/firefox set a list of sites to assume ssl, which would also be nice to hard code. kevin
Attachment:
pgpb5SXeJE50c.pgp
Description: OpenPGP digital signature
_______________________________________________ infrastructure mailing list -- infrastructure@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to infrastructure-leave@xxxxxxxxxxxxxxxxxxxxxxx
