On Monday 24 March 2003 11:37, Peter Clay wrote:
> On Sun, 23 Mar 2003, Ian Grigg wrote:
> > Consider this simple fact:  There has been no
> > MITM attack, in the lifetime of the Internet,
> > that has recorded or documented the acquisition
> > and fraudulent use of a credit card (CC).
> > 
> > (Over any Internet medium.)
> How do you view attacks based on tricking people into going to a site
> which claims to be affiliated with e.g. Ebay or Paypal, getting them to
> enter their login information as usual, and using that to steal money?

Yes, that's definately an attack.  As
was pointed out, the use of the cert
seems to do two things:  stop the
MITM (via a secured key exchange so
the listener cannot see inside the
packets) and confirm the site as per
what is stated in the URL.

My post of last night addressed the
MITM only.  I completely ignored the
issue of spoofing, which would only
be possible if there is no complex
relationship between them - which is
a debateable point.

> It's not a pure MITM attack, but the current system at least makes it
> possible for people to verify with the certificate whether or not the site
> is a spoof.

Does the cert stop spoofing?  That's
the question!  If it does, then there
might be value there.  In which case
we can measure it and construct a cost-
benefit analysis to decide whether to
protect against it.

> > So, let's guess the cost of each CC lost to our
> > MITM as $1000.  (Pick your own number if you
> > don't like that one.)
> > 
> > Then, how many attacks?  None, from the above.
> > 
> > Multiplied together, and you get ... nothing.
> So, you claim that a system designed to make MITM attacks impossible has
> not suffered a successful MITM attack. Sounds rather tautologous to me.

No, there has been little evidence of MITMs
*outside* the system.  (I said none, Steve
Bellovin said some...)

The fact that there are none within the
system, yes, that would only show either
the attacks were defeated, or there weren't
going to be any, or that there are better
pickings elsewhere...  It doesn't allow
you to conclude anything about the need
for protection.

Check Lynn Wheeler's new post (thanks Lynn!)
which points to a lot of inside knowledge
about the absence of any aggressive MITM
activity inside the credit card world.

And, see Steve Bellovin's post for some
evidence of MITM outside the credit card

> > The software mandates it:  mostly the browsers,
> > but also the servers, are configured to kick up
> > a stink at the thought of talking to a site that
> > has no certificate.
> > As such, SSL, as implemented, shows itself to
> > include a gross failure of engineering.
> The system was engineered very well to requirements with which you
> disagree.

:-)  Terms are always debatable!  I'd say that
engineering *includes* the appropriateness
of the requirements.  Science does not.

Where I would agree:  the _protocol_ was engineered
very well to meet its requirements.  It's not a bad
protocol, by any logic.  However, no protocol
exists within a vacuum, this one exists within a
_system_ that is commonly also known as SSL.

(Therein lies a big problem here:  I know of no
separate term to distinguish SSL the protocol
from SSL, the secure browsing system that
you or I use to send our credit card numbers

> > [2] AFAIR, Anonymous-Diffie-Hellman, or ADH, is
> > inside the SSL/TLS protocol, and would represent
> > a mighty fine encrypted browsing opportunity.
> > Write to your browser coder today and suggest
> > its immediate employment in the fight against
> > the terrorists with the flappy ears.
> Just out of interest, do you have an economic cost/benefit analysis for
> the widespread deployment of gratuitous encryption?

No, but it would be an interesting exercise!

> It's just not that important.

It's interesting that you say that ... why is it
then that people like Ben Laurie, Eric Young,
Eric Rescola and others spent years writing
and deploying software for free?  Why do the
people at Safari and Mozilla and Konqueror
also spend all that time getting SSL to work?

I don't claim to know the answer.  But, if
their answer is "to protect credit card numbers"
well, actually, I don't think so!

And that's the point of the rant:  to identify
some of these underlying assumptions like "SSL
protects your credit card numbers" and reveal
the truth or otherwise.

Hopefully, if we can strip out the myths,
we'll find the truth.

> If your browsing privacy is important,
> you're prepared to click through the alarming messages. If the value of
> privacy is less than the tiny cost of clicking "accept this certificate
> forever" for each site, then it's not a convincing argument for exposing
> people who don't understand crypto to the risk of MITM.

People don't think like us techies do.  They see
the messages, and they ask for explanations
from other people.  Who may or may not know
what it all means.  The end result is the lowest
common denominator - if there is a message,
then something is wrong.

And that's the point:  if there is nothing wrong,
the browser shouldn't say there is something

So, what is this "risk of MITM" that the browser
is protecting us against?


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to