info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
intent to unship: HPKP (dynamic key pinning)
223 views
Skip to first unread message
Dana Keeler
Nov 17, 2019, 9:16:56 PM11/17/19
to dev-pl...@lists.mozilla.org
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
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
alex....@gmail.com
Nov 18, 2019, 6:08:08 PM11/18/19
to
Hi Dana,
One thing I don't see mentioned here is certificate transparency, which, while not a 1:1 replacement, nevertheless strongly contributes to the same goal of control over issuance.
Is there a plan to implement SCT verification in Firefox, similar to what Chrome and Apple have shipped? In either event, it sounds like the plan to remove HPKP is not contingent on the answer on CT, correct?
Alex
One thing I don't see mentioned here is certificate transparency, which, while not a 1:1 replacement, nevertheless strongly contributes to the same goal of control over issuance.
Is there a plan to implement SCT verification in Firefox, similar to what Chrome and Apple have shipped? In either event, it sounds like the plan to remove HPKP is not contingent on the answer on CT, correct?
Alex
dke...@mozilla.com
Nov 19, 2019, 3:35:46 PM11/19/19
to
Enabling certificate transparency in Firefox mostly depends on policy details that haven't been worked out yet. But yes, removing HPKP does not depend on CT.
Tom Ritter
Nov 20, 2019, 3:26:51 PM11/20/19
to David Keeler, Mozilla
Will non-mozilla websites be eligible to be added into our preload list, or
is it restricted to our own properties?
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
is it restricted to our own properties?
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Dana Keeler
Nov 20, 2019, 3:26:53 PM11/20/19
to Mozilla
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.
> dev-pl...@lists.mozilla.org <mailto:dev-pl...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-platform
>
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.
> https://lists.mozilla.org/listinfo/dev-platform
>
0 new messages