On Fri, Mar 20, 2015 at 10:37 AM, Ryan Sleevi <
[email protected]> wrote:
> On Thu, March 19, 2015 3:53 pm, Peter Kurrasch wrote:
> > There are 2 differences. First, in
> > the event HSTS was activated on the site there will be no chance to
> > override. Second, a user in that region may want to or need to activate
> > that root because he or she relies on the impacted websites. Another
> > concern is that the case by case override might still result in
> marginally
> > usable sites because the embedded requests (css, js, images, iframes)
> > could fail ("unknown issuer") without any chance to add exceptions for
> > them. Being able to manually re-enable trust would serve as a useful
> > remedy for them while still protecting the rest of the Internet
> > populace.
>
> Peter,
>
> While I do appreciate your efforts to think of the users here, I do think
> it does a disservice to them to suggest that enabling trust in this
> certificate is something desirable. That is, in a matter of opinionated
> design, if the Mozilla Root Program has decided that the Certificate
> Authority is not operating in the interests of Mozilla's users and
> security at large, it does seem counter-productive to suggest that users
> should be able to trivially re-enable support.
>
> If it helps, think about how the SSL warnings themselves behave and used
> to behave; it used to be a single click could bypass the error and
> permanently save it. Increasingly, browsers have explored designs to make
> it more difficult to bypass the error - with corresponding studies showing
> that user understanding is increasing, and click through rate is
> decreasing. Sometimes, making things a little bit harder can make a lot
> more people secure.
>
> On the matter of HSTS, this is working by design with HSTS. The mere act
> of distrusting will prevent an override. Leaving the root in
> doesn't/shouldn't affect this.
>
> So I'm strongly supportive of removing both the certificate AND the trust
> records. For users who do have a critical need to trust this root, and are
> willing to accept the attendant risks that Mozilla is (rightfully) not,
> then they can get that root from the CA and install it in the trust store,
> same as they would do a self-signed root or other roots that have not been
> audited/are not auditable.
>
I'm in the same place as Ryan here. In many security decisions we make, we
have to balance breakage for some people vs. risks for everyone else.
When we turned off SSLv3 in Firefox, it was still required by something
like 0.3% of websites -- several orders of magnitude more than will be
broken by removing e-Guven. We decided to do it because supporting that
small fraction of sites would impose a downgrade risk for every other site
on the web.
The situation is analogous here. The benefit of supporting the very small
number of sites that use e-Guven (thanks, Peter B!) does not balance the
risk posed to every other web site by having a non-compliant CA still
accepted.
--Richard
>
> _______________________________________________
> dev-security-policy mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-security-policy
>
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
