On 27 February 2018 at 10:23, Alex Gaynor via dev-security-policy <dev-security-policy@lists.mozilla.org> 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
