"SSL stops credit card sniffing" is a correlation/causality myth

[Ian G]

On Tuesday 31 May 2005 21:03, Perry E. Metzger wrote:
> Ian G <iang at systemics.com> writes:
> > On Tuesday 31 May 2005 02:17, Steven M. Bellovin wrote:
> >> The next part of this is circular reasoning.  We don't see network
> >> sniffing for credit card numbers *because* we have SSL.
> >
> > I think you meant to write that James' reasoning is
> > circular, but strangely, your reasoning is at least as
> > unfounded - correlation not causality.  And I think
> > the evidence is pretty much against any causality,
> > although this will be something that is hard to show,
> > in the absence.
> >
> >  * AFAICS, a non-trivial proportion of credit
> > card traffic occurs over totally unprotected
> > traffic, and that has never been sniffed as far as
> > anyone has ever reported.
>
> Perhaps you are unaware of it because no one has chosen to make you
> aware of it. However, sniffing is used quite frequently in cases where
> information is not properly protected. I've personally dealt with
> several such situations.


This leads to a big issue.  If there are no reliable reports,
what are we to believe in?  Are we to believe that the
problem doesn't exist because there is no scientific data,
or are we to believe those that say "I assure you it is a
big problem?"

It can't be the latter;  not because I don't believe you in
particular, but because the industry as a whole has not
the credibility to make such a statement.  Everyone who
makes such a statement is likely to be selling some
service designed to benefit from that statement, which
makes it very difficult to simply believe on the face of it.

The only way we can overcome this issue is data.  If
you have seen such situations, document them and
report them - on forums like these.  Anonymise them
suitably if you have to.

Another way of looking at this is to look at Choicepoint.
For years, we all suspected that the real problem was
the insider / node problem.  The company was where
the leaks occurred, traditionally.

But nobody had any data.  Until Choicepoint.  Now we
have data.  We know how big a problem the node is.
We now know that the problem inside the company is
massive.

So we need to see a "Choicepoint" for listening and
sniffing and so forth.  And we need that before we can
consider the listening threat to be economically validated.


> Bluntly, it is obvious that SSL has been very successful in thwarting
> certain kinds of interception attacks. I would expect that without it,
> we'd see mass harvesting of credit card numbers at particularly
> vulnerable parts of the network, such as in front of important
> merchants. The fact that phishing and other attacks designed to force
> people to disgorge authentication information has become popular is a
> tribute to the fact that sniffing is not practical.

And I'd expect to see massive email scanning by
now of say lawyer's email at ISPs.  But, no, very
little has occurred.

> The bogus PKI infrastructure that SSL generally plugs in to is, of
> course, a serious problem. Phishing attacks, pharming attacks and
> other such stuff would be much harder if SSL weren't mostly used with
> an unworkable fake PKI. (Indeed, I'd argue that PKI as envisioned is
> unworkable.)  However, that doesn't make SSL any sort of failure -- it
> has been an amazing success.

In this we agree.  Indeed, my thrust all along in
"attacking PKI" has been to get people to realise
that the PKI doesn't do nearly as much as people
think, and therefore it is OK to consider improving
it.  Especially, where it is weak and where attackers
are attacking.

Unfortunately, PKI and SSL are considered to be
sacrosanct and perfect by the community.  As these
two things working together are what protects people
from phishing (site spoofing) fixing them requires
people to recognise that the PKI isn't doing the job.

The cryptography community especially should get
out there and tell developers and browser implementors
that the reason phishing is taking place is that the
browser security model is being bypassed, and that
some tweaks are needed.

> >  * We know that from our experiences
> > of the wireless 802.11 crypto - even though we've
> > got repeated breaks and the FBI even demonstrating
> > how to break it, and the majority of people don't even
> > bother to turn on the crypto, there remains practically
> > zero evidence that anyone is listening.
>
> Where do you get that idea? Break-ins to firms over their unprotected
> 802.11 networks are not infrequent occurrences. Perhaps you're unaware
> of whether anyone is listening in to your home network, but I suspect
> there is very little that is interesting to listen in to on your home
> network, so there is little incentive for anyone to break it.

Can you distinguish between break-ins and sniffing
and listening attacks?  Break-ins, sure, I've seen a
few cases of that.  In each case the hackers tried to
break into an unprotected site that was accessible
over an unprotected 802.11.

My point though is that this attack is not listening.
It's an access attack.  So one must be careful not
to use this as evidence that we need to protect
data from being listened to.

> >> As for DNS hijacking -- that's what's behind "pharming" attacks.  In
> >> other words, it's a real threat, too.
> >
> > Yes, that's being tried now too.  This is I suspect the
> > one area where the SSL model correctly predicted
> > a minor threat.  But from what I can tell, server-based
> > DNS hijacking isn't that successful for the obvious
> > reasons
>
> You are wrong there again.
>
> Where are you getting your information from? Whomever your informant
> is, they're not giving you accurate information.

I've seen a few reports of DNS hijacking for phsishing over
the last year.  In each case that I saw, the eventual conclusion
was that it wasn't a sensible attack, it was under control,
and the attacker did himself mischief by potentially leading
the ISPs back to him.

However I was specifically interested in phishing - attacks
of direct economic theft - rather than nuisance attacks or
attacks related to indirect economic effects such as access
or DOS, etc.  I know a lot of that goes on.

It if is anything other than that, let us know.  We need
more data.  Without the data it's just more FUD.  Schechter
and Smith's FC03 paper went further and suggests that lack
of data is part of the problem of security.

iang
-- 
Advances in Financial Cryptography:
   https://www.financialcryptography.com/mt/archives/000458.html

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com