Julien,
I hope you don't think I'm beating down on this for
light conversation! The SSL infrastructure there is
very important. And it needs some improvement. Not
much, luckily. That's what this is all about.
> [EMAIL PROTECTED] wrote:
> 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 .
SET failed on (other) merits. I think it is reasonable
to conclude from its history that SSL was not built
along the lines of protecting credit cards, and SET's
existence is one indicator. If you want more info,
I suggest the place to go is Lynn Wheeler's site where
he documents in vast quantity the issues involved.
The point relates solely to whether we know what the
usage is - we don't, and the original designers ditched
that notion as part and parcel of their decision to
create a general purpose, connection oriented protocol,
instead of designing something fit for the specific
purpose of protecting credit card transactions. See
comments at end about the first-click-get-cert.
As to pointing to something better than SSL, that's
not my intention: here we are. SSL is deployed in
the browser. The browser has weaknesses in security.
How can we fix that? Throw out SSL? I don't think
so. Throw out certs? Neither so. Let's do some
minor tweaks that are compatible and don't hurt any
stuff that's out there.
>> 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 .
Paranoia is expensive. It's especially expensive when
others who don't know enough about your own risks do
the paranoia for you. It excludes, and this is its
biggest cost: it denies people security, because what
people would do "isn't good enough" for those playing
God.
Risk analysis is much better. But, this is only really
useful when those who can know the risks can deal in
them.
Paranoia is also tremendously embarressing when it has
been got wrong, as it is now, with browser security
breaches causing headaches. These insecurities perpetuate
in part because the security people say their part is
secure - which is the false sense of security that HTTPS
(and SSL) creates that I mentioned the other day.
Also, the only justification for this paranoia is the
claim that "we know better." Which, had generally better
be right! This of course is the fear - when people
realise how wrong it is, then the crypto people are in
danger of being bypassed as the default security experts.
>> 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
> .
No, what I am getting to is that it is not possible
in a high security sense to create a one size fits
all approach. It fine for low security, which is
what the browser delivers. But, when that approach
gets challenged by a sophisticated attacker, it falls.
In order to raise the security to anything like what
some people perceive it should be, the user has to
be engaged in the security cycle. This means
expanding the lock, sorry about that!
> 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 .
Well, those are all interesting ideas, although I don't
see why they would help. If I think of the user in my mind,
the only way to close the loop on the security equation
is to do the branding (insert prior blah blah here).
OTOH, if one were to create more domains, trust, or other
spaces that were centrally or remotely administered for
various reasons, I'd say that wouldn't add to the security,
but it might meet some specific needs in making the
existing infrastructure easier to deploy on a large scale.
>> 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 .
Ah, well! In the world I come from, it is as I
describe, as an observation. In your world, as
you describe. That goes to show that we simply
don't have much of a clue as to how people work,
and there are disjoint communities out there that
don't know each other's patterns.
BTW, I'd not agree with your implication that
you have no prior relationship nor do checking;
you do, through these ways:
* pricewatch knows all these sites, and you
know pricewatch
* you know your credit card company, and you
know you can chargeback (BTW, as a question,
do you use a non-chargebackable debit card
for these unknown sites?)
* you spend some time on each site clicking
around on the goods, and checking out the
conditions. That's a technical relationship
which could have been used to deliver a
cert in the very first click! Which would
have put you into the SSH model - very hard
but not impossible to MITM.
Even though you never heard of these companies,
you have relationships which you use to make sure
they are good. So I stand by the original claim!
iang
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
