Testing HPKP support

[Hanno Böck]

Hi,

I have an issue here that confuses me when trying to test the
availability of HPKP. On some (but not all) Linux systems the test
fails both in chromium and firefox.

The test has this basic idea:
* I have a host that sends an HPKP header with two pins, one for the
key that is used in the host's cert and one that is a backup key that
is not used at all. I also set the "includeSubdomains" parameter.
* Then an image is included from a sudomain of the host that has a
different certificate with a different key. So the HPKP check should
fail and the image shouldn't be loaded.
The test in this form is currently here:
https://superfish.tlsfun.de/mitm.php

Here is another test by someone else, I think it works (and fails) the
same way:
https://projects.dm.id.lv/Public-Key-Pins_test


Now the problem: I got reports that on some systems the test fails with
browsers that clearly should support it. I have an Arch Linux VM with a
chromium 40.0.2214.115 build and a firefox 36. In both the test fails.
On my own system (Gentoo, chromium 41.0.2272.64, firefox 36) the test
works as expected.

My first thought was that this might be some kind of race condition.
That the image may get loaded before the pin is processed. However this
seems not to be the case. I have a more manual test setup on
https://pin.tlsfun.de/

There I don't include an element from the subdomain, instead I just
link to it. (Although I could still imagine some kind of race condition
if there is some URL prefetching involved, but I think that's
unlikely.) Even if I restart chromium and directly call the subdomain
with the non-pinned key it loads while it shouldn't.

I looked in chrome://net-internals/hsts and the pins seem to be
recognized correctly. So I can't make any sense out of this.


So my questions:
* What's going on here? Why does this test work sometimes and sometimes
not?
* Is this strategy (setting up a domain with hpkp and loading an object
from a subdomain with a non-pinned-key) a legit strategy to test
HPKP? Or can people think of other ways HPKP could be tested in a
reliable way?

cu,
--
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42

[Chris Bentzel]

+net-dev

[Ryan Sleevi]

No. It isn't a reliable way. The same as it is not a reliable way to test HSTS.

The problem is that it assumes a linear connection strategy of an HTTP/1.0 world. That is, that a UA makes a singular connection to a host, performs a full HTTP request, disconnects, (evaluates HSTS policy), creates a new socket, performs a TLS handshake, (evaluates HPKP policy), makes a HTTP request.

That is a simplified model, and, if you're using a very basic command-line tool, how it might behave.

But that is not how browsers behave or have behaved for some time.

- The browser may preconnect sockets
   - As you're typing in the location bar
   - As soon as it sees the host as a target for a link element in a page
   - As soon as you attempt to load the page (e.g. it may create multiple sockets just in case)

- The browser may reuse connections
  - Such as with HTTP keep alive
  - Such as with HTTP/2 connection pooling

- The browser may have cached the sub resource (I suspect this is why it persists even after restart)

In any event, attaching a chrome://net-internals log to a new bug that you file can help isolate further.

[Gorillaultra]

Same problem here: I loaded https://superfish.tlsfun.de/style.css first and https://mitm.superfish.tlsfun.de/style.css second.

[Ryan Sleevi]

As mentioned in my previously reply, bug reports are the best way to
diagnose bugs.

Cheers