New issue
Advanced search Search tips

Issue 612608 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: May 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug-Security



Sign in to add a comment

Invalid HPKP pins are cached

Reported by domi...@rutherfordfamily.co.uk, May 17 2016

Issue description

Steps to reproduce the problem:
1. Visit a website with a correctly formatted, but invalid HPKP header
2. Check cached HPKP information in net-internals
or
3. Attempt to connect to the website again

What is the expected behavior?
If the HPKP header provided by a site is invalid (for example, do not contain a valid hash of one of the site's certificate chain's public keys), then the HPKP header should be ignored - according to https://tools.ietf.org/html/draft-ietf-websec-key-pinning-08#section-2.5 

This prevents a MITM attack from presenting bad HPKP headers and denying future access to the site.

Future visits should not be blocked, and Chrome should not store the key hashes.

What went wrong?
net-internals shows that the invalid header has been cached, and attempts to connect to the website fail (with a security warning).

In my case, attempts to connect to a website failed on Chrome 52 with a security warning. The site had correctly formatted, but invalid, HPKP headers; because the key hashes do not match any of the public keys for the certificate chain.

Did this work before? Yes Chrome 51 on ChromeOS, and Chrome 50 on Android

Chrome version: 52.0.2735.0  Channel: dev
OS Version: 6.0.1
Flash Version:
 

Comment 1 by est...@chromium.org, May 17 2016

Components: Internals>Network>SSL
Hm... we definitely have code that intends to throw out HPKP headers for which the current connection doesn't match the pins: https://code.google.com/p/chromium/codesearch#chromium/src/net/http/http_security_headers.cc&sq=package:chromium&l=86&rcl=1463498288 (and a unit test for it: https://code.google.com/p/chromium/codesearch#chromium/src/net/http/http_security_headers_unittest.cc&sq=package:chromium&l=888)

Do you happen to have a site somewhere that we can access that demonstrates this? Also, did this only reproduce on Android?
My error - disregard this bug report.

It turns out that the website on which I got this inconsistent behaviour had recently changed the cert chain.

I must have browsed to the website using Chrome 52, but not Chrome 51/50, and picked up the HPKP pins at a time when they were valid; so the behaviour on subsequent visits was correct.

On clearing the HSTS/HPKP cache for the site, it loaded as expected in Chrome 52, and did not cache the invalid headers.

Comment 3 by est...@chromium.org, May 18 2016

Labels: -Restrict-View-SecurityTeam
Status: WontFix (was: Unconfirmed)
Ok, no problem, thanks for the report!
Project Member

Comment 4 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 5 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