On Mon, Jan 18, 2016 at 8:46 PM, Ryan Sleevi < ryan-mozdevsecpol...@sleevi.com> wrote:
Because of this, anyone who has ever supported enterprise software is > aware of the all too present necessity for enterprise flags. That is, > off-by-default configuration flags that can change or alter behaviour to > support an enterprises' needs. Yes, some of these directly reduce security > - such as enabling NTLM over HTTP sites, for example, or the "Intranet > Zone" of IE - but are necessary to support the slow-moving, > contract-driven reality of enterprise software support. > I do understand this general dynamic, and have had the great pleasure of enjoying the slow-moving contract-driven reality of enterprise software in my daily life. I was suggesting not deciding a year ahead of time that enterprise apathy will be too overwhelmingly powerful to even try pushing on, in the specific case of SHA-1 deprecation. So imagine a world where we turn SHA-1 off by default. I can assure you > that both Microsoft and Chrome will end up having some form of enterprise > policy to enable it, in some specific cases. Quite possibly Android too. > Is there an enterprise command line flag for MD5 support in Internet Explorer? :) There isn't in Chrome, and here's the bug thread where the Chrome team denied fervent requests by someone behind an enterprise firewall to add MD5 support in behind a command line flag: https://code.google.com/p/chromium/issues/detail?id=121705 To quote rsle...@chromium.org in comment #15: > From the net/security side, the discussion has universally been WontFix. > So far, all vendors (of man in the middle boxes signing with MD5) have > released updates to their product, to the best of my knowledge. The > security of MD5 is distinctively troubling enough that this would be akin to > disabling SSL security for users behind such proxies. I understand that MD5 was in a much more dire situation in 2012 than SHA-1 is in in 2016, and that middlebox vendors are not as far along with SHA-2 support. But that's only a temporary situation, so I don't think it's all that far-fetched to suggest applying any kind of pressure at all to enterprises and middlebox vendors. > I agree that we (as browser vendors and security community members) want > to exert some influence onto vendors to guide them to secure behaviour. > But the reality is the incentives of these vendors is very much *not* in > security. If you have any doubt of that, see examples like > https://code.google.com/p/google-security-research/issues/detail?id=693 ( > or really, any number of examples from > https://code.google.com/p/google-security-research/issues/list?can=1 ) > Oh I don't have any doubt of that, but I do like how the costs of insecurity are rising and becoming more visible to enterprises -- the Trend Micro example above being a good one. We should look for more opportunities to make bad behavior expensive for enterprises and vendors. > > But there's opportunity to exert softer pressure. For example, UI that > reminds users every time they access one of these SHA-1 sites that their > vendor software is insecure, but which doesn't require the user to get > conditioned to click through interstitials, and for which the noisiness > ratchets up over time. > That's a great short-term strategy, if it's decided -- hopefully later in 2016 than January -- that outright removal of support isn't immediately feasible. Incidentally, it's also the same path I would argue that browsers should take in handling the situation of HPKP being overridden by local roots: even if hard-fail enforcement would ultimately lead to a bad ecosystem outcome, surfacing this information in a non-interstitial fashion is far likelier to strike the right balance of user awareness that doesn't create an arms race. registry key to be tweaked, whatever have you, I think we need to > recognize a distinction in timelines and risk factors between publicly > trusted and enterprise trusted. > Absolutely. > This also seems like something of enough import that a multi-browser/OS > > plan would probably be more effective than any single browser leading on > > it, since enterprises tend to have 0 qualms about directing their entire > > staff to use whatever browser works around the problem they're seeing. > > This suggest it's all or nothing, but I tried to spell out above how it's > not the case. Collective action against enterprises consistently > backfires, and just alienates users and makes enterprises more risk averse > - which makes them less likely to apply updates and fixes if they think > the risks are high. We balance that with customization - defaults that > work for the 99.99% of users, and leave enough of an escape hatch where we > believe it's reasonable or that the tradeoffs are balanced. > How weak does SHA-1 have to get before that balance changes? Is it totally dependent on existing enterprise adoption rates, and ambient non-disruptive user warnings? In any case, I very much get the general point you're making. Maybe it's just because I don't personally develop and maintain a browser, but it seems early to pre-capitulate on the issue. It'd be nice to have data. Mozilla is now gathering and publicly releasing telemetry data on middleboxes. Peter Bowen from Amazon recently publicly released a large TLS telemetry dataset that shows middlebox fingerprints: https://cabforum.org/pipermail/public/2015-December/006507.html Maybe that's something other browsers could work on publishing too? -- Eric -- 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
