SSL, client certs, and MITM (was WYTM?)
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. -- Tom Otvos Don't think you are. Know you are. - Morpheus - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: SSL, client certs, and MITM (was WYTM?)
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. The CC number is clearly not hidden if there is a MITM. I think the I got my money so who cares where it came from argument is not entirely a fair representation. Someone ends up paying for abuses, even if it is us in CC fees, otherwise why bother encrypting at all? But that is besides the point. 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. These are, I think, more important examples and again, if there is a MITM, then doing additional authentication post-channel setup is irrelevant. These can be easily replayed after the attack has completed. The authentication *should* be deeply tied to channel setup, should it not? Or stated another way, having chained authentication where the first link in the chain is demonstrably weak doesn't seem to achieve an awful lot. 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). Fascinating! Can you please tell me what bank that was? -- tomo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: SSL, client certs, and MITM (was WYTM?)
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. Or, whether it gets reported if it does occur. 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? Absolutely true. If the only effect of a MITM is loss of privacy, then that is certainly a lower-priority item to fix than some quick cash scheme. So the threat model needs to clearly define who the bad guys are, and what their motivations are. But then again, if I am the victim of a MITM attack, even if the bad guy did not financially gain directly from the attack (as in, getting my money or something for free), I would consider loss of privacy a significant thing. What if an attacker were paid by someone (indirect financial gain) to ruin me by buying a bunch of stock on margin? Maybe not the best example, but you get the idea. It is not an attack that affects millions of people, but to the person involved, it is pretty serious. Shouldn't the server in this case help mitigate this type of attack? 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 times? I take your point, but would suggest isn't a threat be replaced by doesn't threaten the majority. And are we at a point where it needs to be a binary thing -- fix this OR that but NOT both? -- tomo - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
