<story><title>Public Key Pinning Being Removed from Chrome</title><url>https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ?hn</url></story><parent_chain></parent_chain><comment><author>buu700</author><text>I can&amp;#x27;t support this at all, and ironically this is partially my fault.&lt;p&gt;My and @eganist&amp;#x27;s Black Hat &amp;#x2F; DEF CON talk &amp;quot;Abusing Bleeding Edge Web Standards for AppSec Glory&amp;quot; demoed an exploit concept that we called &amp;quot;RansomPKP&amp;quot;, 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&amp;#x27; HPKP implementations.&lt;p&gt;However, this talk also led to concerns being vocalized about the viability of HPKP in general (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=12434585&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;news.ycombinator.com&amp;#x2F;item?id=12434585&lt;/a&gt;), ultimately leading to this. This was not our intention at all, and I don&amp;#x27;t see hostile pinning alone as a reason to give up on HPKP.&lt;p&gt;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&amp;#x27;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?</text></comment>
<story><title>Public Key Pinning Being Removed from Chrome</title><url>https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ?hn</url></story><parent_chain></parent_chain><comment><author>pfg</author><text>Removing dynamic pins was inevitable given the associated risk for &lt;i&gt;all&lt;/i&gt; sites. Some ideas to fix those exist[1], but I&amp;#x27;m not sure it&amp;#x27;s worth the effort in a fully CT-enforced web. That&amp;#x27;s probably time better spent somewhere else (such as improving CT itself and the gossip mechanism.)&lt;p&gt;I&amp;#x27;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&amp;#x27;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).&lt;p&gt;[1]: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;blog.qualys.com&amp;#x2F;ssllabs&amp;#x2F;2017&amp;#x2F;09&amp;#x2F;05&amp;#x2F;fixing-hpkp-with-pin-revocation&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;blog.qualys.com&amp;#x2F;ssllabs&amp;#x2F;2017&amp;#x2F;09&amp;#x2F;05&amp;#x2F;fixing-hpkp-with-...&lt;/a&gt;</text></comment>