1020485 - enable pinning on accounts.firefox.com

Status: RESOLVED FIXED

(Core :: Security: PSM, defect)

Comment 1

[[:mmc] Monica Chew (no longer reading bugmail)]

ckarlof, please redirect this bug to people who know what SSL certificates are being used for FxA domains. The mozilla pinset is currently root certificates whose nicknames are here: http://mxr.mozilla.org/mozilla-central/source/security/manager/tools/PreloadedHPKPins.json#57

Comment 2

[Chris Karlof [:ckarlof]]

:ckolos, can you help here? We want to commit to cert pinning for FxA domains. I understand that IT actually manages our certs, not since svc ops manages accouhts.firefox.com, I think it's appropriate for svc ops to jointly (with the FxA team) take responsibility for this. On the FxA side, Brian Warner will be taking responsibility for this.

Comment 3

[Chris Kolosiwsky [:ckolos] (ckolos has left the building)]

At the risk of sounding completely ignorant, I'm not clear on what's actually being requested here. 

:ckarlof, can you give me some more detail?

Comment 4

[Chris Kolosiwsky [:ckolos] (ckolos has left the building)]

Actually, if I (and wikipedia, stackoverflow, and google) am correct, I think you want to know if we using a cert listed in that .json. We are. Our certs are signed by the DigiCert Global Root CA.

Comment 5

[[:mmc] Monica Chew (no longer reading bugmail)]

Thanks ckolos. Could you please take a look at https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning/SiteOperators and see if your group can consent to follow this process? Basically, if you change your CA issuer, we need 14 weeks notice. This also applies if you decide to outsource some of your content to a CDN or something, and they require a change.

If this process makes sense to you, we will enable pinning in test mode (count pin violations only, don't enforce) on accounts.firefox.com. Then if the numbers look good, we can start enforcing pin violations.

Comment 6

[[:mmc] Monica Chew (no longer reading bugmail)]

Attachment: Enable pinning in test mode for accounts.firefox.com (

Comment 7

[[:mmc] Monica Chew (no longer reading bugmail)]

Comment on attachment 8435985 [details] [diff] [review]
Enable pinning in test mode for accounts.firefox.com (

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

I believe this domain is the same category as AMO because it's critical to the operation of functionality that's supported in browser chrome, yet users can choose to visit it in the location bar, so I set a bucket id.

Comment 8

[Chris Kolosiwsky [:ckolos] (ckolos has left the building)]

:mmc I don't think that will be a problem. Current cert for accounts isn't set to expire until 2017 and we don't switch issuers lightly. I'll make a note of this on our internal docs/wiki.

Comment 9

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Comment on attachment 8435985 [details] [diff] [review]
Enable pinning in test mode for accounts.firefox.com (

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

Looks great. It would be good to make sure that subdomains of accounts.firefox.com also only use that DigiCert root.

::: security/manager/tools/PreloadedHPKPins.json
@@ +79,5 @@
>      },
> +    {
> +      "name": "mozilla_fxa",
> +      "sha256_hashes": [
> +        "DigiCert Global Root CA"

Is there a possibility that DigiCert will re-issue a accounts.firefox.com certificate with a different DigiCert root? I guess we would know if that happened, but it would be nice not to chemspill if it was on short notice.

Comment 10

[[:mmc] Monica Chew (no longer reading bugmail)]

> In reply to David Keeler (:keeler) [use needinfo?] from comment #9)
> Comment on attachment 8435985 [details] [diff] [review]
> Enable pinning in test mode for accounts.firefox.com (
> 
> Review of attachment 8435985 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks great. It would be good to make sure that subdomains of
> accounts.firefox.com also only use that DigiCert root.

I guess we'll find out in test mode :)

> ::: security/manager/tools/PreloadedHPKPins.json
> @@ +79,5 @@
> >      },
> > +    {
> > +      "name": "mozilla_fxa",
> > +      "sha256_hashes": [
> > +        "DigiCert Global Root CA"
> 
> Is there a possibility that DigiCert will re-issue a accounts.firefox.com
> certificate with a different DigiCert root? I guess we would know if that
> happened, but it would be nice not to chemspill if it was on short notice.

I think ckolos is on it, from comment 8.

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/3761ada3b5d2

Comment 11

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3761ada3b5d2

Comment 12

[Chris Karlof [:ckarlof]]

Comment on attachment 8435985 [details] [diff] [review]
Enable pinning in test mode for accounts.firefox.com (

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

::: security/manager/boot/src/StaticHPKPins.h
@@ +669,5 @@
>  };
>  
>  /* Sort hostnames for binary search. */
>  static const TransportSecurityPreload kPublicKeyPinningPreloadList[] = {
> +  { "accounts.firefox.com", true, true, false, 4, &kPinset_mozilla_fxa },

I'm confused by how these flags are set. Is it correct that mIsMoz is false, but it has a mId > -1?

Comment 13

[[:mmc] Monica Chew (no longer reading bugmail)]

(In reply to Chris Karlof [:ckarlof] from comment #12)
> Comment on attachment 8435985 [details] [diff] [review]
> Enable pinning in test mode for accounts.firefox.com (
> 
> Review of attachment 8435985 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: security/manager/boot/src/StaticHPKPins.h
> @@ +669,5 @@
> >  };
> >  
> >  /* Sort hostnames for binary search. */
> >  static const TransportSecurityPreload kPublicKeyPinningPreloadList[] = {
> > +  { "accounts.firefox.com", true, true, false, 4, &kPinset_mozilla_fxa },
> 
> I'm confused by how these flags are set. Is it correct that mIsMoz is false,
> but it has a mId > -1?

Yes. mIsMoz is for mozilla hosts for which we don't collect per-host pinning violations, so it should be false. mId != -1 means we count per-host pinning volumes/violations in histogram CERT_PINNING_MOZ_TEST_RESULTS_BY_HOST (http://people.mozilla.org/~mchew/pinning_dashboard). We deliberately don't double-count hosts for which we have per-host violations to keep our stats cleaner.

It's too early for this data to show up, because it takes telemetry 2 days from build date to reach the dashboards, and the earliest build date for which we will have data is 6/8.

Comment 14

[Brian Warner [:warner :bwarner]]

When we land this for reals (non-testing-mode), let's close https://github.com/mozilla/fxa-content-server/issues/1204 too.

Comment 15

[Frederik Braun [:freddy]]

Should we include the bugs for Loop and MSISDN here or file another one?
See the host names mentioned in bug 1020899.

Comment 16

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Are Loop and MSISDN their own projects or are they part of firefox accounts? If the former, they should probably be tracked in their own bugs.

Comment 17

[[:mmc] Monica Chew (no longer reading bugmail)]

Attachment: Enable production mode for fxa (

Comment 18

[[:mmc] Monica Chew (no longer reading bugmail)]

Comment on attachment 8455537 [details] [diff] [review]
Enable production mode for fxa (

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

Errors are on api.accounts.firefox.com, most likely due to background sync at startup. None of the other pinned domains have this property, so I think a higher level of breakage is to be expected.

Comment 19

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Comment on attachment 8455537 [details] [diff] [review]
Enable production mode for fxa (

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

Looks good to me. One thing it would be good to check is if Firefox Accounts works correctly even if that initial request fails.

Comment 20

[[:mmc] Monica Chew (no longer reading bugmail)]

The background sync will fail until captive portal (or whatever) is cleared. I think these would be failing anyway, since the user already isn't talking to the right service.

Comment 21

[Dana Keeler (she/her) (use needinfo) [:keeler]]

Oh, right. Good call. Looks like this is good to go, then.

Comment 22

[[:mmc] Monica Chew (no longer reading bugmail)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/e5b0fa65110a

Comment 23

[Maire Reavy [:mreavy]]

Monica, Frederik -- Is this needed for v2.0?

Comment 24

[[:mmc] Monica Chew (no longer reading bugmail)]

Pinning is only enabled on desktop, so if that refers to b2g, definitely not.

Comment 25

[Maire Reavy [:mreavy]]

(In reply to [:mmc] Monica Chew (please use needinfo) from comment #24)
> Pinning is only enabled on desktop, so if that refers to b2g, definitely not.

v2.0 is the next b2g release which is going FC (Feature Complete) on Friday and is based on Fx 32.  So if we had needed this for B2G, the deadline for landing & uplifting patches would be basically now (this week).  That's why I wanted to check.  Thanks!

Comment 26

[Frederik Braun [:freddy]]

(In reply to [:mmc] Monica Chew (please use needinfo) from comment #24)
> Pinning is only enabled on desktop, so if that refers to b2g, definitely not.

What's the roadmap for getting this into b2g?

Comment 27

[[:mmc] Monica Chew (no longer reading bugmail)]

This does not make sense to get into b2g unless we have a way to dynamically update the pinning list without baking it into the build. That means https://bugzilla.mozilla.org/show_bug.cgi?id=787133 or some other solution.

Comment 28

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/e5b0fa65110a