Built-in pins expires decades later.

RESOLVED FIXED in Firefox 34

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: cviecco, Assigned: cviecco)

Tracking

unspecified
mozilla35
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox32 unaffected, firefox33 unaffected, firefox34 fixed, firefox35 fixed)

Details

Attachments

(1 attachment, 2 obsolete attachments)

Within
PublicKeyPinning service we have:
  if (time > TimeFromElapsedSecondsAD(kPreloadPKPinsExpirationTime)) {
    return true;
  }
which was changed in bug 1043041 from (change PRTime to mozilla::pkix::Time)

if (time > kPreloadPKPinsExpirationTime) .

Now, kPreloadPKPinsExpirationTime is computed as the number of microseconds since the epoch.  Not the number of seconds since AD.
Summary: Built-in pins never decades later. → Built-in pins expires decades later.
Assignee: nobody → cviecco
Blocks: hpkp
Posted patch fix-expiration-pins (obsolete) — Splinter Review
Posted patch fix-expiration-pins (v1) (obsolete) — Splinter Review
Attachment #8489643 - Attachment is obsolete: true
Attachment #8489644 - Flags: review?(dkeeler)
Comment on attachment 8489644 [details] [diff] [review]
fix-expiration-pins (v1)

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

great - r=me with nits.

::: security/pkix/include/pkix/Time.h
@@ +117,5 @@
>  }
>  
>  Time Now();
>  
> +Time TimeFromEpochInSeconds(uint64_t secondsSinceEpoch);

nit: document that this is the unix epoch (i.e. 00:00:00 UTC, 1 January 1970)

::: security/pkix/lib/pkixtime.cpp
@@ +59,5 @@
>    return TimeFromElapsedSecondsAD(seconds);
>  }
>  
> +Time
> +TimeFromEpochInSeconds(uint64_t secondsSinceEpoch)

This is probably short enough to be inline

@@ +62,5 @@
> +Time
> +TimeFromEpochInSeconds(uint64_t secondsSinceEpoch)
> +{
> +  uint64_t seconds;
> +  seconds = (DaysBeforeYear(1970) * Time::ONE_DAY_IN_SECONDS) +

nit: how about 'uint64_t seconds = ...' all on one line? (I imagine the secondsSinceEpoch will still have to wrap)

@@ +64,5 @@
> +{
> +  uint64_t seconds;
> +  seconds = (DaysBeforeYear(1970) * Time::ONE_DAY_IN_SECONDS) +
> +            secondsSinceEpoch;
> +  return  TimeFromElapsedSecondsAD(seconds);

nit: unnecessary extra space after return
Attachment #8489644 - Flags: review?(dkeeler) → review+
Keeping r+ from keeler. Adding all its comments except making the call inline as it produces compilation failures.
Attachment #8489644 - Attachment is obsolete: true
Attachment #8489668 - Flags: review+
https://hg.mozilla.org/mozilla-central/rev/de47d4022beb
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Comment on attachment 8489668 [details] [diff] [review]
fix-expiration-pins (v1.1)

Approval Request Comment
[Feature/regressing bug #]: 1043041 (Replace PRTime inside mozilla::pkix) 
[User impact if declined]: Built-in pins will expire several decades from now resulting in a DoS when that happens or when the domains pinned change their Ca.
[Describe test coverage new/current, TBPL]: Uses the same coverage, no extra test possible for future time currently.
[Risks and why]: Might break HPKP sooner than expected. It is required for HPKP which is required for Trusted aPPS
[String/UUID change made/needed]: None
Attachment #8489668 - Flags: approval-mozilla-aurora?
Comment on attachment 8489668 [details] [diff] [review]
fix-expiration-pins (v1.1)

I don't think we're going to get much benefit from baking this on m-c. Aurora+
Attachment #8489668 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.