2

For HTTP Strict Transport Security (HSTS), there is a preload list, that site owners can submit their site to a list of domain names that the browser vendors ship their browsers with.

Are there any mechanisms similar to HSTS Preloading, that the site owners can "announce" the signature(s) of the public keys they will be using, so the browser knows what public keys to accept before its very first visit to that site?

I understand shipping a giant file with the public keys isn't practical, but I would be grateful if you could point me if there are any final or draft features that the site owners can announce them securely, and without making it possible for the rogue to trick clients to accept a public key that is not the actual key?

AKS
  • 714
  • 5
  • 14
  • Are you looking for something like DANE which can publish the keys through DNSSEC? – kasperd Nov 25 '16 at 00:27
  • My guess is that *widespread* HPKP preload is extremely awful, not only performance-wise: One of my sites changes its HPKP pins every few weaks (letsencrypt certs with new keys every month and no root/intermediate backup), so such a scenario would defy "hardcoded" lists with presumably longer lifetime – Hagen von Eitzen Nov 06 '17 at 21:00
  • Because we pin the public key (digest of it), as long as the private is the same, the pinning will work. It's something I have implemented with LetsEncrypt (not official client). I do not generate a new key pair, on certificate renewal. – AKS Nov 07 '17 at 01:35

1 Answers1

2

Yes, the major browsers use HPKP preload lists but there is currently no mechanism to submit your own pins (as opposed to the HSTS list).

The big vendors currently restrict the preloaded public key pins to their own properties and some high profile sites (Google, Facebook, Twitter, etc.). The RFC on the Public Key Pinning extension also explicitly mentions that preload lists may be used:

2.7.  Interactions with Preloaded Pin Lists

   UAs MAY choose to implement additional sources of pinning
   information, such as through built-in lists of pinning information.
   Such UAs should allow users to override such additional sources,
   including disabling them from consideration.

   The effective policy for a Known Pinned Host that has both built-in
   Pins and Pins from previously observed PKP header response fields is
   implementation-defined.

For example, Mozilla Firefox is shipped with an HPKP preload list in PreloadedHPKPins.json. They describe their policy for including built-in pins as follows:

We will:

  • Pin all of the sites that Chrome already does (Google, Twitter) by importing chromium's pinset.
  • Pin our own sites after auditing them and cleaning them up.
  • Pin other popular sites like Facebook that are in good shape already (with their cooperation, of course)

Presumably, vendors are not too keen to let everyone submit their pins because that would mean a lot of extra maintenance due to constant change and removal requests.

Community
  • 1
Arminius
  • 44,242
  • 14
  • 143
  • 138