1180411 - Something expired on esr38, causing pinning test failures

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Description

[Phil Ringnalda (:philor)]

Things were fine on a push on June 30th, but this morning's automated blocklist/HSTS update (https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr38&revision=6fa44d85f33c) failed in the pinning xpcshell and browser-chrome tests. 

To verify that it was the date rather than the content of that push, I retriggered an xpcshell run on the previously good push, and https://treeherder.mozilla.org/#/jobs?repo=mozilla-esr38&revision=56c0c55aec7c&filter-searchStr=3f29983665f9ee76b027addc792257d671910bb3 agrees that it must have been that something expired after June 30th.

Comment 1

[:Cykesiopka]

Attachment: bug1180411_update-StaticHPKPins.h_v1.patch

Here's a patch that seems to fix the issue.

It updates StaticHPKPins.h to refresh the |kPreloadPKPinsExpirationTime| variable, which indeed currently indicates a time in the past.

It also picks up some new Google pinsets (I updated StaticHPKPins.h using genHPKPStaticPins.js).

Try push:
  https://treeherder.mozilla.org/#/jobs?repo=try&revision=e1093ffef058
And because I am dumb and/or TryChooser hates me + the instructions on how to trigger jobs I didn't specify in my Try syntax are scary:
  https://treeherder.mozilla.org/#/jobs?repo=try&revision=89f0d40f13cc

Comment 2

[:Cykesiopka]

According to https://hg.mozilla.org/releases/mozilla-esr38/filelog/6788058fa211/security/manager/boot/src/StaticHPKPins.h, the last time this file was updated was 2015-03-28, which is just before FF 38 moved to beta, if I'm reading https://wiki.mozilla.org/RapidRelease/Calendar correctly.

I'm unsure of what the policy is for updating pinsets, but maybe the HPKP update script just needs to run on esr38 as well?

Comment 3

[Phil Ringnalda (:philor)]

[Tracking Requested - why for this release]:

Someone with a better understanding of the feature will have to help you decide severity (since I didn't know what the acronym stood for until a few minute ago), but the layman's description, "up until 3:18am Pacific today, even if you hadn't yet connected to Facebook or Gmail in a new profile, you couldn't be MiTMed by a forged cert, but after 3:18am you could be" has a whiff of chemspill to me.

Comment 4

[Phil Ringnalda (:philor)]

Though the urgency is considerably moderated by the fact that the only people affected went without this feature from the time it shipped in 32 last August until the first esr38 release shipped.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

(In reply to Cykesiopka from comment #1)
> And because I am dumb and/or TryChooser hates me + the instructions on how
> to trigger jobs I didn't specify in my Try syntax are scary:
>   https://treeherder.mozilla.org/#/jobs?repo=try&revision=89f0d40f13cc

FYI, mozci makes this way easier :)
https://mozilla-ci-tools.readthedocs.org/en/latest/project_definition.html

Comment 6

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 8629619 [details] [diff] [review]
bug1180411_update-StaticHPKPins.h_v1.patch

Review of attachment 8629619 [details] [diff] [review]:
-----------------------------------------------------------------

r+ based on the green Try runs and the patch looking like what we'd expect for such an update. Bug 1180453 tracks getting these updates automated in the future.

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr38/rev/cde800606777

Comment 8

[Daniel Veditz [:dveditz]]

(In reply to Phil Ringnalda (:philor) from comment #3)
> Someone with a better understanding of the feature will have to help you
> decide severity (since I didn't know what the acronym stood for until a few
> minute ago), but the layman's description, "up until 3:18am Pacific today,
> even if you hadn't yet connected to Facebook or Gmail in a new profile, you
> couldn't be MiTMed by a forged cert, but after 3:18am you could be" has a
> whiff of chemspill to me.

It's not great that all the pre-loaded pins expired but no worse than not having the feature at all, and the feature itself is a second-line of defense against an attack performed through compromising a Certificate Authority. Users who have not visited those sites before, but who chose to visit them after July 4 will not be protected on that first visit. That's sad, but not chemspill-worthy.

Comment 9

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Adding a tracking flag, this is already fixed in esr-38.

Comment 10

[Lawrence Mandel [:lmandel] (use needinfo)]

Corrected ESR tracking flag.