What is also fun is that they released it two weeks before Oracle released it's own patch for paid Java 6/7 customers, before which the 768-bit DHE was hardcoded.
---------------------------------------- > Subject: Re: Firefox security too strict (HSTS?)? > From: [email protected] > Date: Wed, 23 Sep 2015 12:17:18 -0700 > To: [email protected] > > 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 > [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
