3 ms·

I think this has very little to do with you. Hpkp was championed by a lot of security people, who in turn got a lot of people to foot gun themselves (Scott Hel

by ejcx 9y ago

I think this has very little to do with you. Hpkp was championed by a lot of security people, who in turn got a lot of people to foot gun themselves (Scott Helme even admitted that he is oftentimes one of the first people called by people who HPKP foot-gun themselves). There were only a handful of sites that actually needed HPKP level security, and ransom-hpkp was the least of people's worries. Hpkp was more dangerous to people rolling it out on purpose than it was to mass header injection or similar :/ HPKP has been doomed from the beginning. Here is sleevi saying he regrets it in 2/2016: https://twitter.com/sleevi_/status/696171562383224832 https://twitter.com/sleevi_/status/696171562383224832

buu700 9y ago
I agree that RansomPKP itself isn't that big a real-world concern (which was part of my point), but it did motivate the first wide discussions that I'd seen questioning whether HPKP should exist. The linked Qualys blog post / HN thread was shortly after our talk, which (along with our conversation with Scott Helme around that time) led to Scott's post "Using security features to do bad things"[1]. RansomPKP and related follow-ups are directly highlighted by Scott's recent post "I'm giving up on HPKP"[2] in which he announced his decision to remove HPKP from the Security Headers tool[3], and Scott himself is cited in this post by Chris Palmer. Note that I'm not suggesting that Scott himself is responsible for this, or that anything he's said has been in bad faith. My point is simply that my talk was one part of the chain of events that started the ball rolling on this conversation. I'm also not saying that RansomPKP / hostile pinning is the most important reason that people have for not liking HPKP — in this case Chris lists it as only one of three motivations. Clearly, the usability issues with its implementation have been a much bigger problem, which is what I would like to see serious attempts to improve on before throwing out all the work that's been done up until now. --- Edit: re: sleevi edit: the tweet you linked doesn't say anything about regretting the concept of TLS key pinning entirely, just that it's done as a header. I'll admit it's ambiguous, but that sounds to me like he would rather have kept the feature but changed the API. I would be all for deprecating the HPKP header if it were replaced with a better / more usable interface to the feature. --- 1: https://scotthelme.co.uk/using-security-features-to-do-bad-things https://scotthelme.co.uk/using-security-features-to-do-bad-t... 2: https://scotthelme.co.uk/im-giving-up-on-hpkp https://scotthelme.co.uk/im-giving-up-on-hpkp 3: https://securityheaders.io https://securityheaders.io
- ejcx 9y ago
  I will be VERY upfront that I DO blame Scott Helme for this. I mentioned this in 2/2016 as well[0] It's fair. There was a lot of buzz about Ransom HPKP. The whole thing was doomed from the start, and I was pretty upset every time I saw anyone publicly push for it. 0: https://twitter.com/ejcx_/status/698227927390023681 https://twitter.com/ejcx_/status/698227927390023681
  - buu700 9y ago
    Huh, well that's an interesting point. I don't know exactly how popular Security Headers is, but given that it's at least partially targeted at novices, I can see how this backlash might have been avoided if HPKP had been omitted there from the start.
    - eganist 9y ago
      Well in fairness, our talk probably wouldn't have been accepted by either Black Hat or DEF CON if we omitted RansomPKP. Or any of the HPKP suicide stuff.
  - eganist 9y ago
    I worked with Scott on the HPKP components of that initial blog post (I'm sure he can confirm) and I won't blame him at all for what took place in hindsight. Google actually denied a bounty on disclosures surrounding RansomPKP, so there was nothing to suggest this was the path they would eventually follow.
    - ejcx 9y ago
      Again, I think this decision has nothing to do with Ransom HPKP and everything to do with how it's not a usable standard, and people who try to use it correctly fail.

by ejcx 9y ago

buu700 9y ago

I agree that RansomPKP itself isn't that big a real-world concern (which was part of my point), but it did motivate the first wide discussions that I'd seen questioning whether HPKP should exist. The linked Qualys blog post / HN thread was shortly after our talk, which (along with our conversation with Scott Helme around that time) led to Scott's post "Using security features to do bad things"[1]. RansomPKP and related follow-ups are directly highlighted by Scott's recent post "I'm giving up on HPKP"[2] in which he announced his decision to remove HPKP from the Security Headers tool[3], and Scott himself is cited in this post by Chris Palmer. Note that I'm not suggesting that Scott himself is responsible for this, or that anything he's said has been in bad faith. My point is simply that my talk was one part of the chain of events that started the ball rolling on this conversation. I'm also not saying that RansomPKP / hostile pinning is the most important reason that people have for not liking HPKP — in this case Chris lists it as only one of three motivations. Clearly, the usability issues with its implementation have been a much bigger problem, which is what I would like to see serious attempts to improve on before throwing out all the work that's been done up until now. --- Edit: re: sleevi edit: the tweet you linked doesn't say anything about regretting the concept of TLS key pinning entirely, just that it's done as a header. I'll admit it's ambiguous, but that sounds to me like he would rather have kept the feature but changed the API. I would be all for deprecating the HPKP header if it were replaced with a better / more usable interface to the feature. --- 1: https://scotthelme.co.uk/using-security-features-to-do-bad-things https://scotthelme.co.uk/using-security-features-to-do-bad-t... 2: https://scotthelme.co.uk/im-giving-up-on-hpkp https://scotthelme.co.uk/im-giving-up-on-hpkp 3: https://securityheaders.io https://securityheaders.io

ejcx 9y ago
I will be VERY upfront that I DO blame Scott Helme for this. I mentioned this in 2/2016 as well[0] It's fair. There was a lot of buzz about Ransom HPKP. The whole thing was doomed from the start, and I was pretty upset every time I saw anyone publicly push for it. 0: https://twitter.com/ejcx_/status/698227927390023681 https://twitter.com/ejcx_/status/698227927390023681
- buu700 9y ago
  Huh, well that's an interesting point. I don't know exactly how popular Security Headers is, but given that it's at least partially targeted at novices, I can see how this backlash might have been avoided if HPKP had been omitted there from the start.
  - eganist 9y ago
    Well in fairness, our talk probably wouldn't have been accepted by either Black Hat or DEF CON if we omitted RansomPKP. Or any of the HPKP suicide stuff.
- eganist 9y ago
  I worked with Scott on the HPKP components of that initial blog post (I'm sure he can confirm) and I won't blame him at all for what took place in hindsight. Google actually denied a bounty on disclosures surrounding RansomPKP, so there was nothing to suggest this was the path they would eventually follow.
  - ejcx 9y ago
    Again, I think this decision has nothing to do with Ransom HPKP and everything to do with how it's not a usable standard, and people who try to use it correctly fail.