Hi Kyle, I'm reading your mail now for the third time, but somehow I fail to understand....Specially the thing about "Businesses/organizations need to be able to enforce their policies". Could you give me a short, practical example how the proposal from Nelson would break things and make it impossible to enforce certain policies? I guess there might be minor adjustments needed here and there, but not something which can't be overcome in a sane amount of time...I really want to understand which use cases there are which would support the current behavior.
-- Regards Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org> Jabber: [EMAIL PROTECTED] <xmpp:[EMAIL PROTECTED]> Blog: Join the Revolution! <http://blog.startcom.org> Phone: +1.213.341.0390 Kyle Hamilton wrote: > 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? > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
