User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:47.0) Gecko/20100101 Firefox/47.0 Build ID: 20160606113944 Actual results: security.cert_pinning.enforcement_level is set to 1 This means: If a user installs a CA certificate, this CA is able to MITM all traffic, rendering even HPKP useless. Expected results: security.cert_pinning.enforcement_level should be set to 2 As a user I don't expect that this happens. There is no reasonable means that having a CA certificate installed will allow this CA to MITM all my traffic. See also: https://bugzilla.redhat.com/show_bug.cgi?id=1207335

Is there a point to keeping this security sensitive when the redhat bug is public and this behaviour only manifests when an extra CA cert is added?

(In reply to :Gijs Kruitbosch from comment #1) > Is there a point to keeping this security sensitive when the redhat bug is > public and this behaviour only manifests when an extra CA cert is added? I don't know. Did I do that? If yes, feel free to change it, I can't.

(In reply to Christian Stadelmann from comment #0) > security.cert_pinning.enforcement_level should be set to 2 I don't think we can do this by default, although I would certainly recommend setting it to that value, personally. Even if you ignore companies that install their own roots, there are enough AV products that do the same. That sucks yeah, but it would break a ton of users. David knows a lot more about this than I do, though.

(In reply to Tim Taubert [:ttaubert] from comment #3) > (In reply to Christian Stadelmann from comment #0) > > security.cert_pinning.enforcement_level should be set to 2 > > I don't think we can do this by default, although I would certainly > recommend setting it to that value, personally. > > Even if you ignore companies that install their own roots, Companies that then also (need to) MITM everything, or just companies that do their own certs for company mail/intranet/whatever services? > there are enough AV products that do the same. This is going to sound awful, but could we change the default on Linux and OS X? Or add some kind of mild-ish click-through the first time this happens? (ni Keeler as I assume that's who comment 3 references) (In reply to Christian Stadelmann from comment #2) > (In reply to :Gijs Kruitbosch from comment #1) > > Is there a point to keeping this security sensitive when the redhat bug is > > public and this behaviour only manifests when an extra CA cert is added? > > I don't know. Did I do that? Yes, probably by ticking the checkbox labeled something like "This is a security problem that should be kept private" when filing the bug. > If yes, feel free to change it, I can't. OK.

(In reply to :Gijs Kruitbosch from comment #4) > (In reply to Tim Taubert [:ttaubert] from comment #3) > > Even if you ignore companies that install their own roots, > > Companies that then also (need to) MITM everything, or just companies that > do their own certs for company mail/intranet/whatever services? Yeah, I mean companies that MITM everything and then have a transparent proxy that replaces the cert with one signed by their CA. > > there are enough AV products that do the same. > > This is going to sound awful, but could we change the default on Linux and > OS X? Or add some kind of mild-ish click-through the first time this happens? Hmmm, defaulting to 2 on Linux and OS X might indeed be an option. UX for this seems hard but I'll defer to David :)

(In reply to Tim Taubert [:ttaubert] from comment #3) > (In reply to Christian Stadelmann from comment #0) > > security.cert_pinning.enforcement_level should be set to 2 > > I don't think we can do this by default, although I would certainly > recommend setting it to that value, personally. > > Even if you ignore companies that install their own roots, there are enough > AV products that do the same. That sucks yeah, but it would break a ton of > users. David knows a lot more about this than I do, though. Ok, I didn't think about snake oil AV products, but yes, some of them are transparent proxy-ing browsers MITM all traffic. Seems like they are good for making problems only… (In reply to :Gijs Kruitbosch from comment #4) > (In reply to Tim Taubert [:ttaubert] from comment #3) > > Even if you ignore companies that install their own roots, > > Companies that then also (need to) MITM everything, or just companies that > do their own certs for company mail/intranet/whatever services? Some companies do MITM everything, like deep package inspection for SSL/TLS-secured connections. Does make some sense if you don't trust your staff or you don't trust the software installed on computers your staff uses. > > there are enough AV products that do the same. > > This is going to sound awful, but could we change the default on Linux and > OS X? Or add some kind of mild-ish click-through the first time this happens? And put it in the release notes, of course, so that sysadmins know what broke their MITM. (In reply to Tim Taubert [:ttaubert] from comment #5) > (In reply to :Gijs Kruitbosch from comment #4) > > (In reply to Tim Taubert [:ttaubert] from comment #3) > > > there are enough AV products that do the same. > > > > This is going to sound awful, but could we change the default on Linux and > > OS X? Or add some kind of mild-ish click-through the first time this happens? > > Hmmm, defaulting to 2 on Linux and OS X might indeed be an option. UX for > this seems hard but I'll defer to David :) Adds complexity, but I'd like this solution too.

For the same reason that we wouldn't do this on Windows, I don't think we can on Linux or OS X (causing mysterious and hard-to-fix breakage for users). There may be engineering solutions that could move us further towards this goal (for instance, if we had a way for a user/administrator to import a root and say "this is for MitM" or "this is not for general MitM but some internal service we run"), but this isn't something we're going to be addressing in the near term.