Tom Otvos wrote:

> As far as I can glean, the general consensus in WYTM is that MITM attacks are very 
> low (read:
> inconsequential) probability.  Is this *really* true?

The frequency of MITM attacks is very low, in the sense
that there are few or no reported occurrences.  This
makes it a challenge to respond to in any measured way.

> I came across this paper last year, at the
> SANS reading room:
> I found it both fascinating and disturbing, and I have since confirmed much of what 
> it was
> describing.  This leads me to think that an MITM attack is not merely of academic 
> interest but one
> that can occur in practice.

Nobody doubts that it can occur, and that it *can*
occur in practice.  It is whether it *does* occur
that is where the problem lies.

The question is one of costs and benefits - how much
should we spend to defend against this attack?  How
much do we save if we do defend?

[ Mind you, the issues that are raised by the paper
are to do with MITM attacks, when SSL/TLS is employed
in an anti-MITM role.  (I only skimmed it briefly I
could be wrong.)  We in the SSL/TLS/secure browsing
debate have always assumed that SSL/TLS when fully
employed covers that attack - although it's not the
first time I've seen evidence that the assumption
is unwarranted. ]

> Having said that then, I would like to suggest that one of the really big flaws in 
> the way SSL is
> used for HTTP is that the server rarely, if ever, requires client certs.  We all 
> seem to agree that
> convincing server certs can be crafted with ease so that a significant portion of 
> the Web population
> can be fooled into communicating with a MITM, especially when one takes into account 
> Bruce
> Schneier's observations of legitimate uses of server certs (as quoted by Bryce 
> O'Whielacronx).  But
> as long as servers do *no* authentication on client certs (to the point of not even 
> asking for
> them), then the essential handshaking built into SSL is wasted.
> I can think of numerous online examples where requiring client certs would be a good 
> thing: online
> banking and stock trading are two examples that immediately leap to mind.  So the 
> question is, why
> are client certs not more prevalent?  Is is simply an ease of use thing?

I think the failure of client certs has the same
root cause as the failure of SSL/TLS to branch
beyond its "mandated" role of "protecting e-
commerce."  Literally, the requirement that
the cert be supplied (signed) by a third party
killed it dead.  If there had been a button on
every browser that said "generate self-signed
client cert now" then the whole world would be
using them.

Mind you, the whole client cert thing was a bit
of an afterthought, wasn't it?  The orientation
that it was at server discretion also didn't help.

> Since the "Internet threat
> model" upon which SSL is based makes the assumption that the channel is *not* 
> secure, why is MITM
> not taken more seriously?

People often say that there are no successful MITM
attacks because of the presence of SSL/TLS !

The existance of the bugs in Microsoft browsers
puts the lie to this - literally, nobody has bothered
with MITM attacks, simply because they are way way
down on the average crook's list of sensible things
to do.

Hence, that rant was in part intended to separate
out 1994's view of threat models to today's view
of threat models.  MITM is simply not anywhere in
sight - but a whole heap of other stuff is!

So, why bother with something that isn't a threat?
Why can't we spend more time on something that *is*
a threat, one that occurs daily, even hourly, some

> Why, if SSL is designed to solve a problem that can be solved, namely
> securing the channel (and people are content with just that), are not more people 
> jumping up and
> down yelling that it is being used incorrectly?

Because it's not necessary.  Nobody loses anything
much over the wire, that we know of.  There are
isolated cases of MITMs in other areas, and in
hacker conferences for example.  But, if 10 bit
crypto and ADH was used all the time, it would
still be the least of all risks.


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

Reply via email to