consider enabling public key pinning on Seamonkey

NEW
Unassigned

Status

defect
3 years ago
2 years ago

People

(Reporter: rsx11m.pub, Unassigned)

Tracking

SeaMonkey 2.46 Branch
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

()

Reporter

Description

3 years ago
+++ This bug was initially created as a clone of Bug #1019259 +++

Per http://forums.mozillazine.org/viewtopic.php?f=6&t=3023925 certificate pinning is enabled on Firefox 49.0 and passes the test page. In SeaMonkey 2.46, this works with security.cert_pinning.enforcement_level set to 1 as well, but is disabled by default due to the all.js setting.

So, the question is if we should enable pinning for SeaMonkey builds as well, whatever the implications are I don't know.

There is also Callek's concern from bug 1019259 comment #1:
> What does this SLA mean for terms of our users or derivative projects
> choosing to pin despite our default setting?
> 
> Is this a contractually enforcable SLA for MoCo/MoFo in terms of the use?
> (e.g. if we later decide we think we can meet this SLA, and enable it, then
> turns out we can't due to some other situation, what does that mean for us
> as a community/org)

Response from Monica Chew in bug 1019259 comment #2:
> As long as Seamonkey doesn't change security.cert_pinning.enforcement_level
> from 0 (as it is set in modules/libpref/src/init/all.js), there's nothing to
> be done. Sorry for the confusing bug report, I don't know which, if any,
> prefs Seamonkey takes from browser/app/profile/firefox.js, where the pref is
> set to non-zero.
> 
> The SLA is an informal promise to the pinned site operators that we will do
> our best to get our pinning fixes in 24 hours. If users or derivative
> projects choose to pin (including Seamonkey) then MoCo/MoFo/site operators
> are not in a position to help with escalations in case of breakage or
> unexpected behavior. We recommend against pinning in derivative projects at
> this time. In the future, site operators can advertise their pinning support
> online with HPKP: http://tools.ietf.org/html/draft-ietf-websec-key-pinning-13
> 
> This is a safer mechanism because it won't rely on ops/releng coordination
> for regressions.

The patch should be trivial, but the question is if anything has changed in that recommendation or if SeaMonkey would benefit from enabling certificate pinning as well. For reference, Thunderbird currently has *not* enabled pinning, but Instantbird (im/) has.
At this time, I have no overt concerns.

The only pressing concern is around our ability to ship every ~6 weeks, until we can decrease the burden on that and start meeting (near) our release promises I advise against it [but not a strong advise].

The in-tree HPKP pins have an expiry, I've since learned, so even if we pin those will expire eventually and we won't fail completely. HPKP headers also exist now, so websites can get them updated for our users too.

(There was even a recent addons.m.o sec issue that is now resolved due to hpkp pinning expiring before users got an updated build, and addons website not sending hpkp headers to update the pin/expiry -- it now sends those headers)
See Also: → 1358762
You need to log in before you can comment on or make changes to this bug.