One of the main reasons we hesitated so long to remove HPKP was in part
because it provided an answer to the concern that static pins privilege
some sites and not others (which in general is not conducive to a
healthy, diverse web). Now that we're disabling HPKP, perhaps we need to
have a discussion about the role of the static pins list and what sorts
of domains we put on it.
For background, in addition to a number of our own services and domains,
we have successfully pinned Google, Facebook, Twitter, Dropbox, and Tor
services and domains. We could decide to say that only domains that are
critical to the operation of the product may be on the static list. In
that case, these other sites would be removed. We could go the other way
and define a process by which any site could apply to be added. In that
case, I would argue that candidate domains must be included in as many
user agents as possible that support static pins, to avoid creating
another compatibility risk unique to Firefox. That said, it has been two
and a half years since any non-Mozilla sites have requested to be
included, so perhaps this won't be a concern in practice.
Long story short, to answer your question: there are currently
non-Mozilla sites on the static list, and we're not necessarily opposed
to expanding it, but we would need to do so with care so as to avoid
compatibility issues.
On 11/18/19 8:03 AM, Tom Ritter wrote:
Will non-mozilla websites be eligible to be added into our preload list,
or is it restricted to our own properties?
On Sun, Nov 17, 2019, 8:17 PM Dana Keeler <mailto:dkee...@mozilla.com>> wrote:
The breadth of the web public key infrastructure (PKI) is both an asset
and a risk. Websites have a wide range of certificate authorities (CAs)
to choose from to obtain certificates for their domains. As a
consequence, attackers also have a wide range of potential targets to
try to exploit to get a mis-issued certificate. The HTTP Public Key
Pinning (HPKP) [0] header was intended to allow individual sites to
restrict the web PKI to a subset as it applies to their domains, thus
decreasing their exposure to compromised CAs.
Unfortunately, HPKP has seen little adoption, largely because it has
proved to be too dangerous to use. There are a number of scenarios that
can render websites inoperable, even if they themselves don't use the
header. Chrome removed support for it in version 72 in January of this
year [1]. According to our compatibility information, Opera, Android
webview, and Samsung Internet are the only other implementations that
support the header [2]. At this point, it represents too much of a risk
to continue to enable in Firefox.
A related mechanism, DNS Certification Authority Authorization (CAA)
[3], also allows websites to restrict which CAs can issue certificates
for their domains. This has seen much larger adoption and does not
suffer from the drawbacks of HPKP.
Earlier today, bug 1412438 [4] landed in Firefox Nightly [5] to disable
HPKP via a preference. New HPKP headers will not be processed, and
previously-cached HPKP information will not be consulted.
The static list of key pinning information that ships with Firefox is
still enabled, and these pins will still be enforced.
[0] https://tools.ietf.org/html/rfc7469
[1] https://www.chromestatus.com/feature/5903385005916160
[2] https://developer.mozilla.org/en-US/docs/Web/HTTP/Public_Key_Pinning
[3] https://tools.ietf.org/html/rfc6844
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1412438
[5] Coincidentally, version 72
___
dev-platform mailing list
dev-platform@lists.mozilla.org <mailto:dev-platform@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
