Except in both of these cases -- removing TLS fallback to v1.0, and raising DH parameter minimums -- Chrome joined Firefox in doing so. Firefox went out first, and so that was the first impression people got, but Chrome's policies are no less strict. In at least some enterprises, "everyone use IE" is no longer a viable long-term recommendation, and I get the strong sense that Chrome and Firefox's positions will force positive change. I definitely see it happening around me.
-- Eric On Wed, Sep 23, 2015 at 1:17 PM, R Kent James <k...@caspia.com> wrote: > On 9/16/2015 3:01 PM, AnilG wrote: > >> Yes, I agree. From my limited perspective and knowledge I trust you as an >> authority that that's probably completely correct. >> >> But that's not the issue. I've got a concern that security management in >> Firefox is too hard for enterprise and may additionally have problems for >> domestic users that is stopping Firefox from "working" from their >> perspective and significantly affecting market share. >> > > I have other concrete technical examples of where Firefox security > management made a stricter security decision than other vendors, with no > obvious workaround, that caused grief for users relative to other possible > decisions. > > In the fix to the LOGJAM security vulnerability, one technical decision > was the length of the accepted DH key. Mozilla decided to reject sites with > DH key length shorter than 1023 bits. I made this comment on the private > tb-drivers email list: > > "According to > https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ > : > > "'To protect OpenSSL-based clients, we’re increasing the minimum accepted > DH key size to 768 bits immediately in the next release, and to 1024 bits > soon after." and 'OpenSSL clients will reject connections with DH > parameters shorter than 768 bits. As an unfortunately large number of > servers use 768-bit parameters still, we’ll be giving them a short grace > period to upgrade, with a keen eye out to raising the limit to 1024 bits > soon. ' and 'A February TLS survey of top Alexa sites discovered 3 sites > that prefer 512-bit DH, and 420 sites that prefer 768-bit DH. The 512-bit > connections will now break; the 768-bit sites should urgently upgrade.' > > I don't see anyone here really engaging with AnilG about the actual > question, which in my version of the same question was (continuing to quote > from my tb-drivers posting) "Mozilla seems to have this habit of being > really aggressive about these security updates, thereby making lots of > users unhappy. We have a lot of unhappy users right now. OpenSSL is being > slower than we are, and in general their updates are not pushed as > aggressively as ours." > > Later in the same email thread I said: "Unfortunately Firefox (and as a > result also Thunderbird) is getting a reputation for being inconsiderate of > the needs of users in some of their security updates. In 31 there was the > inability to override certificate problems, which ultimately was allowed in > a dot update. Now in 38, we have Mozilla's aggressive approach to the DHE > Logjam issue, with the 1023 bit limit hitting users with very little > warning (while OpenSSL AFAIUI is giving admins more grace time to upgrade > servers) ... Shutting down email access to hundreds of thousands of our > users is a pretty severe remedy compared to the threat, at least in the > opinion of the vast majority of our users .... It would be better if > Mozilla would learn to give a realistic estimate of the likely impact of > new restrictions, and prepare a mitigation strategy, rather than just > hitting users with an update that causes massive pain for their users to > prevent some theoretical threat from state-level actors." > > My two examples (security certificate overrides in 31, DH bit length in > 38) are other examples of historical cases where Firefox security policies > were either reversed due to problems, or stricter than other vendors, > resulting in user dissatisfaction. > > Is it possible that there is a culture issue in Mozilla security policy > that needs addressing of a willingness to break things in the interest of > security, beyond what users or other vendors accept as reasonable? If not, > and we are proud of our record in all of these cases, what can be done to > better educate the world about why all of this user grief was in fact for > the greater good? > > :rkent > > > > > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- konklone.com | @konklone <https://twitter.com/konklone> _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
