New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 561646 link

Starred by 7 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Nov 2015
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Security

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Replace local root store override of HPKP pins with ability to reset HPKP pin

Reported by itisto...@gmail.com, Nov 25 2015

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0

Steps to reproduce the problem:
1. Add root certificate to local store.
2. Use it to sign a cert for an arbitrary website that uses HPKP pins and then use that cert to MITM the connection to the website

What is the expected behavior?
For Chrome to reject the invalid certificate

What went wrong?
Chrome does not reject the cert. See:

https://twitter.com/__apf__/status/668843620204605440
https://twitter.com/sleevi_/status/668911789841608706

Did this work before? N/A 

Chrome version: 46.0.2490.86  Channel: stable
OS Version: OS X 10.11
Flash Version: Not important
 

Comment 1 by palmer@chromium.org, Nov 25 2015

Cc: rsleevi@chromium.org f...@chromium.org
Labels: -Restrict-View-SecurityTeam -OS-Mac os-all Cr-Internals-Network-SSL Cr-Security
Status: WontFix
This is working as intended. See https://www.chromium.org/Home/chromium-security/security-faq#TOC-How-does-key-pinning-interact-with-local-proxies-and-filters-.

Anyone who can add trust anchors to the local store already fully controls the machine (or at least the user account, if adding to a user-level trust anchor store). So, it's not really an 'attack', and there is no vulnerability here.

It may be that people use machines they don't own, and they don't like the owner's configuration of the machine. Well, that's a social problem, and not something that anyone can fix in application code.

Comment 2 by itisto...@gmail.com, Nov 25 2015

I've read that link already.

This is an attack, and Dell just used it to compromise several hundred thousand people.

Why are you purposefully allowing local roots to override HPKP?

There is zero reason for that. This is literally undermining the point of pinning certificates.

Comment 3 by co...@colin.net.pl, Nov 25 2015

I think that it would be a good idea to add a parameter that disables the special treatment of private trust anchors, for example:
   Public-Key-Pins: max-age=2592000;
       pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
       pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=";
       strict

I believe that nobody, including enterprise IT administrators, should be allowed to see what people are doing on my website. Sometimes it's better to display an HPKP error message than to successfully connect through a known MITM appliance.

Comment 4 by chrisb...@gmail.com, Nov 25 2015

The logic of "well, if someone's attacking you and controls the machine, they can do anything at all" works if the only people making users vulnerable to untrustworthy local store CAs are determined attackers.

But in the Dell case, it seems that they were not intentional attackers.  They wanted something unrelated to being able to hijack CA trust, but since adding to the trust store is super easy, they did that, not understanding the consequences.  They were accidental attackers, by their account.

It seems worthwhile to prevent such unintentional attacks.  The fact that it won't prevent true adversaries doesn't seem like a good reason to avoid a change that *statistically* seems like it has excellent expected return on user safety in the real world.

Comment 5 by palmer@chromium.org, Nov 25 2015

First, note that we did push out a CRLSet update that blacklists the 2 Dell keys.

Second, please note that key pinning works quite well on a client that is not already compromised — which is all we can ever hope for.

Applications must trust the platform they run on. If the platform is working against the device owner's desired security goals, or if the device owner is working against the people who use the device, that's not a problem I can fix in C++ code.


Our purpose in designing key pinning was not to prevent client device owners from exerting their desired policy on the device they own. That would be impossible in any case. And, I hope everyone agrees, undesirable.

We documented this in Section 2.6 of RFC 7469: https://tools.ietf.org/html/rfc7469#section-2.6

Our purpose in designing key pinning was not to prevent malware on the client device from exerting malicious control. It'd be great if we could, but we can't. It's not possible; that's a job for the operating system and the device's owner.

A userland application cannot distinguish the Dell and Superfish incidents from a policy decision exerted by the device's rightful owner. To application code, they look the same.

That is why, when deliberating over the design in the IETF, we rejected the 'strict' option. (https://www.ietf.org/mail-archive/web/websec/current/msg01942.html)


If we did provide an option for the application to enforce strict pinning, a few bad outcomes would likely result:

* Proxies, both legitimate (owner-intended and -controlled) and illegitimate would simply move to the next stages in the arms race. For example, they'd put their certificates in the system store rather than in the local store; they'd inject threads or DLLs into the application to override its certificate and pin validation routines, and so on. Moving to this next stage is not a large hurdle; indeed, many AV/DLP/et c. products are *already doing it*. It is not technically difficult; there is no defensible security boundary there.

* Then, people would have a false sense of strict Pin Validation: They would believe that the application was doing strict Pin Validation, but in reality it would not be.

* Then, people would be upset that the application promised something it could not really deliver. Even if you feel you know that the option would not be a strong guarantee, some people would perceive it has having been intended as one.


Additional discussion of HPKP's behavior and design goals:

https://noncombatant.org/2015/11/24/what-is-hpkp-for/
https://noncombatant.org/2015/05/01/about-http-public-key-pinning/

Comment 6 by palmer@chromium.org, Nov 25 2015

Cc: palmer@chromium.org

Comment 7 by itisto...@gmail.com, Nov 26 2015

> Our purpose in designing key pinning was not to prevent malware on the client device from exerting malicious control. It'd be great if we could, but we can't. It's not possible

Um, raising your hands up in the air and pretend that there's nothing you can do is simply BS.

Copy/pasting from here: https://blog.okturtles.com/2015/11/dells-tumble-googles-fumble-and-how-government-sabotage-of-internet-security-works/

<begin>

One of the most fundamental principles of information security is reducing the attack surface, meaning that when something is unnecessary and can lead to a vulnerability, it must be removed.

Is anything Google could do to make it more difficult for Dell to compromise their customers? Yes, there is. The most obvious thing would be to not allow roots within the local trust store to override HPKP pins.

Had Google removed the red carpet to disabling all of its safeguards, where would that have left Dell? Sure, they could still compromise Chrome, but there would be no “Google Approved” method of doing so. Dell would either:

1. Have to give up, or:
2. Literally install malware on their computers. Dell’s stock would plummet.

Are there any downsides to the user if Google were to do this? There do not appear to be any. Even “Hostile Pinning” can be addressed with a simple user interface for resetting pins. Other perfectly reasonable suggestions have been made, but they appear to be falling on deaf ears.

</end>

Comment 8 by palmer@chromium.org, Nov 26 2015

Labels: Restrict-AddIssueComment-EditIssue
Project Member

Comment 9 by sheriffbot@chromium.org, Oct 1 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 10 by sheriffbot@chromium.org, Oct 2 2016

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic

Sign in to add a comment