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.

"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.

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.

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