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 [EMAIL PROTECTED]
