Re: [websec] #57: Re-add an upper limit to max-age

[Yoav Nir <[e-mail]>]

On Mar 29, 2013, at 5:15 PM, Ryan Sleevi <[e-mail]> wrote:

> On Fri, Mar 29, 2013 at 10:45 AM, Joseph Bonneau <[e-mail]> wrote:
>>> Hopefully, it's not just Google that implements this. I guess any browser that implements this will have some kind of reset button (like they have for other stuff) that will erase all pins. So the site is not really bricked, but still it's pretty embarrassing to have to have a message on their home page like "Chrome for Mac OS X users of foo.com, due to an administrative error, please select the 'Clear Browsing Data…' menu item from the Chrome menu, select 'the beginning of time' from the dropdown menu, and check the 'dynamic public key pins' box. Then click 'Clear browsing data'. Sorry for the inconvenience."
>> 
>> Perhaps we have a different working definition of "bricked"? By
>> bricked, I meant that HPKP pins were set which the site no longer has
>> the ability to satisfy, period. There are many ways that this could
>> happen-pinning to two end-entity keys and losing the private keys,
>> attempting to pin to a CA key but entering the hash incorrectly, and
>> still having the pins accepted since the end-entity key pin is valid,
>> or a malicious bricking with a mis-issued certificate. In this case, a
>> bricked domain would be unable to show anything at all to users, so
>> they couldn't ask users to hit a "reset pins" button as you suggest.
>> Some users might figure it out through an alternate channel like
>> Googling "why is foo.com down??", but it would be awful to train users
>> to ever follow advice to nuke their local state like that.
> 
> So, certainly, as discussed during past meetings, and similar to the
> discussions of HSTS, HPKP represents potential privacy bits being
> disclosed to an attacker ("Have you been here before, and if so,
> when/under what keys?"). As such, it's natural to assume/expect that
> browsers will have a way to clear received dynamic pins, as part of
> the normal clearing of privacy state-related data.
> 
> However, sites / site operators encouraging users to do so would be
> bad for users' security - it would essentially flush their pins,
> allowing potentially misissued certs to be used. If I was a 'clever'
> attacker, and I had the ability to display such messages, then in the
> face of being unable to attack a pinned site, I would look for a
> popular-but-not-pinned site and deliberately inject bad pins (DoS'ing
> the site from the users' perspective), along with some sort of message
> of "Hey, clear your pins for this site to work"
> 
> Once the user cleared their pins, I would be able to attack the target
> site, which would now be unpinned.
> 
> Alternative models (such as temporarily ignoring pins) sort of flies
> in the face of our experiences with HSTS and the general
> browser/usability issues with bypassing warnings. Clearing on a
> per-site basis is the same as a bypass mode, and then we're just
> talking about the number of clicks to get there - also a poor security
> experience.

All true, but if I want to delete my pins, I will, even if I have to search the Internet (using Google, of course) for how to edit the pins on Chrome. I only hope that instructing your users to do this will be enough of a "doghouse" for site operators. As it is, expired certs and chains that don't chain are becoming more and more rare. The power of embarrassment seems to be working there, even though there is a click-through option.

Getting back to the subject of the thread, I still don't see the difference for a site operator between being bricked for 60 days and being bricked for a year. For an only retailer it's catastrophe either way.

Yoav