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.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
