Primary eng (and PM) emails
pal...@chromium.org, rsl...@chromium.org, est...@chromium.org, a...@chromium.org
Summary
Deprecate support for public key pinning (PKP) in Chrome, and then remove it entirely.
This will first remove support for HTTP-based PKP (“dynamic pins”), in which the user-agent learns of pin-sets for hosts by HTTP headers. We would like to do this in Chrome 67, which is estimated to be released to Stable on 29 May 2018.
Finally, remove support for built-in PKP (“static pins”) at a point in the future when Chrome requires Certificate Transparency for all publicly-trusted certificates (not just newly-issued publicly-trusted certificates). (We don’t yet know when this will be.)
Motivation
PKP offers a way to defend against certificate misissuance, by providing a Web-exposed mechanism (HPKP) for sites to limit the set of certificate authorities (CAs) that can issue for their domain. However, this exposes as part of the Open Web Platform considerations that are external to it: specifically, the choice and selection of CAs is a product-level security decision made by browsers or by OS vendors, and the choice and use of sub-CAs, cross-signing, and other aspects of the PKI hierarchy are made independently by CAs.
As a consequence, site operators face difficulties selecting a reliable set of keys to pin to, and adoption of PKP has remained low. When site operators’ expectations don’t match the reality of trust anchors on real world client machines, users suffer. Unexpected or spurious pinning errors can result in error fatigue rather than user safety.
Concretely:
It is hard to build a pin-set that is guaranteed to work, due to the variance in both user-agent trust stores and CA operations.
There is a risk of rendering a site unusable.
There is a risk of hostile pinning, should an attacker obtain a misissued certificate. While there are no confirmed or rumored cases of this having happened, the risk is present even for sites that don’t use PKP.
Interoperability And Compatibility Risk
There is no compatibility risk; no web site will stop working as a result of the removal of static or dynamic PKP.
Edge: Currently does not support key pinning.
Firefox: No official signals yet.
Safari: Currently does not support key pinning.
Opera: If Opera wishes to continue to support pinning, they will need to carry a patch that reverts our diff(s).
Alternative implementation suggestion for web developers
To defend against certificate misissuance, web developers should use the Expect-CT header, including its reporting function. Expect-CT is safer than HPKP due to the flexibility it gives site operators to recover from any configuration errors, and due to the built-in support offered by a number of CAs. Site operators can generally deploy Expect-CT on a domain without needing to take any additional steps when obtaining certificates for the domain. Even if the CT log ecosystem substantially changes during the validity period of the certificate, site operators can provide updated SCTs in the form of OCSP responses (if their CA supports it) or via a TLS extension (if they wish for greater control). The combination of these mitigations substantially reduces the risk of DoS (either accidental or hostile) via Expect-CT deployment. By combining Expect-CT with active monitoring for relevant domains, which a growing number of CAs and third-parties now provide, site operators can proactively detect misissuance in a way that HPKP does not achieve, while also reducing the risk of misconfiguration and avoiding the risk of hostile pinning.
Usage information from UseCounter
Scott Helme found in August 2016 that very few of the Alex Top 1 Million sites were using HPKP (375) or the Report-Only (RO) variant (76): https://scotthelme.co.uk/alexa-top-1-million-crawl-aug-2016/. My own scans (using slightly different/additional corpora) earlier in 2016 showed even lower numbers.
The UMA histogram Net.PublicKeyPinSuccess records a high number of successes, but it includes popular domains for which Chrome has static key pins: likely Google sites.
The UMA histogram Net.PublicKeyPinReportSendingFailure2, which is probably a much better indication of dynamic PKP adoption than Net.PublicKeyPinSuccess, shows extremely low numbers of success and failure, indicating that very few sites are using it, and/or that only very low-traffic sites are using it.
If necessary, we can add UMA histograms to find the ratio of HTTP responses with and without HPKP(-RO) headers.
OWP launch tracking bug
The Chromium tracking bug is crbug.com/779166.
Entry on the feature dashboard
I’m not sure if we need this. If we do, I’ll add one.
Requesting approval to remove too?
Yes.
To defend against certificate misissuance, web developers should use the Expect-CT header, including its reporting function.
"...reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities."
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOuvq212inCp0nTNrGGF1a2mWH3aVToQ5%3Dsr%2BDGyY6abufbpWg%40mail.gmail.com.
This will first remove support for HTTP-based PKP (“dynamic pins”), in which the user-agent learns of pin-sets for hosts by HTTP headers. We would like to do this in Chrome 67, which is estimated to be released to Stable on 29 May 2018.
Finally, remove support for built-in PKP (“static pins”) at a point in the future when Chrome requires Certificate Transparency for all publicly-trusted certificates (not just newly-issued publicly-trusted certificates). (We don’t yet know when this will be.)
Alternative implementation suggestion for web developers
To defend against certificate misissuance, web developers should use the Expect-CT header, including its reporting function. Expect-CT is safer than HPKP due to the flexibility it gives site operators to recover from any configuration errors, and due to the built-in support offered by a number of CAs. Site operators can generally deploy Expect-CT on a domain without needing to take any additional steps when obtaining certificates for the domain. Even if the CT log ecosystem substantially changes during the validity period of the certificate, site operators can provide updated SCTs in the form of OCSP responses (if their CA supports it) or via a TLS extension (if they wish for greater control). The combination of these mitigations substantially reduces the risk of DoS (either accidental or hostile) via Expect-CT deployment. By combining Expect-CT with active monitoring for relevant domains, which a growing number of CAs and third-parties now provide, site operators can proactively detect misissuance in a way that HPKP does not achieve, while also reducing the risk of misconfiguration and avoiding the risk of hostile pinning.
The big problem with pinning is that for most sites, losing the ability to publish the site is a vastly more significant concern than confidentiality. So I am not at all surprised that takeup was slim. Basically it is not possible to use it without an ops team that includes a world class crypto group or a world class Dunning Kreuger effect.
Pinning has two major effects:
1) It forces the use of TLS
2) It requires the use of a particular set of trust anchors.
CT and CAA help address the first but not the second. Currently, CT and CAA are two independent systems. Perhaps it is time to consider linking them and closing the loop via CT for DNSSEC.
On the security policy issue, I think it is past time to admit the failure of DANE and look at the blocking problems that have to be solved to get any sort of client side enforcement of server security policy. I see the problems of DANE as being
1) There is no administration infrastructure. Any security policy scheme that depends on administrators updating DNS records to match server configuration manually is doomed to fail.
2) The scheme is limited to TLS and is not integrated with DNS Discovery (RFC6763).
3) The scheme links security policy with trust anchor validation. While this might be feasible if you are working within an entirely novel discovery infrastructure (e.g. UDDI if it had worked), trying to do that in DNS not.
4) Any scheme that requires additional RR round trips is going to add latency and be unacceptable.
5) There is still far too much infrastructure that blocks unknown DNS RRs to make anything that requires delivery practical.
Despite the length of the list, these are all fixable if there is a will to do so.
--
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/he9tr7p3rZ8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f6a15f83-516e-4072-9eec-8133f224b02b%40chromium.org.
On Friday, October 27, 2017 at 9:07:54 PM UTC+2, Chris Palmer wrote:This will first remove support for HTTP-based PKP (“dynamic pins”), in which the user-agent learns of pin-sets for hosts by HTTP headers. We would like to do this in Chrome 67, which is estimated to be released to Stable on 29 May 2018.
I expect y'all will be putting in a deprecation warning in trunk shortly, and if there's no risk of breakage (and I agree with y'all's analysis that no site will stop working), it doesn't seem like you'd need a 3-release gap. Is there a reason you chose M67?Finally, remove support for built-in PKP (“static pins”) at a point in the future when Chrome requires Certificate Transparency for all publicly-trusted certificates (not just newly-issued publicly-trusted certificates). (We don’t yet know when this will be.)
It looks like the built-in pinsets we have in https://chromium.googlesource.com/chromium/src/+/9bf166893edc3cea7ae7194b0784d85e9ad2cf0f/net/http/transport_security_state_static.json are limited to Google, Tor, Twitter, Facebook, Dropbox, SpiderOak, Yahoo, swehack.org, NCSCCS, and Tumblr. It looks like we support requiring CT on an origin-by-origin basis with `Expect-CT`'s 'enforce' directive. If that's the case, is there still value in keeping the hard-coded list? It seems like we could drop the hard-coded list as soon as these origins independently start sending `Expect-CT: max-age=whatever; enforce`, rather than waiting for ecosystem-wide changes.
Pinning has two major effects:
1) It forces the use of TLS
2) It requires the use of a particular set of trust anchors.
CT and CAA help address the first but not the second. Currently, CT and CAA are two independent systems. Perhaps it is time to consider linking them and closing the loop via CT for DNSSEC.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvaWvYvp55ZiV7qkM9xdDh8%2BCx5A0ZrU_SvRj5NHMTABcy7zA%40mail.gmail.com.
Although I'm not an expert in this space, I'm a little uneasy about the apparent inconsistency between saying that the static pinning list must persist for some indefinite time, while the dynamic approach no longer has value.
I'd feel more comfortable if either (like Mike suggests) we removed static key pinning at the exact same time, or we at least had an open policy and clear instructions for what anyone who was sufficiently motivated could do to get their keys into our static list (I did a quick google search and checked the FAQ, but maybe I'm missing it?). For me this mostly falls under the "we go out of our way to make it clear that Google properties do not receive special treatment in Blink" comment in the blink compat principles.
Also, what's the best guidance we can point people to for understanding CT log anomolies and how to respond to them? I don't see anything really addressing that question in the CT FAQ.
On Mon, Oct 30, 2017 at 10:32 AM, Rick Byers <rby...@chromium.org> wrote:Although I'm not an expert in this space, I'm a little uneasy about the apparent inconsistency between saying that the static pinning list must persist for some indefinite time, while the dynamic approach no longer has value.Could you indicate where/how you arrived at that interpretation? We should definitely work to clarify that.
I think the statement here is that dynamic pinning is substantially more risky - both for those who try to use it (a bad fit for the platform) and those who don't want to use it (e.g. hostile pinning). These risks substantially outweigh the reward.
Static pinning is different, in this respect, on multiple dimensions. More importantly, the incremental approach allows for a meaningful reduction in risk to users and the ecosystem, without compatibility concerns.
I'd feel more comfortable if either (like Mike suggests) we removed static key pinning at the exact same time, or we at least had an open policy and clear instructions for what anyone who was sufficiently motivated could do to get their keys into our static list (I did a quick google search and checked the FAQ, but maybe I'm missing it?). For me this mostly falls under the "we go out of our way to make it clear that Google properties do not receive special treatment in Blink" comment in the blink compat principles.Historically, we've accepted anyone - it's been handled the same as HSTS submissions. However, given the deprecation plan - and the costs - I don't think we'd want to continue accepting inclusion requests.
With respect to the Blink Compat principles, I think that may be a misapplication, although well intentioned - after all, it was the same argument I put forward when arguing for standardization of HPKP. You can look at the static pin list on a number of dimensions - from a site operator perspective, it doesn't 'guarantee' more security, because it's not a fundamental part of the Web Platform.
From a user perspective, it doesn't make one browser that includes such pins more or less secure than another browser that doesn't - the sites and/or UA vendors themselves are responsible for detecting and mitigating the risk. From a Compat/Interop side, this doesn't provide any special advantages to one site over another - so I don't think it conflicts with those principles at all.
I think you'd agree that static pinning for various Google-specific features (e.g. translation, updates, sync) wouldn't be a concern - both from the fact that these aren't part of the Web Platform stack, but also that these are vendor-specific security settings. The major UA vendors (Apple, Microsoft, Mozilla) all provide some level of restrictions on updates and specific features, and this also doesn't undermine interop or compat.
Does that help address?Also, what's the best guidance we can point people to for understanding CT log anomolies and how to respond to them? I don't see anything really addressing that question in the CT FAQ."Best" is going to be inherently subjective and complex - it's somewhat similar to asking what's the best guidance we can give for people running a high-traffic site or for monitoring for brand/trademark abuse. There will be general principles, for sure, but many details will end up being specific to the use case/objective.
The simple answer is site operators should look for certificates for their domains they don't recognize - and a number of tools exist to help with that:For example, two automated tools are https://www.facebook.com/notes/protect-the-graph/introducing-our-certificate-transparency-monitoring-tool/1811919779048165/ or https://sslmate.com/certspotter/ (and a number of CAs provide their customers with equivalent tools)
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACvaWvYChispiRKZC8%3DhtyOywVBZrKM%2BDcPFU2hsXYoyUSsusA%40mail.gmail.com.
Historically, we've accepted anyone - it's been handled the same as HSTS submissions. However, given the deprecation plan - and the costs - I don't think we'd want to continue accepting inclusion requests.Keeping some in while not accepting new ones seems inconsistent to me. Would we also accept changes to the existing ones, or freeze the list entirely?
In practice perhaps this will never come up - that static pinning isn't really that important to anyone for it to matter. But I believe the integrity of our open intent process depends on us bein consistent in treating all of the web the same. Maybe we could agree that if such a request with Chrome usage above some threshold (applied retroactively to existing pinsets) comes in, then we'll commit to either adding it, or removing all our static pins at that time? Ideally I'd rather we treat sites the same regardless of usage level, but if we're going to have site whitelists then at least inclusion should be controled by some principled equation (i.e. chrome users impacted / cost, or just the top 12 in terms of usage) instead of being an arbitrary accident of history.
The simple answer is site operators should look for certificates for their domains they don't recognize - and a number of tools exist to help with that:For example, two automated tools are https://www.facebook.com/notes/protect-the-graph/introducing-our-certificate-transparency-monitoring-tool/1811919779048165/ or https://sslmate.com/certspotter/ (and a number of CAs provide their customers with equivalent tools)Cool. I see SSLMate even mentions some possible "corrective actions" that can be taken in their docs. Is there a page somewhere that has, or could be modified to have links like these so we at least have some explicit guidance we can link to?
First, a huge +1 to everything said by @jbash.
In my mind it seems pretty clearly not a feature that makes sense for every single website to use, but rather the small subset of sites with a particular need for confidentiality,
1. Short-term (Chrome 67): Restrict dynamic PKP to an HSTS-Preload-like whitelist, with a big scary warning in the submission form that the use of this feature is highly discouraged unless they have a specific need for it and an experienced InfoSec team to manage it.
This would be like deprecating WebRTC or Workers simply because they're relatively niche advanced features, when that would've been obvious all the way back during their standardization processes.
It may or may not be niche in the long run, but a lot of the value I see is actually in private networks, and I don't see it as being about "particular needs for confidentiality". Everything has a need for confidentiality.
What would be the point of dynamic pinning if you had to get the browser to whitelist it before it would work? Why would you want to force people to figure out how to supplicate themselves to however many browsers before they could make a server-side configuration decision?
> 2. Medium-to-long-term (ecosystem-wide collaboration): ...
Actually, if people could take all that security-damaging complexity out of browsers, I'd be pretty happy. I might even shut up about certs. I can give you a list of stuff to drop. I might let you keep JavaScript, but not without some grumbling. :-)
Not saying my proposal is ideal, but I'd say it's a lot more productive a stepping stone to something that everyone will be more or less okay with than "Intent to Deprecate".
The difficulty of setting up HPKP has been massively overblown here IMO, but I think it's fair to say that it shouldn't be implemented by a novice admin for anything important given its current interface and the current state of surrounding tooling.
What would be the point of dynamic pinning if you had to get the browser to whitelist it before it would work? Why would you want to force people to figure out how to supplicate themselves to however many browsers before they could make a server-side configuration decision?Why would the point change? I as a site operator want to use dynamic pinning on balls.com for whatever reason I have in mind. The only difference is now I have to wait a little bit for it to start working in Chrome until Google approves me (and potentially likewise for other browsers), and I have a few warnings shoved in my face that'll hopefully scare me off if I truly don't know what I'm doing.
I listed CAA first because (as noted in my and Bryant's Black Hat / DEF CON talk that brought attention to this risk in the form of "RansomPKP") it blocks low-effort attacks involving taking over any arbitrary box and grabbing a cert to pin from LetsEncrypt; you'd specifically need a cert from the CA they're already using.
Further, by attaching an EV requirement, there would be a higher level of confidence that whoever requested the certificate is actually the site owner and not an attacker.
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOuvq212inCp0nTNrGGF1a2mWH3aVToQ5%3Dsr%2BDGyY6abufbpWg%40mail.gmail.com.
Would that authentication work for, say, a .onion site, which could very reasonably want to pin?
Wait, that's different. If I understand what you say correctly, you want the browser not only to check whether CAA records exist, but also to look at the content of the CAA RR(s).