SSL, client certs, and MITM (was WYTM?)

[Anne & Lynn Wheeler]

On Wed, 2003-10-22 at 13:46, Tom Otvos wrote:
> I read the "WYTM" thread with great interest because it dovetailed nicely with some research I am
> currently involved in.  But I would like to branch this topic onto something specific, to see what
> everyone here thinks.
> 
> 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?  I came across this paper last year, at the
> SANS reading room:
> 
> 	http://rr.sans.org/threats/man_in_the_middle.php
> 
> 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.  With sufficiently simplified tools this type of attack can readily be
> launched by "script kiddies" or someone only just slightly higher on the hacker evolutionary scale.
> 
> 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?  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?  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?
> 
> Am I missing something obvious here?  I look forward to any comments you might have.


in general SSL domain name certs address

1) is the server I think I'm talking to really the server that I'm
talking to (is the URL I entered match the URL in the certificate)

2) key exchange, for an encrypted session

So what purpose would client certificates address? Almost all of the use
of SSL domain name certs is to hide a credit card number when a consumer
is buying something. There is no requirement for the merchant to
identify and/or authenticate the client .... the payment infrastructure
authenticates the financial transaction and the server is concerned
primarily with getting paid (which comes from the financial institution)
not who the client is.

So, there are some infrastructures that have web servers that want to
authenticate clients (for instance online banking). They currently
establish the SSL session and then authenticate the user with
userid/password against an online database.

In fact is .... one contention is that possibly 99.9999 percent of the
client-based authentication that happens in the world today is done
against some database.

There was an instance of a bank issuing client certificates for use in
online banking. At one time they claimed to have the largest issued PKI
client certificates (aka real PKI as opposed to manufactured
certificates).

However, they discovered

1) the certificates had to be reduced back to relying-party-only
certificates with nothing but an account number (because of numerous
privacy and liability concerns)

2) the certificates quickly became stale

3) they had to look up the account and went ahead and did a separate
password authentication .... in part because the certificates were
stale.

They somewhat concluded that the majority of client certificate
authentication aren't being done because they want the certificates ....
it is because the available COTS software implements it that way (if you
want to use public key) ... but not because certificates are in anyway
useful to them (in fact, it turns out that the certificates are
redundant and superfluous ... and because of the staleness issue
resulted in them also requiring passwords).

So a reasonable suggestion was to ship webservers ....  with a radius
stub for the client authentication interface. The client registers
authentication material (in much the same way that nearly all of the ISP
authentication infrastructures operation).

If the desire is to have something better than passwords or
"shared-secrets" (aka trying to help the world address the huge
propogation of number of shared-secrets per person that is occuring in
the online world), then it would be possible to register a public key in
the radius database ... and authenticate with a digital signature as
opposed to a shared-secret.

A certificate is to address the propagation of trust between two
entities that have had no prior relationship (and possibly may never in
the future have any sort of relationship) and there is not any other
kind of recourse ....  it is purely possible to have digital signature
strong authentication when certificates aren't involved in anyway
what-so-ever.


If you eliminate all the scenarios where the entities have no prior
relationship and/or have no recourse to an online service then you are
pretty much done to a zero set. The scenario with a random customer at a
random merchant website ... never before visited ... the merchant is
interested in getting paid .... the customer contacts their bank (prior
business relationship), the customer bank contacts the merchant bank
(prior business relationship), and the merchant bank contacts the
merchant (prior business relationship) .... to tell the merchant that
they will get paid (aka the real-time response from the financial
infrastructure means a lot more to the merchant than anything that a
random, unknown consumer might claim ... regardless of any possible
redundant and superfluous certificate that might be involved). 


-- 
Anne & Lynn Wheeler -  http://www.garlic.com/~lynn/

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