>> A cert that isn't laid out to standard isn't useful. > > The dilemma comes out most strongly when a major > browser accepts a non-standard cert. If a product > has 90% of the market, and accepts a non-standard > approach, it's useful. No matter how much one > believes in standards, this happens over and over > again.
Yes, there is a widely used product that seems to have ignored numerous details of various security standards. And from time to time, it is caught sans pants, such as when it was revealed that said product allowed ANY cert to act as a CA cert, and issue other certs, even when the cert's extensions clearly identified it as a non-CA cert.
If mozilla wanted to be fully "bug compatible" with that other product, it could (well, it could come very close. Not all details about the other product's behavior are publicly known, of course.)
But I keep hearing from mozilla users how glad they are thet mozilla doesn't have all the security fire-drills for which the other product is (in)famous. So, I don't think that turning a blind eye to bad certs is the right answer.
Recently, the producers of that other product turned out a significant patch that fixed some of the crypto related holes. That was motivated, I believe, by the release several months ago of a huge PKI test suite named NISCC from an arm of the UK government, and the publication of the results of testing with that test suite. MOzilla benefited from testing with that, too, last year.
There's another test suite now getting attention. This one, known as PKITS, is from USA's NIST. Pretty soon, big customers, including the U.S. government, will begin to demand products that pass that test. I predict that even more security holes will get closed due to that demand.
So, in the long term, many crypto products will be enforcing the rules that mozilla now enforces, IMO, and perhaps more besides.
> If I was a commercial CA, and a browser maker > set up such a rule to determine trouble by number > of complaints & bugs, I would ensure that there > were at least that many bugs and complaints filed > for the weaker products.
How would you do that, short of sabotage of their facilities? All the "weaker" CAs need do is ensure that they don't issue any certs that don't conform to the standards. The complaints have to reveal actual flaws in the CAs' certs, in case that wasn't clear.
> Why doesn't the normal "rule" covers it? If > there aren't enough people to get around to it, > then the bugs will sit there.
With the new policy in place, bugs that say "my homebrew cert doesn't work" will get marked invalid quickly. Trust me ;-)
>> After all the SSL crypto computation, and the >> validation of the cert chain, one of two outcomes arise. Either >> we've proven to our own satisfaction that the party at the other end >> of the SSL "pipe" is who the cert says it is and we now have a "secure >> pipe" to that party, or we haven't and don't. > > No, you've shown that the cert is signed by a > root cert, and that the cert id matches the website.
And that the party at the other end of the pipe has the private key
corresponding to the public key in the cert, and (optionally) that the
cert hasn't been revoked. These things taken together prove the
identity of the party at the other end of the SSL pipe to the browser's satisfaction.
> If the root cert is of lesser pedigree, then > the user might want to know that [1]. Are all > CAs equal?
They may not be all created equal :) but they all get treated equally by all SSL-based https browsers. That is, each browser has its trusted list (perhaps has modified by the local user), and trusts the CAs in that list equally for the purposes for which they are trusted, e.g. SSL server auth.
> You might assert that, but is that > a reliable statement? And, does it make sense > to claim that is a reliable statement? Do all > CAs conduct anything like appropriate due > diligence?
Answering the question "do all mozilla's trusted CAs conduct appropriate due diligence?" is the challenge now before the mozilla foundation, by virtue of the path they've chosen to take.
> I don't think so, simply because the due diligence is the same for a > flower shop as it is for a bank.
I agree that DD(flower shop) != DD(bank). Mozilla Foundation now gets to separate the banks from the flower shops.
> Luckily, this is never at issue, as a real attacker bypasses the > HTTPS security altogether.
I gather you're referring to the problem that many browser users have no idea of the name of the party with whom they wish to securely communicate. They want a secure pipe to person X, but that have no idea who person X really is, or what his name is. E.g. www.ebay-something.com
I assert there's nothing that ANY crypto-based scheme can do about that. Whether the scheme is PGP-like with WOT, or PKI-like with hierarchy, if a user has NO idea of the correct and proper name of the party with whom he's communicating, he cannot know if the name he is shown is correct.
The definition of the problem that SSL, SMIME and/or PGP solve requires that the parties communicating are able to name each other (at least in one direction). An encryptor must be able to name the decrypting recipient. A signature verifier must be able to name the signer. Take that away, and you have a different problem that none of them solve.
This gets back to the issue of the end user not being apt to discern the real security risks. He wouldn't tell his secrets to a complete stranger who rang his door bell, but he will tell his secrets to a complete stranger who has a pretty web page.
>> I think all security conscious folks who've participated here wish that >> browsers would display more info about >> a) what is the full name (as full as we have in the cert) of the party >> at the other end of this pipe, and >> b) who says so? >> I know that the various managers of browser crypto securty software >> under which I've worked in the last 7+ years all wanted that, as did >> most (if not all) the crypto security developers. >> >> The fact that browsers don't do that today is not because security >> people are holding back, but rather is because UI people do not value >> security enough to be willing to devote the window real estate to it. > > That's a key point, so, we are agreed that the > security is unsatisfactory.
I didn't say that, and don't agree to it. Perhaps we agree that the display of security relevant information is not as prominent as we might wish it to be, but it is available. The security of my bank's vault is not lessened by the fact that I cannot see all the door's locking bars at a glance.
>> One thing we learned from Communicator 4.x was that if you give the >> user a way to override a security error, the user will always choose >> to do so. Any error or warning that you let the user disable, he will >> disable. The user views warnings that say "you're not talking to the >> party who you said you want to talk to" as just another annoying >> dialog that they have to click through on the way to what they want. >> IOW, the user is typically not able to aptly judge security risks, >> even though it is they who are most likely to lose from their choices. > > > > Right. This brings up some quite difficult results, > such as, even if the browser says, "this party is > using a bad cert," then the user clicks through any > way. [snip]
Isn't that what I wrote immediately above?
> So, we seem to be in agreement that the current > notion of popup dialogs that asks questions is not > going to help.
It doesn't help as much as had been intended, WHEN we let them override.
> False certs are not defeated, in > the practice of the browser activity, although they > are addressed in the protocol and the CA regime.
If we let user defeat them. As I said before, I think the answer is fewer user overrides, fewer user decisions, fewer user mistakes.
Giving the user more information only increases the chance that the user will click past it. The user understands "No, you can't do it." and not much more.
> Hence, the branding idea. This is an idea that has > been floating around for some time, and was brought > up recently by Tim Dierks. CAs want it, as per the > below [1], and they should, otherwise their business > is free riding off the other CAs, and they can't set > their prices properly.
Yes. Netscape's crypto security managers at one time wanted it too, to reduce potential liability. The idea was expressed this way: when the user asks "who says this is secure, and the party to whom I'm speaking is so-and-so?", we want the answer to be "This CA", not "Netscape". There was a facility developed to display a CA's logo, getting the image from a URL in the cert. But this is where the aforementioned window real estate battle occurred.
> There are some good reasons why brand works when > dialogs don't: it enables the user to make choices > based on information that they've acquired via > other channels. It enables the CAs to express some > real claims. There are also some reasons why it > isn't perfect, but it does seem to be way way better > than what's there at the moment.
Maybe we could use the image of a mean devil for certs from unknown CAs.
> >> That's one reason why mozilla has fewer security dialogs that the user >> can override, and more that simply say "no dice". And it hasn't been >> a great tragedy. More web sites that used to be sloppy have now done >> the right thing and fixed the problems. That's a GOOD THING. >> >> I'd say the way forward is to enforce the rules no less tightly than >> before, maybe more so, and give the users fewer decisions to make, >> fewer chances to hurt themselves. With the presence of low-cost CAs, >> there won't be any remaining excuse for people to continue to use >> improperly made certs from their own homebrew CAs. > > Security is a hard problem. It's not amenable > to a binary result, that of being secure, or > being insecure.
Ultimately, it's always a binary decision to act, or not. Do I spend the money? Do I type in my confidential info?
> It's a process, and a progression. The HTTPS > implementation is already so imbalanced within > today's browsing, by means of its desire to > create a user-simple binary security choice, > that it is ignored by almost all attackers [2].
E-commerce has been a HUGE success. People buy things over the web now in HUGE amounts. It really has impacted "brick and mortar" businesses. And it gets almost NO bad press. People simply don't hear that large numbers of people are incurring substantial losses because of unwise choices in E-commerce. The public is largely fearless about internet use, quite a switch from the way it was 8-10 years ago, when most people were very afraid to attempt e-commerce.
Today, that fearless attitude is why people click past all the warnings. They've never heard of someone who suffered because he ignored them. So, the public ignores them too. branding doesn't solve that. You can't entice people with the words "safer, more secure" when the public feels no lack of safety.
> By any measures, browsing is not well protected.
Unfortunately, I think it is better protected than the public cares it to be.
> The security that was built in is bypassed on a > routine basis in real attacks. One of the core > reasons for banking websites being so vulnerable > is that HTTPS is "too secure" - so theoretically > secure that it results in costs and inconveniences > that lead to easy bypasses and easy ignoring.
banking websites are so vulnerable? Can you substantiate that?
One area where people still do take some care about their web security is banking. I've not heard or read any reports of succesful attacks on bank web sites. (Except, see below)
> You are totally right that this is also/really > a UI problem. But, the UI people won't look at > it until they realise that the HTTPS system in > browsers doesn't deliver the security that they > thought.
And I doubt that mozilla UI people will ever realize that.
At one time, the predecessor of the mozilla browser was being developed by a for-profit company whose paying customers were mostly enterprise businesses who had more concern for security than the average consumer. And even in that environment, where developers salaries were paid by producing a product that met a business need, and that businesses were willing to buy, the developers were unwilling to devote additional window real estate to security info.
Today, mozilla is a nearly all volunteer effort. Most of the volunteer time is devoted to things that are clearly visible in the UI. Very little is devoted to such "invisible" things as crypto security. People work on UI because it's visible, it's something they can literally point to and say "I did that". The projects that get worked on are mostly those that appeal to volunteers. Volunteers aren't likely to work on a low visibility feature out of some sense of obligation or fair play, even if it makes a different to the product's security.
Now, if we couldn't get UI people to devote real estate to security when arguably their jobs depended on it, what chance have we now that UI work is all volunteer?
Maybe we should abandon trying to get screen real estate, and instead have a voice that sounds like Mom, saying "Don't you even THINK of typing your confidential information into that screen, young man!" :)
In the meantime, taking away the overrides seems reasonably sensible.
> iang
There's a web site that offers a proxy service to visitors. They offer the promise of "faster browsing", and the chance to win occasional cash and "fabulous prizes" to people who will agree to install their software and use their proxy. If you install their software, they will not only monitor your http traffic, but also your https traffic (decrypted) for many popular websites, such as Amazon (if I recall correctly). They're up-front about this. If you read their FAQ and their privacy statement, they spell out that they will monitor your secure encrypted banking traffic too. Of course, they promise to keep it all confidential. Their site even displays a WebTrust seal!
When I checked into it a couple years ago, their proxy server identified
itself with a string similar to "Man-In-The-Middle Proxy". Their software includes a trusted root CA cert. This is one of the few sustained MITM
attacks on SSL known to me.
If you visit that web site with mozilla, you will be directed to a page that informs you that your browser is not supported. Should we make mozilla compatible with that "other browser" to get around this?
I wish I knew how many users they have. Every one of their users is someone who traded away his privacty and security for not much value, IMO. (Please don't ask for the URL. I've given plenty of clues.)
At the risk of lanuching another tangent into a parallel universe ... I have wondered for a long time, why companies like Standard and Poor, who rate companies on various merits that might directly correspond to business trustworthiness, don't get into the CA business and put info about a company's ratings into the certs they issue. A cert that tells me I'm dealing with a fortune 500 company with a good credit rating vs a fly-by-night outfit might be a LOT more meaningful than the present certs. Similarly, a cert from the Better Business Bureau stating that I'm dealing with a company that satisfactorily resolves 99% of consumer complaints would be to my liking.
Maybe it's up to the CAs themselves to start offering more real value to the relying parties in their cert contents. This probably doesn't bode well for low cost CAs though.
Diclaimer: opinions and faulty memories expressed are solely mine.
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
