On Mon, January 18, 2016 12:26 pm, Eric Mill wrote:
> On Mon, Jan 18, 2016 at 10:19 AM, Richard Barnes <rbar...@mozilla.com>
> wrote:
>
> > ...
> >
> > One thing that has been proposed is to have an exception for local
> > roots,
> > i.e., to let non-default trust anchors continue to use SHA-1 for some
> > more
> > time. What do folks here think about that idea?
> >
>
> That seems like a choice to make only if it must be made, in order to shut
> off SHA-1 for public roots in the absence of change in the enterprise.
> It's
> not something I would proactively accept and move towards, since it
> removes
> all pressure from vendors and enterprises to fix up their stuff.
I think this misses out as to how enterprise support generally works.
I think we're all in agreement that we want users safe by default.
I think it should, but may not be, obvious that the risk profiles for a
publicly trusted CA are very different than that of an enterprise-operated
CA. In both cases, a SHA-1 chosen-prefix collision puts all users who
trust that certificate at risk, but the population size for a given
enterprise-root versus Mozilla-default root are many orders of magnitude
different (a single enterprise versus all Mozilla users)
It's also worth considering that enterprise *users* are in a very
different position to enact change. Generally, they're dependent on
vendors, who unlike CAs, don't participate in many (any) industry forums
and which have a very different set of use cases and constraints than
publicly trusted CAs do. Showing a *user* an error because the *vendor* is
slacking doesn't really help protect the user - it just gets them to shift
off that browser or innoculate them to warnings, more than it gets them to
apply pressure to the vendor.
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.
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.
So what should the flag do when it's enabled? Enable it for all sites?
Probably not - that's encouraging publicly trusted CAs to act in bad-faith
for Internet security. It's most likely that it would do exactly what
Richard proposes - whether it be metadata associated with the root at time
of installation ("Allow this certificate to issue SHA-1 certificates") or
general policy ("Allow enterprise-installed certificates to issue SHA-1"),
the effect is the same.
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 )
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.
There's no question that a number of vendors will need months to fix their
products, and aren't doing their due dilligence now. And even when they
do, it may take enterprises months-to-years to deploy these new versions,
because it's always with trade-offs (perhaps the vendor discontinued Vital
Feature X in the version that supports SHA-2, for example).
So we definitely can't think of this as a game of chicken with enterprise
vendors - it's a complex ecosystem balance - and one where, if we want to
support enterprise users, needs to be sensitive to their needs. Whether
it's a default policy (which I support Richard's proposal, which is not
surprising, considering I was one of several to have suggested it) or a
custom flag in about:flags, or an environment variable to be set, a
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.
> 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.
It doesn't have to be a permanent exception, by any means - enterprise
flags go away all the time too, especially if and as they increase support
costs or decrease velocity in maintaining the code (which grows to support
each possible permutation and combination of flags). But all or nothing,
nah.
For what it's worth, the policy proposed by Richard is more or less what
Chrome has presently adopted ( see
https://googleonlinesecurity.blogspot.com/2015/12/an-update-on-sha-1-certificates-in.html
), and almost certainly more or less what Microsoft will adopt (given that
RSA keysize deprecation already has enterprise flags associated with it,
as does the 'strong crypto' behaviour of CryptoAPI & Edge), so it's not at
all unreasonable.
A possible migration path is to distinguish PTCs (Publicly Trusted Certs)
from ETCs (Enterprise Trusted Certs), and have separate flags, with
defaults being SHA-1 off for PTCs, and SHA-1 left on for ETCs by default.
Enterprises can use Firefox's policy management to adjust the ETC flags,
and with a date set in the future where the default for ETCs, in the
absence of policy explicitly configuring it, will switch from "On" to
"Off". This is how you securely migrate things, potentially with
additional UI to communicate if/when ETCs are encountered (which is a
separable issue, really - you can introduce the flag well before and w/o
needing any corresponding UI; the UI is for evangelism, not enforcement)
Alternatively, a more complicated change would be configuring per-root
whether SHA-1 was allowed or not-allowed, but the downside for that is it
creates incentives for PTCs to encourage or instruct users to do so. Given
the history of root CAs encouraging and evangelizing insecure practices
when it can net them additional revenue, I think that would perhaps be
unwise, but it is a more robust option for organizations that have many
ETCs with distinct threat/risk profiles. In my experience, however, such
enterprises are rare, and the risk/reward/complexity tradeoffs favor the
simple flag-for-all solution rather than flag-per-CA.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
