If the "fail verification only" option is not viable, I personally think we shouldn't expose this to extensions.
I don't think the ability to experiment with new trust models for the web is worth the price we'd be paying in malicious-extension risk, in fracturing the ecosystem risk, or in general complexity risk. Alex On Wed, Feb 28, 2018 at 11:54 AM, Tom Ritter <[email protected]> wrote: > On 27 February 2018 at 10:23, Alex Gaynor via dev-security-policy > <[email protected]> wrote: > > A reasonable compromise that jumps out to me is allowing extensions to > make > > an otherwise-secure connection fail, but not allow them to rehabilitate > an > > insecure connection. This would allow experimenting with stricter > controls > > while avoiding some of the really scary risks. > > I'm obviously the person who filed that bug and began this discussion, > but I think this compromise is one of those compromises where no one > gets what they want. > > Firefox gets a complicated API that gets shimmed into > security-sensitive code and can disrupt TLS handshakes. > > Web Extension developers get something that doesn't do the most > valuable thing they would like to do: experiment with new Server > Authentication modes. > > Of the examples I gave (Cert Patrol, Perspectives, Convergence, DANE, > DNSSEC-Stapling) - every single one of them would not actually allow > experimenting with Server Authentication modes if all they could do is > reject certificates and not accept them. And in many cases, it will > completely prevent any such experimentation, because you can't ask a > CA to sign a cert saying "No really, I just want you to include this > weird data under this weird not-documented/not-standardized x509 > extension". > > > Unless people show up claiming that that functionality is sufficient > for them to do things they want to do; I don't think it would be > valuable to implement this compromise. > > -tom > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
