enable pinning on accounts.firefox.com

RESOLVED FIXED in mozilla33

Status

()

RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: mmc, Assigned: mmc)

Tracking

unspecified
mozilla33
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

Comment hidden (empty)
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
Blocks: 1005430
Flags: needinfo?(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.
Flags: needinfo?(ckarlof) → needinfo?(ckolos)
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?
Flags: needinfo?(ckolos) → needinfo?(ckarlof)
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.
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.
Flags: needinfo?(ckarlof)
Flags: needinfo?(ckolos)
Created attachment 8435985 [details] [diff] [review]
Enable pinning in test mode for accounts.firefox.com (
Assignee: nobody → mmc
Status: NEW → ASSIGNED
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.
Attachment #8435985 - Flags: review?(dkeeler)
: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.
Flags: needinfo?(ckolos)
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.
Attachment #8435985 - Flags: review?(dkeeler) → review+
> 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
Keywords: leave-open
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?
Flags: needinfo?(mmc)
(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.
Flags: needinfo?(mmc)
When we land this for reals (non-testing-mode), let's close https://github.com/mozilla/fxa-content-server/issues/1204 too.
Should we include the bugs for Loop and MSISDN here or file another one?
See the host names mentioned in bug 1020899.
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.
Depends on: 1033872
Created attachment 8455537 [details] [diff] [review]
Enable production mode for fxa (
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.
Attachment #8455537 - Flags: review?(dkeeler)
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.
Attachment #8455537 - Flags: review?(dkeeler) → review+
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.
Oh, right. Good call. Looks like this is good to go, then.
Monica, Frederik -- Is this needed for v2.0?
Flags: needinfo?(mmc)
Flags: needinfo?(fbraun)
Pinning is only enabled on desktop, so if that refers to b2g, definitely not.
Flags: needinfo?(mmc)
(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!
(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?
Flags: needinfo?(fbraun)
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Keywords: leave-open
Target Milestone: --- → mozilla33
You need to log in before you can comment on or make changes to this bug.