I.e., it is a fact that nominally, SSL was required/invented in order to protect credit card transactions. Yet, it is also a fact that the SSL model is singularly unsuited to that role (c.f., SET), and that what was built instead was a general purpose connection security protocol for client-server channels. E.g., within the life of the design of the protocol, not to mention its implementation, the original transaction requirement was disposed of, and something different was built.
(Whether this was good or bad is not debated here, but the point is that SSL is not really tuned to the task of protecting credit card transactions, something that many people in the credit card world will be happy to discuss at length.....)
And SET was so well designed and implemented, that it has practically replaced SSL for credit card transactions, right ? If you want to point to something better than SSL, please come up with something more credible than SET .
In short, we do not know anything about what the transactional usage that we might be trying to protect.
So, setting the protection at the highest level MUST BE A MISTAKE, because we cannot decide on what that highest level might be. In fact, we have no tools whatsoever to decide *any* level, nor practically anything about the transactions.
No, think of it is a paranoid, worst case approach : since the browser doesn't have any way of knowing how risky the transaction is, other than it needs security by virtue of the https protocol handler, it uses the highest level of security it has available - ie. SSL/TLS with CA authentication .
Which is how it should be. The users should decide what protection they need and what they can afford (by this I mean server users and browser users). Funnily enough, they know much much more than any security developer about their own risks.
The only problem is that HTTPS *denies* them the capability to set their own protection. Or, as I recently ranted, they have a binary choice: Servers can do only high end purchased CA certs, or nothing, and browser users can only do whatever the server has decided to do, "nothing" or "everything."
The HTTPS protocol client and server users have the capability to set what level of trust they want, by selecting which certificates they trust .
The CA list that come with browsers and servers is only a default , which can be overridden .
What I think you are getting to is that there isn't a single set of trust that works for all applications, which has been discussed at length .
I'll let you in on a little secret. A very long time ago, in a galaxym far far away, in the dot com days, there was a project called NSS "Stan" . One of its features was going to be "trust domains" . This would allow a single process using NSS to use multiple sets of trust bits .
The targeted application was for SSL servers running with SSL virtual servers at ISPs. Each virtual server (primarily HTTPS) could have a different set of trust, ie. the ISP could host 6 small businesses on a single server, which all happened to issue certs to their customers, but from a different CA (or sub CA), and require an SSL client auth login . Each virtual server would therefore have a trust domain . Think of it almost like a separate cert database, except the content was not entirely disjoint - each domain would contain the same certs, but not with the same trust bits, hence the name "trust domain" .
It sounds like that model would be suited to your client needs as well : have a trust domain for no security (self-signed certs), another for banking, another for credit card purchases, etc . You could select your trust domain for different browser windows / connections, without it being having to be initiated by a server-side tag or URL .
There was however no real demand for the feature, and not enough manpower working on NSS, so this project was canned . I don't know if it will ever be revived.
However, on the client side, you can achieve a very close result by simply creating multiple browser profiles, each with their own cert database, and having a different set of trust and CAs . Then name those profiles "credit card", "banking", etc . There is no setting for "accept all certs", but you could create one profile called "Mr self-signed certs" and just trust every cert that pops up in it.
Perhaps this separatte profile approach is not elegant, as you can't run multiple Mozilla browser windows in different profiles on the same box due to the IPC, but at least it is possible to work that way. I don't think IE allows anything that comes close - there is only one system cert / trust store .
PS: Oh, well, I suppose there is one thing that we know: the users tend to do their transactions with a site that they are familiar with (banks, transfer agents (paypal, goldmoney), auction houses, etc etc). Funny thing, one of the requirements for SSL was that it protect transactions where the user had no prior relationship, which happens to be an unusual transaction - I mean, who just clicks on a URL and starts filling out a form with their credit card details without doing some checking??? - and not the common transaction that we normally see needing protecting. It is not explained why this is for SSL, just assumed. Just another false premise.
Sorry to say, but I order lots of things in the middle of the night online with SSL transactions when the businesses are closed, and often with little to no possible checking at those hours. Those transactions usually start at sites like "www.pricewatch.com" where I'll look for something and find who is the most affordable merchant, and order it from their SSL site (I always move on if the merchant does not have one). It is almost always the case that I have never heard of the company I'm buying from before. I suspect many other people do the same. Those transactions are protected first by SSL, and second by my credit card company. Without the first protection, I would not be conducting any of that business online, even with the second protection in place. It's just too painful to deal with disputing card charges for someone you have actually done business with, let alone someone you haven't .
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
