13 ms·

Public Key Pinning Being Removed from Chrome

261 points by ejcx 9y ago

sigmar 9y ago
Good riddance. It had low adoption and pales in comparison to what will be achieved with Certificate Transparency. DNS redirect attacks (common/easy due to social engr) combined with malicious HPKP could result in some nasty ransoming ("many of your users can't access your site unless you pay me for the key"). I've heard many surprised it hasn't happened yet. Particularly considering the lack of recourse options for victims.
- yebyen 9y ago
  What would be the fix? I'm asking sincerely as someone who is only surface level familiar with HPKP, and have never implemented it (but my boss did...) If someone ransomed you, would you need to pay them for the key, and then use the key on your site from then on? So, you could pay the ransom and they'd be able to decrypt all of your traffic from then on? (I'm sure I just don't know how HPKP works, like there's some solution where the ransomer's key/the compromised key can be used to sign another key, and then HPKP pinners that cached the bogus key can now accept it as the new key... but then couldn't you use a compromised key to do the same attack again in the future?)
  - mschuster91 9y ago
    > What would be the fix? I'm asking sincerely as someone who is only surface level familiar with HPKP, and have never implemented it (but my boss did...) The fix would be to embed the expected key fingerprint in DNS and have the browser issue either a 2nd request for it or have the DNS server return it as additional data just like when requesting a CNAME record and it returns the A record too. Then, to prevent DNS MITM attacks, have the whole zone and the domain's zonefile signed. On the other hand, given that DNS is UDP, this opens up the possibility of an MITM attacker simply suppressing the 2nd request for the HTTPS key, or corp firewalls/MITM boxes/crappy provider DNS servers simply filtering out the responses...
    - posixplz 9y ago
      Sounds a lot like DANE/TLSA.
      - mschuster91 9y ago
        Oh cool, haven't read about this one before. Wonder why it didn't get picked up despite being a standard :(
        rocqua 9y ago
        The basic reason is that people really don't like DNSSEC. tptaeck (https://news.ycombinator.com/user?id=tptacek https://news.ycombinator.com/user?id=tptacek) has plenty of comments really supporting that argument.
        dane-pgp 9y ago
        I won't say he's wrong, but he presents a very one-sided view. It's worth reading the responses to criticisms like his: https://www.easydns.com/blog/2015/08/06/for-dnssec/ https://www.easydns.com/blog/2015/08/06/for-dnssec/
        detaro 9y ago
        DANE is used a bit for SMTP (where it also forms a clear "only talk to our mail servers over TLS" signal, which as far as I know didn't exist before) As a replacement for HPKP it doesn't solve the big attack scenario of someone taking over your DNS and obtaining a certificate to impersonate your site: if they can do that, they can also put false certificate details in DNS. It's also tied to DNSSEC, which isn't universally deployed for domains, would if I understand correctly putting a full DNSSEC-resolver in the browsers to protect against local MITM (which isn't practical in many situations) and often criticized.
        hannob 9y ago
        > Wonder why it didn't get picked up despite being a standard :( It doesn't work on the real internet, only on some fantasy internet that merely exists in the head of DNSSEC advocates. Basically you can only do DNSSEC if you can receive arbitrary DNS records. That's not the case for a non-negligible portion of Internet accesses, where those queries get filtered. Adam Langley has pointed this out years ago: https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html So if you want to deploy DANE you can choose between falling back to insecure (so it's entirely pointless) or breaking the Internet for a large fraction of users. Neither is a very good plan.
  - pfg 9y ago
    You would indeed have to use the attacker's key until the pins of all visitors who visited the site during the attack expire. I believe the maximum HPKP max-age in Chrome is 2 months, it might be longer in Firefox. There is no mechanism that would allow you to use the attacker's key to sign another key: HPKP requires that the pinned key is present in the actual trust chain selected for your connection. You could switch to a non-compromised key a bit earlier by setting max-age to zero and waiting for a certain percentage of the affected visitors to return, if you're willing to accept that the remaining affected visitors cannot access the site for a few months.
- nly 9y ago
  > DNS redirect attacks (common/easy due to social engr) combined with malicious HPKP could result in some nasty ransoming How? Someone can hijack your resolver but they still need a valid certificate for the name before they can install the pin?
  - Laforet 9y ago
    Once an attacker controls a domain it is trivial to get a DV certificate signed with their own key.
    - nly 9y ago
      Hijacking a authorative DNS server is different kettle of fish to hijacking a resolver used by a client. You need to either infiltrate a CA or do the former for a DNS attack to work and get you a DV certificate.
      - user5994461 9y ago
        Once a site is breached, the attacker is usually in control of the domain and he can order any legitimate certificate for it.
darkhorn 9y ago
What about supporting client side certificates in HTTP2?
- detaro 9y ago
  Less a Chrome policy thing and more a "Nobody has suggested a solution the working group making the standard likes enough, so there isn't even a defined way how". So unless I missed a recent development, don't expect it to happen.
- andyjh 9y ago
  You can use client certificates in h2, you just can't do TLS renegotiation. So you have to request a client cert in the initial handshake; you can't ask later (eg for a specific URL).
Roritharr 9y ago
This is especially funny to me as our PCI DSS Network Scan just started flagging not having a HPKP Header as something thats necessary to remediate. I've had to waste half a day on the phone and then to write a Risk Mitigation Plan that explains how we mitigate the risk of an MITM Attack in case our CA gets breached...
- geofft 9y ago
  ... isn't the risk that HPKP mitigates the risk of a MITM attack in case some other CA gets breached?
  - detaro 9y ago
    HPKP also protects against your CA if you pin the direct private keys your servers use, but I bet it also is quite annoying to come up with a good plan for how you are not going to loose/delete all the private keys you have pinned...
    - geofft 9y ago
      Right. I'm curious which approach the auditors wanted - either one would be a weird thing to mandate! In theory, pinning your servers' private keys is actually kind of reasonable, if you generate like two or three sets of backup private keys and put them in off-site storage. And I've long been an advocate of buying at least one backup certificate from another CA just in case your current one gets distrusted. (And it makes sense from a technical perspective why HPKP supports both of these approaches, but the ambiguity probably didn't help it from a policy perspective).
- deleted 9y ago
  [deleted]
- tptacek 9y ago
  It is deeply fucked up if a scanning checklist demands PKP, since most sites --- including most commerce sites --- shouldn't pin.
weinzierl 9y ago
Interesting HN-discussion about the future of HPKP from a little over a year ago [1]. Reading it, I think this move was predictable. The article suggests the Expect-CT header as a safer alternative. Scott Helme has a short but informative write-up how this works[2]. [1] https://news.ycombinator.com/item?id=12434585 https://news.ycombinator.com/item?id=12434585 [2] https://scotthelme.co.uk/a-new-security-header-expect-ct/ https://scotthelme.co.uk/a-new-security-header-expect-ct/
- amluto 9y ago
  Crikeys. By that point the damage is done. How about a read-CAA-via-DNSSEC-and-confirm-that-it's-the-right-CA header? (The certificate could embed a DNSSEC assertion about the CAA header or lack thereof, for that matter.)
pfg 9y ago
Removing dynamic pins was inevitable given the associated risk for all sites. Some ideas to fix those exist[1], but I'm not sure it's worth the effort in a fully CT-enforced web. That's probably time better spent somewhere else (such as improving CT itself and the gossip mechanism.) I'm not convinced that static pins need to go too. There are something like 10 sites on that list currently, and all of them are valuable targets and should have the resources to ensure their pins don't fail. Even increasing that number to something like 100 should be manageable for browser vendors and would cover a large percentage of all page views (rather than just guarantee discovery after the fact). [1]: https://blog.qualys.com/ssllabs/2017/09/05/fixing-hpkp-with-pin-revocation https://blog.qualys.com/ssllabs/2017/09/05/fixing-hpkp-with-...
saas_co_de 9y ago
why not provide an advanced feature that alerts you any time a cert changes, similar to what we get with SSH? at least then security conscious users could make decisions for themselves.
- PhantomGremlin 9y ago
  why not provide an advanced feature that alerts you any time a cert changes Because certificates change ... all ... the ... time. Again ... and ... again ... and ... again. Years ago I tried using a Firefox addon called Certificate Patrol. I spent half my time approving changes. Here's a Stack Exchange question on exactly that topic. It's a few years old; I don't know if things have gotten better: https://security.stackexchange.com/questions/41578/why-does-google-ssl-cert-change-so-frequently https://security.stackexchange.com/questions/41578/why-does-...
  - posixplz 9y ago
    I imagine things have only gotten "worse" with Let'sEncrypt issuing 90 certificates.
    - Confiks 9y ago
      You pin a public key (of which the private key signs the leaf certificate, the sub-CA or the CA) with HPKP, not the certificate. With the default settings, LetsEncrypt re-uses the keypair for a new certificate.
  - wnevets 9y ago
    >Years ago I tried using a Firefox addon called Certificate Patrol. yeah I too gave up on using that addon for the same reason
  - lucb1e 9y ago
    > Because certificates change ... all ... the ... time. Not OP but I do see potential there. I've thought about it before. Try looking at it from a solution perspective rather than from "why don't we already" and "what would the issues be": certs change, yeah, but usually because they (almost) expired. We should check when Let'sEncrypt renews by default (is that 14 days before expiry?) and what common practice is, and go from there in triggering a warning. And if there is some uncommon reason to roll over (e.g. suspected compromise), a header could be set either in advance or one could be set that signs the new fingerprint with the old key. The new one shouldn't be pinned right away since an attacker might have misused a compromised key, and a warning symbol could be displayed similar to the mixed-content warning. If someone is suspicious and it can't be delayed, they can call their bank (or whatever it is) and they'd know about it and be able to confirm things out of band. I'm just conceptualizing but I don't see anything that's not easily solved. I think it could be a good addition.
buu700 9y ago
I can't support this at all, and ironically this is partially my fault. My and @eganist's Black Hat / DEF CON talk "Abusing Bleeding Edge Web Standards for AppSec Glory" demoed an exploit concept that we called "RansomPKP", which was essentially a pattern of hostile pinning that could theoretically enable pivoting from a web server compromise to holding a site for ransom. Hostile pinning was by no means a new concept, and even has some discussion in the IETF spec itself, but we found this to be a fun novel application and used it to spur some minor security improvements to browsers' HPKP implementations. However, this talk also led to concerns being vocalized about the viability of HPKP in general (https://news.ycombinator.com/item?id=12434585 https://news.ycombinator.com/item?id=12434585), ultimately leading to this. This was not our intention at all, and I don't see hostile pinning alone as a reason to give up on HPKP. I would much rather see some discussion around improving the usability of HPKP before jumping straight to putting it on the chopping block — both from a site operator's end and a user end. For example, off the top of my head, why not make it possible for users to click past the HPKP error screen like they can with any other TLS error screen?
- phyzome 9y ago
  I'm curious about that followup message (is that you?) about how Cyph (seems to be some sort of encrypted messaging thing) relies on "HPKP Suicide" for... in-browser code-signing? I didn't find any resources laying out exactly how this works.
  - buu700 9y ago
    The first comment on that thread is from @eganist (not me, but my colleague). This is how Cyph's HPKP-based code signing works: https://cyph.team/websigndoc https://cyph.team/websigndoc tl;dr: the same idea that we showed how to apply maliciously via RansomPKP is also applied for defensive purposes, in this case to persistently pin a client-side page with logic that validates and runs signed packages.
    - dane-pgp 9y ago
      Here's a potentially easier to read (doesn't require JavaScript) document explaining WebSign: https://www.cyph.com/websign https://www.cyph.com/websign It's a really smart idea, although it did have some odd edge cases, and required you to trust that they really were throwing away the keys as promised. There is some talk in the W3C of extending the SRI standard to let a website declare that all (or just certain) included resources have been signed by an (offline) PGP key: https://github.com/w3c/webappsec/issues/449 https://github.com/w3c/webappsec/issues/449 so we might one day reach a point where running a webapp at least has the small security guarantee that a TOFU policy gives you. If this could be combined with versioned releases of webapps, and the signature appearing in something like a Binary Transparency log, then the security guarantee could actually be quite meaningful: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency
deleted 9y ago
[deleted]
Exuma 9y ago
Can someone explain all this like im 5? I've always wondered what all this was about.
- grizzles 9y ago
  An attacker (eg. a criminal or foreign power) can pretend to be a website you know. Certificate pinning is a way for website to alert you to a hostile change of certificate. HPKP Cert pinning has some issues that create other problems. Chrome is removing HPKP Cert pinning and replacing it with something better called Expect-CT.
- dfabulich 9y ago
  On the internet, when you send and receive data, your data gets handled by a lot of different people. In the old days, anybody who handled your data could tamper with it or impersonate anybody else. Cryptography to the rescue. Suppose "Alice" and "Bob" want to send secret messages to each other, without allowing "Eve" the eavesdropper to read them, even if Eve can intercept the messages. Traditional cryptography is "symmetric," where both Alice and Bob must share a secret before they can communicate. Symmetric cryptography won't suffice over the internet, because if Alice and Bob had a secure way of sharing secrets, they wouldn't need internet cryptography in the first place. So the internet relies on public-key cryptography, where Alice and Bob each have a pair of keys (a "key pair"), one "public" key that everyone can see, even Eve, and one "private" key that has to be kept secret. Alice can encrypt a message using Bob's public key that can only be decrypted using Bob's private key. At first, it might seem like public-key crypto solves the problem completely, but it creates a new problem: how will Alice get Bob's public key? If she asks Bob for his public key over an unencrypted public channel, Eve can intercept it and offer her own public key, acting as a "man in the middle" (MITM). Luckily, public-key cryptography has one more trick up its sleeve. If you "encrypt" a message using a private key, it can be "decrypted" using the public key. Only Bob (the owner of Bob's private key) can encrypt messages that can be decrypted with Bob's public key, so anything Bob encrypts that way is effectively "signed" by Bob. If Alice and Bob trust a third party, Charlie, Charlie can sign a message saying: "This is Bob's public key: 12345" and another message saying "This is Alice's public key: 23456". Eve can't impersonate Charlie without his private key. We call Charlie a "certificate authority." (CA) When you visit an HTTPS website, the site presents a certificate signed by a CA. Your browser trusts a ton of CAs all over the world, many of them run by governments that you may not really want to trust; any of them can use their private keys to impersonate any site on the internet. This is a hard social problem as much as a technical problem. High-value websites like Gmail, Facebook, or banks may want to say "Here's our certificate, but don't just trust any certificate authority about that. You should only trust Charlie's signature." That's called "pinning" the public key to a certificate authority. It's a nice idea, but how will Gmail convey that message to its users? If Eve is a hostile government who intercepts messages and owns a trusted CA, they can impersonate Gmail, saying "Oh, you don't need to trust Charlie exclusively. You can trust any CA, even me." Chrome comes with a static, hard-coded list of pinned keys for high-value sites, but that can't scale. They had the idea of allowing anybody on the internet to pin their keys, "dynamic" pinned keys or HTTP-based key public key pinning (HPKP). The problem is, if you pin your public key and you need to change it for some reason, or if you need to switch certificate authorities for any reason, you're in big trouble. People have used HPKP and brought their site down, unable to bring it back up again, because browsers don't trust their new valid key. As a result, very few sites used HPKP, so the Chrome team is planning to remove it. Surprisingly to me, they even plan to remove the static list of pinned keys, in favor of "Certificate Transparency" where it's publicly obvious which CAs are signing which certificates. Rogue CAs would then have to reveal that they've gone rogue, at which point browsers could revoke their automatic trust in them.
alpb 9y ago
As someone who's completely unfamiliar with the Chrome ecosystem I wonder what Blink has anything to do with this (why is this posted in blink-dev@googlegroups.com)? Isn't Blink just the rendering engine for Chromium that does DOM/CSS stuff?
- wolf550e 9y ago
  They used to coordinate security stuff on mozilla.dev.security.policy but they switched to blink-dev, maybe to indicate this is Chrome's/Google's position only. The first big use of blink-dev for security that I remember was the Symantec thing.
feelin_googley 9y ago
non-javascript url: https://groups.google.com/a/chromium.org/forum/?_escaped_fragment_=msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ https://groups.google.com/a/chromium.org/forum/?_escaped_fra...
MichaelMoser123 9y ago
Kazakhstan and probably Russia as well require all TLS traffic to be opened by MITM devices. https://m.habrahabr.ru/post/303736/ https://m.habrahabr.ru/post/303736/ https://news.ycombinator.com/item?id=10663843 https://news.ycombinator.com/item?id=10663843 https://www.google.co.il/amp/s/www.rbth.com/document/103300000000001000150127/amp https://www.google.co.il/amp/s/www.rbth.com/document/1033000... i wonder if other governments are enacting similar rules in one form or the other....
- jopsen 9y ago
  That sounds hard to implement. If it's done by issuing a new certificate for a different key then won't it trigger red flags when certificate transparency becomes mandatory? Resulting in the CA getting the kick.
  - pfg 9y ago
    IIRC the plan was to force users to manually install a root certificate (controlled by the government) on their devices. Local roots are exempt from any CT enforcement. Naturally, you can just not install the root certificate, but if all traffic is intercepted, I'd expect most users to do so to get around the warnings.
    - jopsen 9y ago
      That probably only works if the root cert is mandated in all OEM installs... And still you probably won't find any Linux distros with this support. Note. incepting all traffic sounds expensive and very dangerous, ie. risk or leaking grows when you scale. It's probably better to only use it for select users. Curious, why future versions of chrome would not force CT for official TLDs?
      - pfg 9y ago
        > Curious, why future versions of chrome would not force CT for official TLDs? This would cause all corporate MitM proxies to fail. Certificates generated by these devices cannot be logged to the CT log servers accepted by browsers (they only accept certificates chaining back to a trusted root). Local roots were exempt from HPKP pins as well, so this is just keeping with existing policy.
jkooper 9y ago
Is there an alternative to prevent people from doing MITM attacks on mobile apps? With HPKP running, apps with Charles requires a rooted device.
- jakub_g 9y ago
  For mobile apps it's easier than for websites because native apps have more control over what's going on than the website, and can read the details of http connections (so in worst case, you can roll out your own pinning). For Android there are a built-in facilities for that in modern versions: https://developer.android.com/training/articles/security-config.html https://developer.android.com/training/articles/security-con... For iOS: not an expert, but this article seems good https://dzone.com/articles/ssl-certificate-pinning-in-ios-applications https://dzone.com/articles/ssl-certificate-pinning-in-ios-ap... It might get a bit trickier when WebViews are involved though because, at least on Android, SSL in WebView is subject to different security rules than the java-initiated connections (AFAIU the problems due to https://www.chromium.org/developers/androidwebview/webview-ct-bug https://www.chromium.org/developers/androidwebview/webview-c... could not have been avoided on the app side, for example, as it was a bug in Chromium).
  - strcat 9y ago
    > It might get a bit trickier when WebViews are involved though because, at least on Android, SSL in WebView is subject to different security rules than the java-initiated connections They've started changing that: https://developer.android.com/about/versions/oreo/android-8.0-changes.html#o-sec https://developer.android.com/about/versions/oreo/android-8....
hsivonen 9y ago
Seems reasonable to remove HPKP. In my experience the use case that HPKP addresses the best is winning arguments with people who like ssh and think WebPKI and browsers are wrong. HPKP can be used to establish TOFU trust in the leaf key (but you need to pin your future key, too). Winning that argument isn't worth the risks of HPKP, though.
_Codemonkeyism 9y ago
The same as with 301, everyone recoomends them until they buy a domain or do some restructuring with new people some years down the line and 301 totally messed their site up without any reset button.
- jakub_g 9y ago
  Can you explain this more?
  - rav 9y ago
    HTTP provides a couple of different response codes for when one URL should redirect to another URL. The most common are 301 Moved Permanently and 302 Found, aka moved temporarily. When designing a website and you find the need to redirect one URL to another, you have to choose which HTTP response code to use for the redirect. You might naively think 301 Moved Permanently is the right choice for when you perceive the redirection to be a non-temporary thing. Unfortunately HTTP 301 responses are cached very aggressively by web browsers by default, so if you install a 301 redirect in your website and choose to revert it, clients who have already seen the now-reverted 301 redirect will just keep following the cached redirect. Basically, unless the URL you're redirecting is receiving way more than a thousand hits per second (i.e. unless you're running a large-scale website with lots of traffic), you should always use the temporary 302 redirect, even though you might perceive the redirection to be non-temporary.
    - _Codemonkeyism 9y ago
      Thanks for doing what would have been my job. Appreciated.
ComodoHacker 9y ago
Without key pinning, are threre other options for site operators to protect their users from MITM by traffic monitoring appliances?
- strcat 9y ago
  HPKP doesn't protect against MITM via locally installed trust anchors. It explicitly permits that in both Chromium and Firefox.
peterwwillis 9y ago
Ah, Google. The tech gods giveth standards, and the tech gods taketh standards away. This is what happens when you let a single vendor define web standards, and have a majority share of the browser market. They can take their toys and go home, and websites won't support what they don't support.

261 points by ejcx 9y ago

Good riddance. It had low adoption and pales in comparison to what will be achieved with Certificate Transparency. DNS redirect attacks (common/easy due to social engr) combined with malicious HPKP could result in some nasty ransoming ("many of your users can't access your site unless you pay me for the key"). I've heard many surprised it hasn't happened yet. Particularly considering the lack of recourse options for victims.

yebyen 9y ago
What would be the fix? I'm asking sincerely as someone who is only surface level familiar with HPKP, and have never implemented it (but my boss did...) If someone ransomed you, would you need to pay them for the key, and then use the key on your site from then on? So, you could pay the ransom and they'd be able to decrypt all of your traffic from then on? (I'm sure I just don't know how HPKP works, like there's some solution where the ransomer's key/the compromised key can be used to sign another key, and then HPKP pinners that cached the bogus key can now accept it as the new key... but then couldn't you use a compromised key to do the same attack again in the future?)
- mschuster91 9y ago
  > What would be the fix? I'm asking sincerely as someone who is only surface level familiar with HPKP, and have never implemented it (but my boss did...) The fix would be to embed the expected key fingerprint in DNS and have the browser issue either a 2nd request for it or have the DNS server return it as additional data just like when requesting a CNAME record and it returns the A record too. Then, to prevent DNS MITM attacks, have the whole zone and the domain's zonefile signed. On the other hand, given that DNS is UDP, this opens up the possibility of an MITM attacker simply suppressing the 2nd request for the HTTPS key, or corp firewalls/MITM boxes/crappy provider DNS servers simply filtering out the responses...
  - posixplz 9y ago
    Sounds a lot like DANE/TLSA.
    - mschuster91 9y ago
      Oh cool, haven't read about this one before. Wonder why it didn't get picked up despite being a standard :(
      - rocqua 9y ago
        The basic reason is that people really don't like DNSSEC. tptaeck (https://news.ycombinator.com/user?id=tptacek https://news.ycombinator.com/user?id=tptacek) has plenty of comments really supporting that argument.
        dane-pgp 9y ago
        I won't say he's wrong, but he presents a very one-sided view. It's worth reading the responses to criticisms like his: https://www.easydns.com/blog/2015/08/06/for-dnssec/ https://www.easydns.com/blog/2015/08/06/for-dnssec/
      - detaro 9y ago
        DANE is used a bit for SMTP (where it also forms a clear "only talk to our mail servers over TLS" signal, which as far as I know didn't exist before) As a replacement for HPKP it doesn't solve the big attack scenario of someone taking over your DNS and obtaining a certificate to impersonate your site: if they can do that, they can also put false certificate details in DNS. It's also tied to DNSSEC, which isn't universally deployed for domains, would if I understand correctly putting a full DNSSEC-resolver in the browsers to protect against local MITM (which isn't practical in many situations) and often criticized.
      - hannob 9y ago
        > Wonder why it didn't get picked up despite being a standard :( It doesn't work on the real internet, only on some fantasy internet that merely exists in the head of DNSSEC advocates. Basically you can only do DNSSEC if you can receive arbitrary DNS records. That's not the case for a non-negligible portion of Internet accesses, where those queries get filtered. Adam Langley has pointed this out years ago: https://www.imperialviolet.org/2015/01/17/notdane.html https://www.imperialviolet.org/2015/01/17/notdane.html So if you want to deploy DANE you can choose between falling back to insecure (so it's entirely pointless) or breaking the Internet for a large fraction of users. Neither is a very good plan.
- pfg 9y ago
  You would indeed have to use the attacker's key until the pins of all visitors who visited the site during the attack expire. I believe the maximum HPKP max-age in Chrome is 2 months, it might be longer in Firefox. There is no mechanism that would allow you to use the attacker's key to sign another key: HPKP requires that the pinned key is present in the actual trust chain selected for your connection. You could switch to a non-compromised key a bit earlier by setting max-age to zero and waiting for a certain percentage of the affected visitors to return, if you're willing to accept that the remaining affected visitors cannot access the site for a few months.
nly 9y ago
> DNS redirect attacks (common/easy due to social engr) combined with malicious HPKP could result in some nasty ransoming How? Someone can hijack your resolver but they still need a valid certificate for the name before they can install the pin?
- Laforet 9y ago
  Once an attacker controls a domain it is trivial to get a DV certificate signed with their own key.
  - nly 9y ago
    Hijacking a authorative DNS server is different kettle of fish to hijacking a resolver used by a client. You need to either infiltrate a CA or do the former for a DNS attack to work and get you a DV certificate.
    - user5994461 9y ago
      Once a site is breached, the attacker is usually in control of the domain and he can order any legitimate certificate for it.

darkhorn 9y ago

What about supporting client side certificates in HTTP2?

detaro 9y ago
Less a Chrome policy thing and more a "Nobody has suggested a solution the working group making the standard likes enough, so there isn't even a defined way how". So unless I missed a recent development, don't expect it to happen.
andyjh 9y ago
You can use client certificates in h2, you just can't do TLS renegotiation. So you have to request a client cert in the initial handshake; you can't ask later (eg for a specific URL).

Roritharr 9y ago

This is especially funny to me as our PCI DSS Network Scan just started flagging not having a HPKP Header as something thats necessary to remediate. I've had to waste half a day on the phone and then to write a Risk Mitigation Plan that explains how we mitigate the risk of an MITM Attack in case our CA gets breached...

geofft 9y ago
... isn't the risk that HPKP mitigates the risk of a MITM attack in case some other CA gets breached?
- detaro 9y ago
  HPKP also protects against your CA if you pin the direct private keys your servers use, but I bet it also is quite annoying to come up with a good plan for how you are not going to loose/delete all the private keys you have pinned...
  - geofft 9y ago
    Right. I'm curious which approach the auditors wanted - either one would be a weird thing to mandate! In theory, pinning your servers' private keys is actually kind of reasonable, if you generate like two or three sets of backup private keys and put them in off-site storage. And I've long been an advocate of buying at least one backup certificate from another CA just in case your current one gets distrusted. (And it makes sense from a technical perspective why HPKP supports both of these approaches, but the ambiguity probably didn't help it from a policy perspective).
deleted 9y ago
[deleted]
tptacek 9y ago
It is deeply fucked up if a scanning checklist demands PKP, since most sites --- including most commerce sites --- shouldn't pin.

weinzierl 9y ago

Interesting HN-discussion about the future of HPKP from a little over a year ago [1]. Reading it, I think this move was predictable. The article suggests the Expect-CT header as a safer alternative. Scott Helme has a short but informative write-up how this works[2]. [1] https://news.ycombinator.com/item?id=12434585 https://news.ycombinator.com/item?id=12434585 [2] https://scotthelme.co.uk/a-new-security-header-expect-ct/ https://scotthelme.co.uk/a-new-security-header-expect-ct/

amluto 9y ago
Crikeys. By that point the damage is done. How about a read-CAA-via-DNSSEC-and-confirm-that-it's-the-right-CA header? (The certificate could embed a DNSSEC assertion about the CAA header or lack thereof, for that matter.)

pfg 9y ago

Removing dynamic pins was inevitable given the associated risk for all sites. Some ideas to fix those exist[1], but I'm not sure it's worth the effort in a fully CT-enforced web. That's probably time better spent somewhere else (such as improving CT itself and the gossip mechanism.) I'm not convinced that static pins need to go too. There are something like 10 sites on that list currently, and all of them are valuable targets and should have the resources to ensure their pins don't fail. Even increasing that number to something like 100 should be manageable for browser vendors and would cover a large percentage of all page views (rather than just guarantee discovery after the fact). [1]: https://blog.qualys.com/ssllabs/2017/09/05/fixing-hpkp-with-pin-revocation https://blog.qualys.com/ssllabs/2017/09/05/fixing-hpkp-with-...

saas_co_de 9y ago

why not provide an advanced feature that alerts you any time a cert changes, similar to what we get with SSH? at least then security conscious users could make decisions for themselves.

PhantomGremlin 9y ago
why not provide an advanced feature that alerts you any time a cert changes Because certificates change ... all ... the ... time. Again ... and ... again ... and ... again. Years ago I tried using a Firefox addon called Certificate Patrol. I spent half my time approving changes. Here's a Stack Exchange question on exactly that topic. It's a few years old; I don't know if things have gotten better: https://security.stackexchange.com/questions/41578/why-does-google-ssl-cert-change-so-frequently https://security.stackexchange.com/questions/41578/why-does-...
- posixplz 9y ago
  I imagine things have only gotten "worse" with Let'sEncrypt issuing 90 certificates.
  - Confiks 9y ago
    You pin a public key (of which the private key signs the leaf certificate, the sub-CA or the CA) with HPKP, not the certificate. With the default settings, LetsEncrypt re-uses the keypair for a new certificate.
- wnevets 9y ago
  >Years ago I tried using a Firefox addon called Certificate Patrol. yeah I too gave up on using that addon for the same reason
- lucb1e 9y ago
  > Because certificates change ... all ... the ... time. Not OP but I do see potential there. I've thought about it before. Try looking at it from a solution perspective rather than from "why don't we already" and "what would the issues be": certs change, yeah, but usually because they (almost) expired. We should check when Let'sEncrypt renews by default (is that 14 days before expiry?) and what common practice is, and go from there in triggering a warning. And if there is some uncommon reason to roll over (e.g. suspected compromise), a header could be set either in advance or one could be set that signs the new fingerprint with the old key. The new one shouldn't be pinned right away since an attacker might have misused a compromised key, and a warning symbol could be displayed similar to the mixed-content warning. If someone is suspicious and it can't be delayed, they can call their bank (or whatever it is) and they'd know about it and be able to confirm things out of band. I'm just conceptualizing but I don't see anything that's not easily solved. I think it could be a good addition.

buu700 9y ago

I can't support this at all, and ironically this is partially my fault. My and @eganist's Black Hat / DEF CON talk "Abusing Bleeding Edge Web Standards for AppSec Glory" demoed an exploit concept that we called "RansomPKP", which was essentially a pattern of hostile pinning that could theoretically enable pivoting from a web server compromise to holding a site for ransom. Hostile pinning was by no means a new concept, and even has some discussion in the IETF spec itself, but we found this to be a fun novel application and used it to spur some minor security improvements to browsers' HPKP implementations. However, this talk also led to concerns being vocalized about the viability of HPKP in general (https://news.ycombinator.com/item?id=12434585 https://news.ycombinator.com/item?id=12434585), ultimately leading to this. This was not our intention at all, and I don't see hostile pinning alone as a reason to give up on HPKP. I would much rather see some discussion around improving the usability of HPKP before jumping straight to putting it on the chopping block — both from a site operator's end and a user end. For example, off the top of my head, why not make it possible for users to click past the HPKP error screen like they can with any other TLS error screen?

phyzome 9y ago
I'm curious about that followup message (is that you?) about how Cyph (seems to be some sort of encrypted messaging thing) relies on "HPKP Suicide" for... in-browser code-signing? I didn't find any resources laying out exactly how this works.
- buu700 9y ago
  The first comment on that thread is from @eganist (not me, but my colleague). This is how Cyph's HPKP-based code signing works: https://cyph.team/websigndoc https://cyph.team/websigndoc tl;dr: the same idea that we showed how to apply maliciously via RansomPKP is also applied for defensive purposes, in this case to persistently pin a client-side page with logic that validates and runs signed packages.
  - dane-pgp 9y ago
    Here's a potentially easier to read (doesn't require JavaScript) document explaining WebSign: https://www.cyph.com/websign https://www.cyph.com/websign It's a really smart idea, although it did have some odd edge cases, and required you to trust that they really were throwing away the keys as promised. There is some talk in the W3C of extending the SRI standard to let a website declare that all (or just certain) included resources have been signed by an (offline) PGP key: https://github.com/w3c/webappsec/issues/449 https://github.com/w3c/webappsec/issues/449 so we might one day reach a point where running a webapp at least has the small security guarantee that a TOFU policy gives you. If this could be combined with versioned releases of webapps, and the signature appearing in something like a Binary Transparency log, then the security guarantee could actually be quite meaningful: https://wiki.mozilla.org/Security/Binary_Transparency https://wiki.mozilla.org/Security/Binary_Transparency

deleted 9y ago

[deleted]

Exuma 9y ago

Can someone explain all this like im 5? I've always wondered what all this was about.

grizzles 9y ago
An attacker (eg. a criminal or foreign power) can pretend to be a website you know. Certificate pinning is a way for website to alert you to a hostile change of certificate. HPKP Cert pinning has some issues that create other problems. Chrome is removing HPKP Cert pinning and replacing it with something better called Expect-CT.
dfabulich 9y ago
On the internet, when you send and receive data, your data gets handled by a lot of different people. In the old days, anybody who handled your data could tamper with it or impersonate anybody else. Cryptography to the rescue. Suppose "Alice" and "Bob" want to send secret messages to each other, without allowing "Eve" the eavesdropper to read them, even if Eve can intercept the messages. Traditional cryptography is "symmetric," where both Alice and Bob must share a secret before they can communicate. Symmetric cryptography won't suffice over the internet, because if Alice and Bob had a secure way of sharing secrets, they wouldn't need internet cryptography in the first place. So the internet relies on public-key cryptography, where Alice and Bob each have a pair of keys (a "key pair"), one "public" key that everyone can see, even Eve, and one "private" key that has to be kept secret. Alice can encrypt a message using Bob's public key that can only be decrypted using Bob's private key. At first, it might seem like public-key crypto solves the problem completely, but it creates a new problem: how will Alice get Bob's public key? If she asks Bob for his public key over an unencrypted public channel, Eve can intercept it and offer her own public key, acting as a "man in the middle" (MITM). Luckily, public-key cryptography has one more trick up its sleeve. If you "encrypt" a message using a private key, it can be "decrypted" using the public key. Only Bob (the owner of Bob's private key) can encrypt messages that can be decrypted with Bob's public key, so anything Bob encrypts that way is effectively "signed" by Bob. If Alice and Bob trust a third party, Charlie, Charlie can sign a message saying: "This is Bob's public key: 12345" and another message saying "This is Alice's public key: 23456". Eve can't impersonate Charlie without his private key. We call Charlie a "certificate authority." (CA) When you visit an HTTPS website, the site presents a certificate signed by a CA. Your browser trusts a ton of CAs all over the world, many of them run by governments that you may not really want to trust; any of them can use their private keys to impersonate any site on the internet. This is a hard social problem as much as a technical problem. High-value websites like Gmail, Facebook, or banks may want to say "Here's our certificate, but don't just trust any certificate authority about that. You should only trust Charlie's signature." That's called "pinning" the public key to a certificate authority. It's a nice idea, but how will Gmail convey that message to its users? If Eve is a hostile government who intercepts messages and owns a trusted CA, they can impersonate Gmail, saying "Oh, you don't need to trust Charlie exclusively. You can trust any CA, even me." Chrome comes with a static, hard-coded list of pinned keys for high-value sites, but that can't scale. They had the idea of allowing anybody on the internet to pin their keys, "dynamic" pinned keys or HTTP-based key public key pinning (HPKP). The problem is, if you pin your public key and you need to change it for some reason, or if you need to switch certificate authorities for any reason, you're in big trouble. People have used HPKP and brought their site down, unable to bring it back up again, because browsers don't trust their new valid key. As a result, very few sites used HPKP, so the Chrome team is planning to remove it. Surprisingly to me, they even plan to remove the static list of pinned keys, in favor of "Certificate Transparency" where it's publicly obvious which CAs are signing which certificates. Rogue CAs would then have to reveal that they've gone rogue, at which point browsers could revoke their automatic trust in them.

alpb 9y ago

As someone who's completely unfamiliar with the Chrome ecosystem I wonder what Blink has anything to do with this (why is this posted in blink-dev@googlegroups.com)? Isn't Blink just the rendering engine for Chromium that does DOM/CSS stuff?

wolf550e 9y ago
They used to coordinate security stuff on mozilla.dev.security.policy but they switched to blink-dev, maybe to indicate this is Chrome's/Google's position only. The first big use of blink-dev for security that I remember was the Symantec thing.

feelin_googley 9y ago

non-javascript url: https://groups.google.com/a/chromium.org/forum/?_escaped_fragment_=msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ https://groups.google.com/a/chromium.org/forum/?_escaped_fra...

MichaelMoser123 9y ago

Kazakhstan and probably Russia as well require all TLS traffic to be opened by MITM devices. https://m.habrahabr.ru/post/303736/ https://m.habrahabr.ru/post/303736/ https://news.ycombinator.com/item?id=10663843 https://news.ycombinator.com/item?id=10663843 https://www.google.co.il/amp/s/www.rbth.com/document/103300000000001000150127/amp https://www.google.co.il/amp/s/www.rbth.com/document/1033000... i wonder if other governments are enacting similar rules in one form or the other....

jopsen 9y ago
That sounds hard to implement. If it's done by issuing a new certificate for a different key then won't it trigger red flags when certificate transparency becomes mandatory? Resulting in the CA getting the kick.
- pfg 9y ago
  IIRC the plan was to force users to manually install a root certificate (controlled by the government) on their devices. Local roots are exempt from any CT enforcement. Naturally, you can just not install the root certificate, but if all traffic is intercepted, I'd expect most users to do so to get around the warnings.
  - jopsen 9y ago
    That probably only works if the root cert is mandated in all OEM installs... And still you probably won't find any Linux distros with this support. Note. incepting all traffic sounds expensive and very dangerous, ie. risk or leaking grows when you scale. It's probably better to only use it for select users. Curious, why future versions of chrome would not force CT for official TLDs?
    - pfg 9y ago
      > Curious, why future versions of chrome would not force CT for official TLDs? This would cause all corporate MitM proxies to fail. Certificates generated by these devices cannot be logged to the CT log servers accepted by browsers (they only accept certificates chaining back to a trusted root). Local roots were exempt from HPKP pins as well, so this is just keeping with existing policy.

jkooper 9y ago

Is there an alternative to prevent people from doing MITM attacks on mobile apps? With HPKP running, apps with Charles requires a rooted device.

jakub_g 9y ago
For mobile apps it's easier than for websites because native apps have more control over what's going on than the website, and can read the details of http connections (so in worst case, you can roll out your own pinning). For Android there are a built-in facilities for that in modern versions: https://developer.android.com/training/articles/security-config.html https://developer.android.com/training/articles/security-con... For iOS: not an expert, but this article seems good https://dzone.com/articles/ssl-certificate-pinning-in-ios-applications https://dzone.com/articles/ssl-certificate-pinning-in-ios-ap... It might get a bit trickier when WebViews are involved though because, at least on Android, SSL in WebView is subject to different security rules than the java-initiated connections (AFAIU the problems due to https://www.chromium.org/developers/androidwebview/webview-ct-bug https://www.chromium.org/developers/androidwebview/webview-c... could not have been avoided on the app side, for example, as it was a bug in Chromium).
- strcat 9y ago
  > It might get a bit trickier when WebViews are involved though because, at least on Android, SSL in WebView is subject to different security rules than the java-initiated connections They've started changing that: https://developer.android.com/about/versions/oreo/android-8.0-changes.html#o-sec https://developer.android.com/about/versions/oreo/android-8....

hsivonen 9y ago

Seems reasonable to remove HPKP. In my experience the use case that HPKP addresses the best is winning arguments with people who like ssh and think WebPKI and browsers are wrong. HPKP can be used to establish TOFU trust in the leaf key (but you need to pin your future key, too). Winning that argument isn't worth the risks of HPKP, though.

_Codemonkeyism 9y ago

The same as with 301, everyone recoomends them until they buy a domain or do some restructuring with new people some years down the line and 301 totally messed their site up without any reset button.

jakub_g 9y ago
Can you explain this more?
- rav 9y ago
  HTTP provides a couple of different response codes for when one URL should redirect to another URL. The most common are 301 Moved Permanently and 302 Found, aka moved temporarily. When designing a website and you find the need to redirect one URL to another, you have to choose which HTTP response code to use for the redirect. You might naively think 301 Moved Permanently is the right choice for when you perceive the redirection to be a non-temporary thing. Unfortunately HTTP 301 responses are cached very aggressively by web browsers by default, so if you install a 301 redirect in your website and choose to revert it, clients who have already seen the now-reverted 301 redirect will just keep following the cached redirect. Basically, unless the URL you're redirecting is receiving way more than a thousand hits per second (i.e. unless you're running a large-scale website with lots of traffic), you should always use the temporary 302 redirect, even though you might perceive the redirection to be non-temporary.
  - _Codemonkeyism 9y ago
    Thanks for doing what would have been my job. Appreciated.

ComodoHacker 9y ago

Without key pinning, are threre other options for site operators to protect their users from MITM by traffic monitoring appliances?

strcat 9y ago
HPKP doesn't protect against MITM via locally installed trust anchors. It explicitly permits that in both Chromium and Firefox.

peterwwillis 9y ago

Ah, Google. The tech gods giveth standards, and the tech gods taketh standards away. This is what happens when you let a single vendor define web standards, and have a majority share of the browser market. They can take their toys and go home, and websites won't support what they don't support.