6 ms·

This sounds like pretty much the same argument that @eganist and I made to Google and Mozilla a little while back before demoing an HPKP supercookie (https://gi

by buu700 8y ago

This sounds like pretty much the same argument that @eganist and I made to Google and Mozilla a little while back before demoing an HPKP supercookie (https://github.com/cyph/hpkp-supercookie https://github.com/cyph/hpkp-supercookie) at Black Hat and DEF CON. Our position was that doing just about anything less than what Chris did here was essentially lying to users about incognito mode's threat model, but if I recall correctly both teams viewed other security tradeoffs (such as carrying over HPKP and HSTS state) as worth considering infringing on incognito's stated purpose. In the end they did both follow our suggested mitigation for the HPKP issue (before Google turned around and deprecated HPKP out of nowhere ಠ_ಠ), but it isn't surprising to hear that similar issues may still exist.

tialaramex 8y ago
Do you really feel that deprecation of the HPKP self-ransoming foot gun came out of nowhere?
- buu700 8y ago
  Well, the timing wasn't 100% random since the newly supported Expect-CT header was HPKP's "replacement", but I do think three years is a ridiculously small turnaround time between initially adding support for the feature and killing it with low adoption as a stated reason. I'd also say the footgun aspects of HPKP are a weak excuse to kill it, given that nothing really new about them has been discovered that wasn't acknowledged as a consideration in the original spec. If anything, I think it would've made more sense to improve the UX for both end users and admins/devs to reduce the likelihood of deployment mistakes (better documentation and tooling) and the potential for damage when mistakes did happen (e.g. make HPKP error screens skippable like any other TLS errors).
  - dagenix 8y ago
    > make HPKP error screens skippable like any other TLS errors That largely defeats the point. Almost no one knows what to make of those errors. And just training everyone to ignore them makes HPKP pointless. The problem with HPKP was that it could be used to attack any site on the internet with no way for websites to opt out. Basically, the same problem as with certificate authorities - but worse. Those issues we're know when the spec was written, true. But, it was still a dangerous and extremely difficult to deploy feature. Good riddance.
    - buu700 8y ago
      That largely defeats the point. Almost no one knows what to make of those errors. And just training everyone to ignore them makes HPKP pointless. How so? Are you suggesting that TLS as a whole is pointless because browsers allow users to skip the error screens ("Proceed to balls.com (unsafe)")? Even if the error screen is skippable, it makes it clear to the user that something is very wrong and that they're advised to abort their usage of the site. The problem with HPKP was that it could be used to attack any site on the internet with no way for websites to opt out. Basically, the same problem as with certificate authorities - but worse. Definitely agreed on that. (One of our BH/DC demos, RansomPKP, showed that you could actually pivot from a server compromise or MitM to deploying ransomware that would brick an entire domain and hold it hostage until you got paid.) I just think there are much better ways of going about addressing that. Specifically, my proposal to the Chromium team was as follows: 1. Short-term (Chrome 67): Any time dynamic PKP is used, print a console warning that additional requirements are planned to be attached to the use of dynamic PKP with a relevant link. 2. Medium-to-long-term (ecosystem-wide collaboration): Disregard dynamic PKP headers unless the domain in question has some kind of new indicator in the certificate to show that the CA has validated that the site owner is really really sure they want to use HPKP and understands the risks involved (i.e. offload the whitelisting/validation responsibility from individual browser vendors to the broader CA industry). (And I had some other ideas about roping CAA into the mix to address some specific concerns, but it wasn't critical or the meat of the idea.) The response was kind of handwavy — not so much caring about the footgun aspect (i.e. accidental self-bricking and hostile pinning), but more an entirely unrelated concern about the HPKP implementation being hard to maintain for some unspecified reasons. Those issues we're know when the spec was written, true. But, it was still a dangerous and extremely difficult to deploy feature. Good riddance. I hear this repeated a lot, and frankly I think it's nonsense. I just can't see how anyone with a basic knowledge of deploying TLS would be confused about how HPKP works. The idea that only a veteran sysadmin or crypto expert can understand how to use certs, public keys, and hashes just seems really elitist to me. Obviously people have occasionally screwed up in the wild, but in those cases I think the fault lies more in the tooling and documentation than in the existence of the standard itself. Further, if we do collectively feel that everyone's hands need to be held, attaching additional requirements to its usage as in my proposal would neatly accomplish that while minimally imposing on all of us who already depend on HPKP in production.

by buu700 8y ago

tialaramex 8y ago

Do you really feel that deprecation of the HPKP self-ransoming foot gun came out of nowhere?

buu700 8y ago
Well, the timing wasn't 100% random since the newly supported Expect-CT header was HPKP's "replacement", but I do think three years is a ridiculously small turnaround time between initially adding support for the feature and killing it with low adoption as a stated reason. I'd also say the footgun aspects of HPKP are a weak excuse to kill it, given that nothing really new about them has been discovered that wasn't acknowledged as a consideration in the original spec. If anything, I think it would've made more sense to improve the UX for both end users and admins/devs to reduce the likelihood of deployment mistakes (better documentation and tooling) and the potential for damage when mistakes did happen (e.g. make HPKP error screens skippable like any other TLS errors).
- dagenix 8y ago
  > make HPKP error screens skippable like any other TLS errors That largely defeats the point. Almost no one knows what to make of those errors. And just training everyone to ignore them makes HPKP pointless. The problem with HPKP was that it could be used to attack any site on the internet with no way for websites to opt out. Basically, the same problem as with certificate authorities - but worse. Those issues we're know when the spec was written, true. But, it was still a dangerous and extremely difficult to deploy feature. Good riddance.
  - buu700 8y ago
    That largely defeats the point. Almost no one knows what to make of those errors. And just training everyone to ignore them makes HPKP pointless. How so? Are you suggesting that TLS as a whole is pointless because browsers allow users to skip the error screens ("Proceed to balls.com (unsafe)")? Even if the error screen is skippable, it makes it clear to the user that something is very wrong and that they're advised to abort their usage of the site. The problem with HPKP was that it could be used to attack any site on the internet with no way for websites to opt out. Basically, the same problem as with certificate authorities - but worse. Definitely agreed on that. (One of our BH/DC demos, RansomPKP, showed that you could actually pivot from a server compromise or MitM to deploying ransomware that would brick an entire domain and hold it hostage until you got paid.) I just think there are much better ways of going about addressing that. Specifically, my proposal to the Chromium team was as follows: 1. Short-term (Chrome 67): Any time dynamic PKP is used, print a console warning that additional requirements are planned to be attached to the use of dynamic PKP with a relevant link. 2. Medium-to-long-term (ecosystem-wide collaboration): Disregard dynamic PKP headers unless the domain in question has some kind of new indicator in the certificate to show that the CA has validated that the site owner is really really sure they want to use HPKP and understands the risks involved (i.e. offload the whitelisting/validation responsibility from individual browser vendors to the broader CA industry). (And I had some other ideas about roping CAA into the mix to address some specific concerns, but it wasn't critical or the meat of the idea.) The response was kind of handwavy — not so much caring about the footgun aspect (i.e. accidental self-bricking and hostile pinning), but more an entirely unrelated concern about the HPKP implementation being hard to maintain for some unspecified reasons. Those issues we're know when the spec was written, true. But, it was still a dangerous and extremely difficult to deploy feature. Good riddance. I hear this repeated a lot, and frankly I think it's nonsense. I just can't see how anyone with a basic knowledge of deploying TLS would be confused about how HPKP works. The idea that only a veteran sysadmin or crypto expert can understand how to use certs, public keys, and hashes just seems really elitist to me. Obviously people have occasionally screwed up in the wild, but in those cases I think the fault lies more in the tooling and documentation than in the existence of the standard itself. Further, if we do collectively feel that everyone's hands need to be held, attaching additional requirements to its usage as in my proposal would neatly accomplish that while minimally imposing on all of us who already depend on HPKP in production.