Hi Nelson,
Nelson B wrote:
I wasn't asking "what do you think is the cause of a low
incidence of eavedropping", but rather "on what evidence do you
gather that there is not a high incidence of eavesdropping?"
Ah, the evidence of the busts. There is a continuous
series of bad guys getting caught, and they are always
doing it only a few ways. Either it's a hacked box,
or an insider job. Choicepoint was a variant on the
latter of course. A new variant that is starting to
make the rounds is key loggers and so forth extracting
the information from the user's machine.
This isn't "conclusive" but it's pretty darn close;
reports of anyone eavesdropping stand out a mile, in
fact I've never come across a validated one, and I
sort of gave up expecting it in the later half of
the 90s. People who work in credit card processing
companies have confirmed that they've never ever
heard of a case.
(On this very group a year back someone mentioned
that there was some case where a student had had her
CC sniffed in a dorm situation. And occasionally
we hear about the sysadm who got sacked for reading
people's email - from their on-disk email boxes.)
I think (based on your repeated references to credit cards) that
it is due to an absence of widespread reports of stolen CC numbers
that are attributed to network snooping. But that's not the most
relevant indicator.
That's it. Just the laws of incredulity; if you
never ever hear about it then it isn't happening,
unless you also believe in UFOs, ESP and the return
of Elvis.
What is the most relevent factor?
Finally, there is this factor - for every attack, you get
a low likelihood of success, and a high work effort. You
have to scan many sessions to get one lousy credit card.
That's easy for the bad guys to solve. Filter the traffic by IP
addreses of known banks and merchants. Traffic to/from banks
will contain LOTS of gold. They don't want just CC numbers.
Knowldge about what books you buy, who much you spend on clothes
at upscale merchants, ... it's all very sellable.
Easy to *technically* solve, but they don't have
access to that traffic, unless they are in an ISP,
in which case ... a) they are probably not the
right person, and b) running datamining on customers
at the ISP is something that others in the ISP are
likely to notice at some point.
Mind you ... I'm prepared to be persuaded - you say
that all this information is readily sellable - can
you offer any evidence, any anecdotes?
We are as a security community desparate for some
data points on this... I occasionally grill people
who should know and they can't come up with any.
Well, that's another thing, that's called marketing,
or as you mentioned in the other example, national
policy. Are you suggesting that Mozilla Foundation
take a stance on these things?
In fact, today, mozilla empowers users with the tools to
detect and avoid these things. The SSH model doesn't.
I'm sorry, I can't keep up. I looked up this
quote, and it seems we are talking about the
Chinese ISP scenario, where the user has to
download the ISP's software and install that,
and/or root keys.
So obviously, no detection is needed ... and
avoidance would likely put ones life & liberty
in danger. I think I prefer the SSH model :)
But I don't know what it is you are saying there.
Where it is in the agreement, it is a thing that can
be accepted by the user or rejected. We should be
careful not to confuse our threat models with what's
written in the contract and doesn't appeal to our
sensibilities, and what's an aggressive and unexpected
attack.
The contracts never specifically mention SSL MITM. They say
(paraphrased) "You give us the right to see all your traffic"
and "SSL will still work". The user reads those and concludes
that that means that SSL is still secure end-to-end between
himself and his bank, but it isn't. Today, mozilla's warnings
will still alert the user to this MITM. SSH-style cert
acceptance does not.
This is a distinct example to the Chinese
scenario? So this is a marketing company
that somehow got the user to sign up to a
proxy service?
You said above that mozilla avoids those
things and now you say that the SSL isn't
secure?
Also, in that scenario if the proxy returns
a CA signed certificate and does an MITM,
this would result in a popup and a status
bar display of the proxy domain name, right?
SSH - you might have the wrong idea about
what is being suggested there. In discussions
of SSH style acceptance, the notion is to
augment or add the caching of history to the
existing regime. So a user can 'start' a
cache with the gmail cert. The cert itself
should still be checked for valid signing,
indeed before being cached. It's only if
the cert is substituted for another that
we get interested in who signed that new
cert, and to compare it to the signatory
on the previous cert.
Buying merchandise paid for with stolen CC's is not a sustainable
long term business model, because the users detect the theft from
the bogus purchases that appear on their statements.
! Credit card fraud has been runnning at around
0.1 to 1% since ... forever. I'm not sure how
much more sustainable that can get. Any credit
card whizzes here who can give us some figures?
Selling info about consumers with large bank balances to merchants
who are not required under law to reveal their sources is a very
sustainable business plan.
Ah. Sure, but mostly they acquire the information
using legal methods. Their existence doesn't mean
that they use illegal methods.
I knew a guy who did this; it was all totally legal,
and it was very very legal deliberately, because he
had a lot of enemies who wanted to shut him down.
Only by being very careful was he able to keep going.
The distinctions are these:
* each CC is hard to get, a needle in a packet haystack
Only petty thieves want mere CC numbers. The big money and
long term money is in selling info.
Stolen info? Can you offer any anecdotes? How
much is it worth, for example?
Peter Gutmann reported in some recent slides that
CC infor was down below a dollar per. So maybe
you are right in that credit cards are so open
that they aren't worth anything.
Doesn't that tell you something?
* techies aren't the type to do it
* crunching 40bits or doing MITMs is kind of obvious
over the long term.
Not really. It's been going on for years. Few have noticed, and
some in this newsgroup have even denied that it is going on.
Show us some evidence. I'm very keen to hear it.
Literally, if there's never been a bust then I
doubt it is going on. Statistics is very powerful,
it can get that sort of broad hint right. We are
talking about a billion users of the net, and
millions of merchants ...
(Anyway, don't forget nobody much uses 40 bit and
that was a hypothetical though experiment. If
there's anyone doing any MITMing or crunching of
128 bit or etc etc ... just exactly is it that
they are doing to breach SSL ?)
I'd be very careful to distrust marketing information
spread about by people who have a vested interest in
selling security gear. They are known to hyperventilate
at the sight of an innocent customer.
And there are proxies operating now that do real MITM attacks
against SSL that passes through them. To use these proxies,
you must agree to an end user agreement and download their
software that installs their root CA cert. The end user agreement
prevents the user from taking any action against them for their
snooping. The user even agrees to "hold them harmless" against
any legal action that might come against them as a result of the
user blowing the whistle. Recent reports say there are tens of
thousands of users of it.
Right, but we've excluded them, right?
I don't think so. How have we excluded them?
We have excluded them from the class of cert attackers
because they do it with the agreement of the users.
The unwitting agreement of the users. Like I said, they don't come
out and say that they're MITMing SSL. They say "SSL will still work"
and leave the user to assume that that means that SSL will still
protect him from their snooping.
OK. So up in layer 7-9, they lied to the
customer.
BTW do they say "SSL will still work?" Or
do they say "Your access to SSL-based
services will be unimpaired?"
I'll bet they've thought about this...
They are not attackers, they are participants, insiders.
The users install their root cert - that's what you said, right?
The users run an installer program to get the supplier's "software",
never realizing that they're installing a bogus root cert that
defeats SSL's MITM protections for them. (These schemes primarily
target IE users today, because Windows has an API by which any
little program can install root CA certs silently.)
So ... you're saying that Mozilla should not allow
changes to the root list?
People who are really interested in the security of the average
end user advise end users NOT to install ISPs' software.
It would help if you'd just come out and say who's
doing this stuff. It's really difficult to follow
when we only hear half the picture. I'm still not
clear whether Mozilla defeats this attack or not.
Whatever Mozilla provides these users with, the ISP
says, we don't care, just let us read your encrypted
traffic. Right? They are excluded therefore from
our view of the threat model.
We exclude them because they demand to read encrypted traffic?
Well, I thought you were talking about the Chinese
government there. So, it kind of depends on who
you are talking about. But fundamentally, if the
user *knows* what is going on, and agrees to carry
on anyway, that's no longer a threat. So, yes,
they are excluded. Mozilla should try and give the
best tools to the user, but any tool can be used
for good and bad. We are not on a mission from God,
we just make browsers if the user chooses to use
them.
(When I say we, I'm not being literal. :)
One of them has a WebTrust seal. Although they have not yet
approached mozilla to be admitted as a CA (AFAIK), if they did so,
on what basis in the present policy draft would they be denied?
Hint: think policy floor.
So, they are like another big CA that is in the root
list already - that has a stated objective that puts
it in conflict with the users of its certificates? I've
written elsewhere on who this might be.
Are you being sarcastic? or
Are you arguing that mozilla should let all issuers of certs into
the list because there's one with a policy that you find to be in
conflict with the users' interests?
No, I'm saying these are difficult questions. If the
CA has indicated to its users what it is up to, then
that covers the policy. If it has hidden this from
the users, then that's another issue - that's like
lying, or in legal terms it is a material non-disclosure.
That's why I for one argue that there is no point in
being too harsh on any CA, because of course they are
on their best behaviour before they are let in, and
they'll abuse it afterwards ... and dare Mozilla to
act.
Better to craft a policy that survives abuse without
undue stress on Mozilla, which hasn't the resources
to police the CAs.
Seems like letting in untrustworthy CAs suits the purposes of
advancing the SSH-style cert use proposal very well. Let in
untrustworthy CAs, wait for the inevitable disaster, then declare
that CA-based PKI is discredited and that SSH-style was the answer
all along.
LOL... everyone loves a good conspiracy, and I know
it's Saturday night and all, but think about it for
a bit.
SSH style caching is being being proposed in *addition*
to the existing cert based regime. At no time has anyone
on this list said "oh, golly, let's rip out the certificate
stuff and replace it with SSH." That's a complete non-
starter.
(Although, on some other lists out there, people have
said exactly that. Good for them, I say!)
Is that an example of "thinking several moves ahead"?
I think your example shows you several moves behind!
Here's the strategy:
a. add stuff to the chrome to force SSL to be obvious,
so that's Gervase and HJ's extra colours and bars and
what have you.
b. when that works, phishers will start acquiring
duff certs from dodgy issuers. So the brand of the
CA should be on the chrome. That's because of a very
simple thing: a CA can check his own DB for any
phishing attempt, but he has more trouble getting
access to anyone elses.
c. as well as that, give the user some opportunities
to mark her handful of favourites. With petnames, or
even better with logos like the TrustBar.
Then, the phisher has to fight a) the fact the cert
will force him to enter into the business loop, and
b) the only easy certs come from some other CA, so
the brand changes on the user's chrome, and c) if
it is a valuable relationship, she may well have
named it specially and locally.
Certs + local naming + CA policing. Sounds pretty
powerful to me, I'm not sure what there is that is
evil and insidious about it.
If it has the WebTrust it's in. If not, then it has to
follow the alternates that have been worked out by this
group.
I'm not sure if you're endorsing that view, or if you're
criticizing it, or merely saying you think that's what the
current policy says.
That's where it is right now, in terms of the draft
that Frank is preparing for MoFo.
Or, are you saying that MoFo should be in the judgement business?
No, I'm saying there should be a well written policy that contains
specific provisions that keep phony CAs operated by MITMs out.
And it doesn't appear to me that WebTrust by itself suffices.
Well, hoorah! as the marines say. That's a very
big admission by you - that WebTrust by itself may
not suffice.
Right, exactly. That's what the policy was aiming
at all along - WebTrust or even its equivalents is
not sufficient to conquer this beast; we need some
other stuff.
And, while that other stuff is coming along, there
isn't much point in holding back the policy in the
vein hope that some silver bullet will come along.
We've batted this around for the last two weeks,
and I haven't seen any objective way of tying user
security to policy. I know a lot of things have
been proposed, but none of them have stood up to
scrutiny.
Judgement won't fly. We've clearly set our goals as the
average user, and if enough average users decide to take
up the kind offer of a benevolent ISP then ... the
average user has spoken! That's that!
I guess you're using sarcasm.
Surely you're not suggesting that we lower our ability to protect
users' information to levels where they no longer protect end users
against attacks that the common end user does not understand, just
because the ends users do not understand it!
Unfortunately, it is not up to Mozilla Foundation
to provide protection where the user has signed on
to an unprotected regime. No matter how dumb you
think that is, if Mozilla were to interfere with
the contractual arrangement between the user and
the ISP or whoever, then it would place Mozilla in
a very sticky position, legally speaking.
On the other hand, if they haven't signed on to
such, then protection can and should be offered.
But I'm unclear which of the two scenarios you are
proposing here. Before you quoted (paraphrased):
"You give us the right to see all your traffic"
That's pretty clear. For Mozilla to intefere with
that right would put Mozilla into damages. Is that
what you are proposing?
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
