Closed Bug 1412438 Opened 7 years ago Closed 5 years ago

consider removal of HTTP Public Key Pinning (HPKP)

Categories

(Core :: Security: PSM, enhancement, P1)

Product:
Core
Component:
Security: PSM
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla72
Tracking Flags:
Tracking Status
firefox72 + fixed

People

(Reporter: dbaron, Assigned: keeler)

References

Details

(Keywords: dev-doc-complete, site-compat, Whiteboard: [psm-assigned])

Attachments

(1 file)

bug 1412438 - add preference to disable HPKP by default r?jcj
47 bytes, text/x-phabricator-request
Details | Review
https://groups.google.com/a/chromium.org/d/msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ announces that Chromium will be removing support for HTTP Public Key Pinning (HPKP). It seems like Gecko should consider that removal as well, given that based on that message, we'd be the only engine supporting it once Chrome removes it, and given the rationale for removal stated there. Chrome's removal would probably mean that Firefox users would be more likely to see TLS errors as a result of site's HPKP misconfiguration (for example, a stale configuration that no longer matches the current CA), since those misconfigurations would only lead to problems in Firefox. (However, given the low rate of usage cited in the message, this also doesn't seem like a huge risk.)
Some more discussion about HPKP, its risks and possible ways to fix: https://scotthelme.co.uk/the-death-knell-for-hpkp/ The risk, in short: Using HPKP, an attacker can a) insert a HPKP header onto an unencrypted page load using man in the middle attacks b) insert a HPKP header onto a website he temporarily hijacked in both cases, the attacker can lock out any users from that page because only he has the private key belonging to the public key pinned onto the domain name. This poses the threat of a domain ransomware (or HTTPS ransomware).
I'd consider it. Removing support for this would reduce attack surface in the browser as well. (In reply to Christian Stadelmann from comment #1) > a) insert a HPKP header onto an unencrypted page load using man in the > middle attacks Pretty sure this isn't true - we disregard HPKP headers if we encounter them on non-secure channels. But point b is still definitely a concern.
Priority: -- → P2
Whiteboard: [psm-backlog]
"a)" is absolutely untrue. This quite obvious attack is addressed in the spec. Like HSTS, HPKP headers have to be served securely over TLS. A second important requirement is that the security state set by the header must be VALID at the time it's set. You can't pin to a fake cert: at least one of the pins has to be valid for the current certificate.
Severity: normal → major
We should definetely look into this bug within the next months.
Please don't remove it! You don't have to everything, just because Chrome/ium does so. Especially you should give great care, before removing a security feature! I mean, we do not talk about a small CSS feature here, it actually is a security thing. Here are some arguments and counter-arguments against "We replace HPKP with CT/CAA": a) HPKP is easy to deploy and a very strong security measure – even for smaller sites. b) "RansomPKP" – Totally theoretical and nobody has seen this in practice until now, and we have had HPKP for some time, already. Also this is only an issue for the time the website is online and hacked. c) "Certificate transparency is better than HPKP and provides the same features." – This is actually not true. While it also allows to detect rogue certificates, it is… 1. only reactive (i.e. the incident has to happen and only afterwards you can notice it) – in contrast HPKP, which is is proactive, i.e. it prevents a potential attack *before* it actually happens. 2. only big sites profit from CT most, as many security researchers monitor these domains. Smaller companies/website admins actually have to manually monitor the CT logs to find out of a potential misuse – nobody else can actually know whether the CA issued a valid cert or a rogue one. With HPKP you set one header and you're done. So to recap: CT requires constant active involvement, while HPKP is something you deploy once, keep in mind (for key rotation or so), but otherwise just a one-shot. d) CAA is also a good technology, but yet again something different. E.g. it totally trusts the CA and that they support the feature. HPKP can be deployed with zero trust regarding CAs. e) HPKP is the only reliable way to protect against DNS forgery. A cert is technically bound to the server and verified via HTTPS handshake, while DNS results may be forged/faked/…. When an attacker can issue a wrong cert for some time/domain, at least, (as it is assumed in the case of HPKP and CT threat models) and they can fake the DNS, CT logs may show the correct domain (so don't raise questions), but HPKP prevents the attack completely. f) Also, Chrome/ium even removed **static pinning**. This one does technically not have the flaws (theoretical problems) outlined above. Chrome likely only removed it, because they don't want to get into antitrust market distortion issues for supporting only big companies. g) HPKP usage may not be widespread. That's true. Considering it is a goal of a security technology to be widespread (which I would not necessarily agree with, because even some "crypto geek" websites or others using a feature would be good) one may say HPKP is not worth it/does not help many websites. As also explained above, however, CT has the same problem: As long as website admins don't actively monitor the logs, it does not help their site's security. The problem here is: We have no stats at all, about how many web admins monitor CT logs, so we cannot prove that "CT does not really help the security of many websites."¹. Generally I think it is not fair to pit one security feature against any other, when they both increase the security. At least in this case, they have different threat models (though, admittedly, partially very similar), so removing one for supporting another is a bad deal. And if you really think HPKP should be improved, yeah, why not. It's totally possible: * https://blog.qualys.com/ssllabs/2017/09/19/fixing-hpkp-with-certificate-constraints * https://blog.qualys.com/ssllabs/2017/09/05/fixing-hpkp-with-pin-revocation * or, e.g., require to pin 1 at least CA cert in addition to the current requirements. This should prevent most RansomPKP attacks as they would just have to get a cert from that CA – and whichever CA the attackers choose, it should always be possible to get a cert. (and attackers choosing pricey CAs, e.g. Extended Validation, are on a risky track, as such CAs usually require identifications, they may get into bigger trouble than anything else) * or, e.g. only save the pin if the website is revisited after 1 day or so – this equally prevents RansomPKP, but still provides a great security improvement. Conclusion: * HPKP is risky and has always been for website admins to deploy when admins don't know, what they do. But it is a huge security feature and awesome for small self-hosted servers with low users, i.e. low risk. Or in the reverse: big banks, that know that they do may use it, or basically any competent security/web admin. * HPKP is a stronger security measure in the HTTPS world than any other, including CT. * RansomPKP can be mitigated with a small change in how browsers handle it. (as explained above) Just removing a security feature instead of at least _trying_ to improve it, is a bad move and does not actually help to increase the security. * Alternatively one may try to rework the HPKP spec or improve it in general… But there is no reason to just remove it. * The worst thing one could do is removing static pinning, which does not suffer from any issues HPKP has. I have no idea why Google did not try to improve the technology and just remove it. -> Don't remove a security feature, improve/fix it. We would not have gotten anywhere, if we just removed a security feature, because of some minor (theoretically) flaws in the past. Side notes: * I've argued about this topic before, when Chrome announced their decision: https://twitter.com/rugkme/status/924004441908531203, thread goes on here: https://twitter.com/Scott_Helme/status/924005184287764483 ¹ But it does help the whole PKI "ecosystem" (by detecting certs mis-issued for obvious reasons like wrong hash or so), of course, but that's not the point here.
CT mainly improves the detection of phishing sites: https://twitter.com/Scott_Helme/status/1008697493977272320 DNSSEC guarantees my authority and is the only way to effectively secure a mail server (to be compliant with Art. 32 GDPR). If I use HPKP to pin to Let's Encrypt, someone interfering my network could still request a cert via http challenge, or not? CAA lets me express a wish, now it can be extended with "validation-methods=dns-01": https://community.letsencrypt.org/t/acme-caa-validation-methods-support/63125 Only HPKP (trust on first use) and DANE (e.g. bug 1450674) are preemptive measures as it is required by law in some circumstances. HPKP could be interesting to secure users against a domain takeover.
DNSSEC is yet some other technique and mostly only useful for mail servers, yes, so let's keep it out of this discussion here. (same as DANE) Yes, CT is nice and e.g. helps to detect phishing sites. That's also what I said before, but this does not affect this issue. Here I only used this as a comparison. Also, this should not get into a support thread about HPKP, so I'll just answer your question here in short, better use other places for that later: > If I use HPKP to pin to Let's Encrypt, someone interfering my network could still request a cert via http challenge, or not? If you pin the CA, yes. However, the threat model HPKP protects against is against these CAs e.g. By pinning to LE only this one CA can be used to get a cert, so you effectively trust only this CA (and your backup key). It does not protect against a server breach. Even stronger protection can be done when you pin leaf certs, i.e. only your own key pairs. You have to be careful then, as you can lock yourself out, that's why you need to take care and use backup keys.
(In reply to rugk from comment #7) > DNSSEC is yet some other technique and mostly only useful for mail servers, yes, so let's keep it out of this discussion here. (same as DANE) I (a community member) just wrote my summary without relating to your comment and answered my hypothetical question with an upcoming solution. HPKP is mainly useful to protect existing users' LocalStorage/IndexedDB/Cookies against a domain owner change by pinning leaf certs. CT monitoring against misissuance and phishing is possible with Hardenize and Facebook. In all other cases (untrusted networks) and to protect first-time users I should use DNSSEC to secure CAA (enforce DNS challenge) to give a CA confidence about an issuance request and/or to empower browsers to validate the current domain owner's certificate by TLSA (preemptive measure). In theory one can use the WebCrypto API to protect user data with a different solution than HPKP. I could imagine a "skip HPKP warning" button that deletes all site data and tells the user that the domain owner may have changed or has lost control in some way.
Hi folks - glad you're interested in this. However, please have discussions in the appropriate mailing list (e.g. https://groups.google.com/forum/#!forum/mozilla.dev.security.policy or https://lists.mozilla.org/listinfo/dev-security ). Bugzilla isn't the best place for a discussion as we mainly use it to track implementation status rather than whether or not something should be implemented (or in this case, removed).
BTW, just another comment on the differentiation between HPKP (when pinning root CA) and CAA: * CAA is only a signal to CAs. So if one CA different to the one you allow to issue certs does not behave properly, they can just ignore it. * HPKP, however, is a technically enforcing security. If a different CA than pinned does not behave and issues a cert for your domain, then it is not accepted when your browser is presented with it.

It will be removed in Chrome 72: https://www.chromestatus.com/feature/5903385005916160
We're updating Chrome's compat data here: https://github.com/mdn/browser-compat-data/pull/3175

Adding ddn to track if/when Firefox removes this.

Keywords: dev-doc-needed

Hello! Chrome 72 is Stable now. :)

We're pulling our HPKP toolset from https://report-uri.com as we're no longer supporting adoption of HPKP.

We're also looking to pull support for HPKP reports to further simplify our app, but it seems Firefox still supports it.

Is there an ETA on when/if Firefox will drop support?

A prominent Twitter user who reports on data breaches is having a problem with HPKP in Firefox:

https://twitter.com/pogowasright/status/1192874027750178818?s=21

The site, databreaches.net, sets a PKP header. It's working for me in Firefox 70 right now, but I guess for some people there is Pin Validation failure.

For anyone interested: There is a workaround in Firefox. In about:config, there is a setting called security.cert_pinning.enforcement_level. The default is 1; if you set it to 0, Firefox will skip pin validation and bricked sites should work again.

(Although I think that means Firefox might not do pin validation for static PKP, as opposed to dynamic/HPKP, as well. And that would be bad; you want that protection. I really hope Mozilla will remove HPKP and keep static pins.)

Yes, that's what setting that pref to 0 means: the feature is 100% off including preloads. We don't currently have an option to turn off the header parsing. We should at least put a pref switch on it, even if we're not ready to rip it out. Somewhere around here:

https://searchfox.org/mozilla-central/rev/2a10f4812f3f7c7645d253a4fe52f26bf58e20e8/security/manager/ssl/nsSiteSecurityService.cpp#843-847

Flags: needinfo?(jjones)

Preffing off header parsing would still leave us honoring previously-parsed headers until they expire (max 60 or 90 days?). If we can't live with that, but still want to honor built-in pins, then we'd have to do more work in the enforcement code.

Or just turn it all off with the pref we already have. Does enforcing internal pins buy us very much?

[Tracking Requested - why for this release]:
This seems to be a footgun in practice, and not just theory, and when it breaks it's "I don't know why Firefox doesn't work on my site, use another browser".

tracking-firefox72: --- → ?

I do think enforcing static pins is valuable, yes. We have no plans to remove it from Chrome any time soon, for what it's worth.

I am going to defer the final decision on this to Dana, but my opinion is in favor of :

  1. adding a pref to disable HPKP
  2. announcing an intent-to-unship to set said pref to disable HPKP
Flags: needinfo?(jjones)

As Chrome has removed support for the HPKP (HTTP Public Key Pinning) header,
continuing to support it in Firefox is a compatibility risk. This patch adds
the preference "security.cert_pinning.hpkp.enabled" and sets it to false by
default. As such, the platform will no longer process the HPKP header nor
consult any cached HPKP information for certificate pins.
Preloaded (statically-compiled) pins are still enabled in Firefox by default.
This patch also disables dynamically setting pins via our remote security
settings infrastructure, as it uses the same backend and represents similar
compatibility risk.

Assignee: nobody → dkeeler
Priority: P2 → P1
Whiteboard: [psm-backlog] → [psm-assigned]

Please send an "Intent to unship" mail for this.

Yes, I'm intending (heh) to.

Pushed by dkeeler@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/d791bfa31f08 add preference to disable HPKP by default r=jcj
Keywords: site-compat

https://hg.mozilla.org/mozilla-central/rev/d791bfa31f08

Status: NEW → RESOLVED
Closed: 5 years ago
status-firefox72: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla72

Google is a well known voluntary partner of the NSA and their motivation for removing this feature was likely by request of the NSA because it interferes with the NSA's interception hardware that they secretly force companies to use.

Other actions that Chrome has taken like removing P-521 is also very suspicious since ECC is very vulnerable to quantum computers and P-521 will be broken years before RSA-2048. The most common reason presented was "It's not in Suite B" so if the NSA would of put 3DES in Suite B then we'd using 3DES now. Right now, with Google themselves having a quantum computer and the NSA having one for at least 10 years, P-521 isn't enough.

There has not been a single legitimate reason presented for removing this feature that was not already known before becoming an IETF standard.

I believe this should be reconsidered or a browser fork needs to take place.

See Also: → 1281469, 1450674

(In reply to Bob Nelson from comment #32)

Google is a well known voluntary partner of the NSA and their motivation for removing this feature was likely by request of the NSA because it interferes with the NSA's interception hardware that they secretly force companies to use.

Other actions that Chrome has taken like removing P-521 is also very suspicious since ECC is very vulnerable to quantum computers and P-521 will be broken years before RSA-2048. The most common reason presented was "It's not in Suite B" so if the NSA would of put 3DES in Suite B then we'd using 3DES now. Right now, with Google themselves having a quantum computer and the NSA having one for at least 10 years, P-521 isn't enough.

There has not been a single legitimate reason presented for removing this feature that was not already known before becoming an IETF standard.

I believe this should be reconsidered or a browser fork needs to take place.

There is waterfox that enables HPKP by default. But a fork is useless, since the major part of firefox users will have hpkp disabled by default and webmasters who don't trust CAs will discard this function anyway, since only a minority will benefit from it. I don't see any other function that can satisfy a webmaster who doesn't trust CAs. Unfortunately, those who possess most of the users have the power in this case, and there are no good powers.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: