Built-in pins expires decades later.

RESOLVED FIXED in Firefox 34

Status

()

Core
Security: PSM
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: cviecco, Assigned: cviecco)

Tracking

unspecified
mozilla35
Points:
---

Firefox Tracking Flags

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

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

3 years ago
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.
(Assignee)

Updated

3 years ago
Summary: Built-in pins never decades later. → Built-in pins expires decades later.
(Assignee)

Updated

3 years ago
Assignee: nobody → cviecco
(Assignee)

Updated

3 years ago
Blocks: 787133
(Assignee)

Comment 1

3 years ago
Created attachment 8489643 [details] [diff] [review]
fix-expiration-pins
(Assignee)

Comment 2

3 years ago
Created attachment 8489644 [details] [diff] [review]
fix-expiration-pins (v1)
Attachment #8489643 - Attachment is obsolete: true
(Assignee)

Updated

3 years ago
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+
(Assignee)

Comment 5

3 years ago
Created attachment 8489668 [details] [diff] [review]
fix-expiration-pins (v1.1)

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+
(Assignee)

Updated

3 years ago
status-firefox34: --- → affected
status-firefox35: --- → affected
https://hg.mozilla.org/mozilla-central/rev/de47d4022beb
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
(Assignee)

Comment 9

3 years ago
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+
status-firefox32: --- → unaffected
status-firefox33: --- → unaffected
status-firefox35: affected → fixed
status-firefox34: affected → fixed
You need to log in before you can comment on or make changes to this bug.