On Dec 4, 2007 4:20 PM, Nelson B Bolyard <[EMAIL PROTECTED]> wrote:
> Gervase Markham wrote, On 2007-12-04 14:44:
> > Nelson Bolyard wrote:
> >> Now, there is a request asking that NSS's code for matching the
> >> application's desired host names to the names in the cert adopt the more
> >> restricting IETF standards, and the NSS team wholeheartedly agrees.
> >
> > What is the rationale for the request? Does it increase security in some
> > way? Or enable CAs to sell more certs? ;-)
>
> It reduces a user's vulnerability to certain forms of attack.
> Today, a user may be persuaded to import and trust an SSL server cert
> with a "*" pattern, which allows the hold to masquerade as any DNS name.
> Perfect for MITM attacks. This would stop that.
>
> We think there actually are certain "products" in use in the wild that
> depend on that very vulnerability to perform MITM operations (that we
> might or might not characterize as "attacks"). They do this to filter
> content for links or image tags to advertisers or certain malware, etc.
Businesses also use these in order to centralize all of their
web-browsing Sarbanes-Oxley documentation, educational record privacy
compliance, and other compliances. Making this change would make it
MUCH more difficult for them.
> This would stop most of those from working. IMO, this is a net good
> thing. The right place to do such filtration is inside the browser,
> not in an MITM. An MITM takes away from the browser user all control
> over how invalid certs from the true distant servers are handled.
I would agree in principal, but severely disagree in practice. A
proxy, under the current rules, is used to enforce policy. Allowing
unchecked HTTP CONNECT creates a hole in the policy that anyone can
walk through.
There are several aspects of policy handling, and enforcing that they
be pushed out to browsers (which have been plagued with security
holes) on subvertible, arbitrary-code-execution-vulnerable operating
systems is counterproductive.
Businesses/organizations need to be able to enforce their policies,
and if you try to break what they've settled on as means of making the
policies work to ensure their compliances you're going to end up
removing a large amount of the impetus to use Mozilla-based products
in those environments.
For home use ('home' defined as 'places that don't use proxies'), it
is necessary to allow the browser to perform some policy sanity checks
(such as the 'phishing site check') -- but unless you allow every
possible mechanism that the browser has to contact the outside world
to be controlled to arbitrary depth, you're going to alienate people
and organizations that do need the current behavior.
> The MITM implements its own policy towards invalid certs (probably by
> accepting them all as valid), and always presents its MITM cert to the
> browser, which accepts it as valid.
(I've seen MITM software that refuses to allow private-label CAs to
sign sites that it allows connections to. It removes the policy
decision from the browser and places it under administrative lockdown.
The /administrator/ implements the policy checking. If that's done,
no software on earth should take control away from the administrator.)
The problem the Mozilla organization has, and this has been inherited
from the Netscape organization, is that the Mozilla organization seems
to think that it must define and arbitrarily change policy within its
codebase and if the user doesn't like it they don't have to come along
for the ride. The problem is, this is a HUGE change in policy
(effectively removing the choice to externally-implement the policy
:P). I've been involved in two organizations that only allow Mozilla
products to be used in their locked-down environments because it
allows for the external policy implementation.
(I should also point out that this proposed change does absolutely
nothing for the case where a local CA, controlled by the proxy, is
imported into the browser. The CA can generate certificates "on the
fly" for each and every domain that's requested by a client -- but
that, too, is a significant change as it requires more processing
power be used for bookkeeping just to keep the browser from bitching.)
> >> It is proposed that we change NSS to accept only wildcards that meet
> >> these rules:
> >> - exactly one star (*) and no more.
> >> - star matches any numbers of characters EXCEPT DOT.
> >> - There can be no dots to the left of the star, and a dot must
> >> immediately follow the star.
> >> - There must be at least two dots after (to the right of) the star,
> >> and each dot must be followed by one or more non-dot characters.
> >> - There may be characters OTHER THAN DOTS to the left of the one star.
> >
> > Are there CAs who are issuing (or have issued in the past year or two)
> > certificates which do not meet these rules?
>
> It is unknown if any legitimate CAs do so, or have done so.
> It is certain that illegitimate ones (read, attackers) have done so.
So disallow importation of these kinds of certificates into the local
certificate repository, or explain (during import -- oh wait, that
would be 'changing the chrome') what the effect is and why it's
generally an extremely bad thing. I wouldn't mind a mechanism to
change between new and old behavior (in Mozilla, it'd be a preference
setting), but I feel extremely strongly that this is not a change that
everyone will be happy with.
> >> Also note that Microsoft Internet Explorer (MSIE) already disallows many
> >> of the wildcard patterns that we propose to disallow in NSS.
> >
> > Many? Or all?
>
> We don't know exactly what rules they enforce. We know that they permit
> only a single '*', and do not permit any of the other forms of so-called
> regular expressions that are presently recognized by NSS. We don't know
> if they require any minimum number of dots to the right of the '*', or
> if they allow other things to the left of the star.
So, here's a radical thought: why don't you propose a mechanism of
certificate handling and submit it through the IETF, instead of making
arbitrary changes to your own policy that are all but guaranteed to
reduce the Mozilla user-base? Specifications are only useful to the
point that they are useful -- there are many aspects of everything
cryptography-related that aren't, including specifications of policy
requirements in the base protocols ("the server MUST identify itself
before it asks for client authentication" being a very pointed
reference).
Reality seems to have a way of enforcing itself against the wishes of
anyone or anything who might wish to avoid its enforcement. Why
aren't we using the X. series of protocols (X.400 for email, X.500 for
a full world-scale Directory, etc)? It's because the specifications
have been shown to be unworkable, unwieldy, and unimplementable.
There are many problems, but the core seem to be 'defining policy in
protocol'. When someone wants to use the protocol, they have to fight
the policies that implementations of the protocols force down their
throats, rather than having the flexibility to use the protocols and
identify for themselves and their own purposes and environments the
points where policy can best be applied.
> >> If the proposed change will cause you grief, please let the NSS team
> >> know by posting a message to this news group or mailing list, or by
> >> adding a comment in bugzilla bug 159483, or by sending email to me
> >> (you must demangle my email address) SOON. (This week, please.)
> >
> > Do you think it is worth asking this question more widely?
>
> I was expecting to get some quick responses from readers of this
> group/list. I want to hear from producers of products.
If you assume that 'producers of products' are going to be on this
mailing list, even when they have built their exception-crafting
systems from other technologies, you're falling into the same
haughtiness that Microsoft falls into every time they make a change in
their products' behaviors without allowing input from their users.
Remember, 'users' cannot be bandied about as 'those idiots who don't
have any clue what they're making themselves vulnerable to'. 'users'
also include network and security administrators, compliance
administrators, business users -- as well as the "clueless home
lusers" that you seem to dismiss all users as. (Quite frankly, I'm
disappointed that you're forgetting this.)
Until NSS provides for administrator-specified policy implementation
plugins, this is an extremely bad move.
> If we ask the broad user base, we KNOW that we will get lots of
> complaints from users who are crafting their own certs that use these
> techniques. The answer for those users is: PSM's new store of added
> security exception certs.
>
> Let's face it: Users want certs that they make for themselves to work,
> without error, no matter how many different ways they are invalid.
> The new cert exception store accommodates them better than the old
> scheme, because it reduces their potential vulnerabilities to the
> things a really bad cert might do to them.
>
> So, I'm really not concerned about the users who make one or two of
> their own certs for their own use, because we have an adequate solution
> for them. I'm concerned about "legitimate" products and/or large scale
> deployments (say, by in-house CAs) that might be affected by this.
I'm rather frightened by the disconnect that this suggests. Those
"legitimate" products are bought and deployed by some members of the
class of "users" in your view -- the same "users" who you so coldly
dismiss the capabilities of.
Then again, I don't expect you to hear what I have to say with any
kind of attention. After all, I was only a network security
administrator for a hospital and later for an international
private-sector corporation. After all, I only have colleagues who are
in education and finance. After all, it's not like I would have any
knowledge of this kind of thing -- I'm just a "user".
If someone were to lump you in with a group whose
security-consciousness and intellect are viewed as somewhat
submammalian, what would your reaction be?
-Kyle H
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
