HTTPS Public Key Pinning HPKP

[mozfreddyb]

Would be great if badssl had a test for HPKP voilations.

[lgarron]

Before I forget: we should have a preloaded pinning violation like https://pinningtest.appspot.com/

[lgarron]

https://pinning-test.badssl.com should trigger a pinning failure in tomorrow's Chrome Canary: https://codereview.chromium.org/1413513003

[lgarron]

Whee!

[april]

Looks nice, now go to bed!

[rugk]

Nice, but you should not write: This site is preloaded with a bad HPKP pin starting in Chrome 48
Because HPKP is a name for the "dynamic pinning".
So probably "preloaded key pinning" would be a better name to differentiate this.

---

BTW could you also open an issue for inclusion of this key pin in Firefox?

[lgarron]

Because HPKP is a name for the "dynamic pinning".

I prefer to use HSTS and HPKP consistently to make them more recognizable.

As far as I understand, preloaded HPKP is still key pinning for HTTP – it just wasn't served using an HTTP header. (Whereas the "H" distinguishes this mechanism from, say, the SSH known_hosts mechanism.)

Your link and the spec are unclear on this; the most relevant information I can find is a suggestive description of it as trust on first use. But I'd like to get it right; do you know of a good citation for it?

BTW could you also open an issue for inclusion of this key pin in Firefox?

Will do.

[lgarron]

BTW could you also open an issue for inclusion of this key pin in Firefox?

Will do.

Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1218515

[jkldgoefgkljefogeg]

I got no warning on Chromium 48.0.2564.116 (Developer Build) Ubuntu 15.10 (64-bit) and Firefox 44.0.2

[lgarron]

I got no warning on Chromium 48.0.2564.116 (Developer Build) Ubuntu 15.10 (64-bit) and Firefox 44.0.2

Chromium developer builds don't have HPKP enabled. Did you build this yourself?

[jkldgoefgkljefogeg]

I got the warning on 49.0.2623.64 (Official Build) beta-m (64-bit) Windows x64.

but not on 48.0.2564.116-0ubuntu0.15.10.1.1221 0 from Ubuntu wily

[timmc]

Same result here, no warning on Chromium Version 53.0.2785.89 Built on 8.5, running on Debian 8.5 (64-bit). This is true on my work computer as well. Additionally, a coworker verified that Google Chrome on Linux did block access. Maybe Debian packages it weird?

(I also don't see a warning on Firefox ESR 45.3.0, and I thought the pin went into v44.)

Should I open a separate issue?

[lgarron]

Should I open a separate issue?

No, this is expected behaviour.
Non-official builds disable static key pinning data, to avoid stale entries whose updates are not controlled by Google.

[timmc]

Maybe worth a note, then, that the static test is only valid for Google Chrome.

[timmc]

Ah... and my Firefox ESR 45 probably "fails" the test because the static pins have expired! Yeah, I think some of these tests need a special marker indicating that they only work for some browser/version/build combinations and are not expected to work across the board.

[lgarron]

tests need a special marker

This is not a bad idea, and we are working on improving the descriptions (#202).

However, this behaviour is known to most people who use badssl.com on a regular basis, and it's not quite our goal to cater to every use case, so I don't consider this a high priority right now.

Could you let us know more about your use case?

[timmc]

Well, the tagline of the repo is "Memorable site for testing clients against bad SSL configs." so I assumed it was for broader use than just on the official vendor-built binaries. When I found that neither of Chromium 53 or Firefox ESR 45 "passed" the pinning test I was all set to file bugs, then found this thread. So I think there's a lot of value in noting which tests are broadly applicable (e.g. no browser should accept expired certs) vs. specific to a particular set of builds (e.g. preloaded HPKP).

[lgarron]

When I found that neither of Chromium 53 or Firefox ESR 45 "passed" the pinning test I was all set to file bugs, then found this thread.

So you were testing for HPKP support in your Chromium/Firefox installs? Sounds like a reasonable case. Could you file a more specific bug, so that you'll be in the loop when we update the language?