aus3 and aus4.mozilla.org.

Comment on attachment 8484484 [details] [diff] [review] Enable pinning on the updater (aus3 and aus4) ( Review of attachment 8484484 [details] [diff] [review]: ----------------------------------------------------------------- I see from https://bugzilla.mozilla.org/show_bug.cgi?id=1005430#c1 that we missed aus3 initially. This patch just enables test mode on aus3, so we can enable them in production mode at the same time later (or aus3 first, if that's the dev instance).

I don't think you should do this, especially with the "strict" setting of the pinning preference. Otherwise, people who are on the other side of a corporate MitM proxy won't be able to auto-update when "strict" mode is on. That would be especially problematic if "strict" is made the default. I think a better solution is to leave AUS completely unpinned, and rely on the code signing mechanism (expanding code signing to all platforms).

Monica, what Mozilla services are currently pinned and which ones have not been pinned and are planned to be pinned?

(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #3) > I don't think you should do this, especially with the "strict" setting of > the pinning preference. Otherwise, people who are on the other side of a > corporate MitM proxy won't be able to auto-update when "strict" mode is on. > That would be especially problematic if "strict" is made the default. > > I think a better solution is to leave AUS completely unpinned, and rely on > the code signing mechanism (expanding code signing to all platforms). This is one of my main fears. As we discussed, we have other security measures in place that cover the entire update process and pinning would only cover a small subset of what is covered by these other security measures.

Hey Robert, Sorry for not including this in comment 0. https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#New_sites_pinned_in_Firefox_32 AMO: *.addons.mozilla.org, *.addons.mozilla.net Mozilla CDN: *.cdn.mozilla.{org,net}, *.media.mozilla.com 33: accounts.firefox.com We are also pinning Twitter and Google in 33 (and Facebook in 34, hopefully).

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #5) > (In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment > #3) > > I don't think you should do this, especially with the "strict" setting of > > the pinning preference. Otherwise, people who are on the other side of a > > corporate MitM proxy won't be able to auto-update when "strict" mode is on. > > That would be especially problematic if "strict" is made the default. > > > > I think a better solution is to leave AUS completely unpinned, and rely on > > the code signing mechanism (expanding code signing to all platforms). > This is one of my main fears. As we discussed, we have other security > measures in place that cover the entire update process and pinning would > only cover a small subset of what is covered by these other security > measures. This is fine with me, but how do we resolve https://bugzilla.mozilla.org/show_bug.cgi?id=1052365? I don't want to see any callers of CertUtils do stuff with cert names in prefs.

They could use an alias to the host and a different cert.

(In reply to [:mmc] Monica Chew (please use needinfo) from comment #7) > (In reply to Robert Strong [:rstrong] (use needinfo to contact me) from > comment #5) > > (In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment > > #3) > > > I don't think you should do this, especially with the "strict" setting of > > > the pinning preference. Otherwise, people who are on the other side of a > > > corporate MitM proxy won't be able to auto-update when "strict" mode is on. > > > That would be especially problematic if "strict" is made the default. > > > > > > I think a better solution is to leave AUS completely unpinned, and rely on > > > the code signing mechanism (expanding code signing to all platforms). > > This is one of my main fears. As we discussed, we have other security > > measures in place that cover the entire update process and pinning would > > only cover a small subset of what is covered by these other security > > measures. > > This is fine with me, but how do we resolve > https://bugzilla.mozilla.org/show_bug.cgi?id=1052365? I don't want to see > any callers of CertUtils do stuff with cert names in prefs. 1. Use LOAD_ANONYMOUS so cookies, etc. are not an issue. 2. Firefox should always know (be taught) the hashes of acceptable GMP packages, and verify against those hashes. (A good way to do this would be for Firefox to download a set of detached signatures signed using a Firefox code signing certificate). 3. The key pinning infrastructure blocking downloads/updates of that plugin is not as big a deal as key pinning failures blocking Firefox updates. So, if key pinning is still desired for that plugin, then it can be done as Robert suggested in comment 8.

(In reply to [:mmc] Monica Chew (please use needinfo) from comment #7) > This is fine with me, but how do we resolve > https://bugzilla.mozilla.org/show_bug.cgi?id=1052365? I don't want to see > any callers of CertUtils do stuff with cert names in prefs. All that manual pseudo-pinning stuff needs to go away. It was always a hack stop-gap waiting for actual signed content. Real pinning would be better than manual pinning, but signed updates are better than both.

Removing leave-open keyword from resolved bugs, per :sylvestre.