Using crypto against Phishing, Spoofing and Spamming...

Ian Grigg iang at systemics.com
Tue Jul 20 02:07:49 EDT 2004


Steve,

thanks for addressing the issues with some actual
anecdotal evidence.  The conclusions still don't
hold, IMHO.


Steven M. Bellovin wrote:
> In message <40FA611F.8030403 at systemics.com>, Ian Grigg writes:

>>Right...  It's easy to claim that "it went away"
>>because we protected against it.  Unfortunately,
>>that's just a claim - there is no evidence of
>>that.
>>
>>This is why I ask whether there has been any
>>evidence of MITMs, and listening attacks.  We
>>know for example that there were password
>>sniffing attacks back in the old days, by
>>hackers.  Hence SSH.  Costs -> Solution.
>>
>>But, there is precious little to suggest that
>>credit cards would be sniffed - I've heard one
>>isolated and unconfirmable case.  And, there is
>>similar levels of MITM evidence - anecdotes and
>>some experiences in other fields, as reported
>>here on this list.
>>
> 
> 
> I think that Eric is 100% correct here: it doesn't happen because it's 
> a low-probability attack, because most sites do use SSL.

The trick is to show cause and effect.  We know the
effect and we know the cause(s).  The question is, how
are they related?  The reason it is important is that
we may misapply one cause if the effect results from
some other cause.

> I think that people are forgetting just how serious the password 
> capture attacks were in 1993-94.  The eavesdropping machines were on 
> backbones of major ISPs; a *lot* of passwords were captured. 

Which led to SSH, presumably, and was pre-credit card
days, so can only be used as a prediction of eavesdropping.

Question - are we facing a situation today whereby it is
easy to eavesdrop from the backbone of a major ISP and
capture a lot of traffic?  As far as I can see, that's
not likely to happen, but it could happen.

Secondly, who were the people doing those attacks?  Back
in 93-94, I'd postulate they weren't criminal types, but
hacker types.  That is, they were hackers looking for
machines.  Those people are still around - defeated by
SSH in large measure - and use other techniques now.
(Hackers had no liability in those days.  Criminals do
have liability, and are more concerned to cover their
tracks.  This makes active attacks less useful to them.
Criminals are getting braver though.)

Thirdly, why aren't we seeing more reports of this on
802.11b networks?  I've seen a few, but in each case,
the attack has been to hack into some machine.  I've
yet to see a case where listeners have scarfed up some
free email account passwords, although I suppose that
this must happen.

The point of all this is that we need to establish how
frequent and risky these things are.  Back in the pre-
commerce days, a certain amount of FUD was to be expected.
Now however, it's been a decade - whether that FUD was
warranted then is an issue for the historians, but now
we should be able to scientifically make a case that
the posture matches the threats.  Because it's been a
decade (almost).

As far as I can see, there *some* justification for
expecting eavesdropping attacks to credit cards.  There
is a lot more justification with unprotected non-commerce.
And in contrast, there is little justification for
expecting active attacks for purposes of theft.



What this leads to is not whether SSL should have been
deployed or changed in its current form (it is fruitless
to debate that, IMHO, except in order to lay down the
facts) but a discussion of certificates.

There seems some justification in suggesting that SSL be
(continued to be) deployed in any form.  Mostly, IMHO,
in areas outside commerce, and mostly, in the future,
not now.

There seems a lot of justfication for utilising certs as
they enable relationship-protection.  There seems quite a
bit of justification for utilising CA-signed certs because
they permit more advanced relationship protection such as
Amir's logo ideas and my branding ideas, and more so every
day.

What there doesn't appear to be any justification for is
the effective or defacto mandating of CA-signed certs.
And there appears to be a quite serious cost involved in
that mandating - the loss of protection from the resultant
*very* low levels of SSL deployment.

This all hangs on the MITM - hence the question of frequency.
It seems to be very low, an extraordinarily desparate attack
for a criminal, especially in the light of experience.  He
does phishing and hacking with ease, but he doesn't like
leaving tracks in the infrastructure that point back to him.

If the MITM cannot be justified as an ever-present danger,
then there is no justification for the defacto mandating of
CA-signed certs.  Permitting and encouraging self-signed
certs would then make deployment of SSL much easier, and
thus increase use of SSL - in my view, dramatically -
which would lead to much better protection.  (Primarily
by relationship management on the client side, and also
by branding/logo management with the CAs, but that needs
to be enabled in code first at the browsers.)

(It has to be said that encouraging anon-diffie-hellman
SSL would also lead to dramatically improved levels of
SSL deployment and thus protection as well.  But since
RFC deprecates that, it simply becomes a higher burden
to show.)

> Furthermore, the technology has improved -- have you looked at dsniff 
> lately, with the ARP-based active attack capability?  And credit cards 
> are much easier to grab -- they're probably sent in one packet, instead 
> of several, and the number is a self-checking string of digits.

Well, I think the thing here would be that credit cards
are sent in forms, so POSTs, and some sort of scanning
and interpretation would be required.  If it was an issue,
it would be a mildly interesting problem to design and
test scanning software.  But it's not an issue, so we
don't hear of it.  I believe the reason we don't hear of
it is that even over the open nets, the notion of scanning
for masses of credit cards would be too risky.  Poor ROI,
to use Lynn's term.  I think eavesdropping is a much bigger
risk for other purposes, and deploying more SSL would address
that.  But, for reasons outlined logic above, deployment of
SSL remains constrained.

> It's also worth remembering that an SSL-like solution -- cryptographically 
> protecting the transmission of credit card number, instead of digitally 
> signing a funds transfer authorization linked to some account -- was 
> more or less the only thing possible at the time.  The Internet as a 
> medium of commerce was too new for the banks to have developed 
> something SET-like, and there wasn't an overwhelmingly-dominant client 
> platform at the time for which custom software could be developed.  
> (Remember that Windows 95 was the first version with an integral TCP/IP 
> stack.)  *All* that Netscape could deploy was something that lived in 
> just the browser and Web server.  SET itself failed because the 
> incentives were never there -- consumers didn't perceive any benefit to 
> installing funky software, and merchants weren't given much incentive 
> to encourage it.

(That's plausible, and has some good observations which
I'd love to debate but feel the need to focus on SSL and
now and low levels of deployment and thus protection.)

iang

PS: in all the above I refer to SSL as the protocol,
sans key exchange.

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



More information about the cryptography mailing list