On Fri, Mar 29, 2013 at 10:45 AM, Joseph Bonneau <[email protected]> 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.
>
>>> If there were a max-age of 60 days, would the Chrome team take a hard
>>> line of "Sorry foo.com, you'll just have to wait it out"? Or would
>>> they ship a patch to disables HPKP for foo.com, fearing that otherwise
>>> some users will just switch to another browser to regain access?
>>
>> I don't think any of us like the answer, but this probably depends on who
>> 'foo' is. You don't brick Gmail, Hotmail, Paypal, or any major bank in the
>> US. http://www.brambleberry.com ? I don't see any of the major browser
>> issuing a patch to bail them out.
>
> I'm can live with that answer, though I'd be curious to hear from the
> Chrome developers (who are likely to be the pioneers here). If a
> channel to whitelist misconfigured HPKP domains is going to be built,
> it changes the discussion around max-age limits to be mostly a
> performance optimization and I don't think it's a good security
> tradeoff.
I don't have any answer for this at this time. There are obviously a
set of security trade-offs here.
Do you trust/want your browser vendor to deliver secure pins (aka
pre-loaded pins)?
Do you trust/want your browser vendor to deliver unpins (of dynamic pins)?
The risks and likely responses to the first question are very
different than those of the second.
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
