Re: SSL, client certs, and MITM (was WYTM?)
Tom Weinstein wrote: The economic view might be a reasonable view for an end-user to take, but it's not a good one for a protocol designer. The protocol designer doesn't have an economic model for how end-users will end up using the protocol, and it's dangerous to assume one. This is especially true for a protocol like TLS that is intended to be used as a general solution for a wide range of applications. I agree with this. Especially, I think we are all coming to the view that TLS/SSL is in fact a general purpose channel security protocol, and should not be viewed as being designed to protect credit cards or e-commerce especially. Given this, it is unreasonable to talk about threat models at all, when discussing just the protocol. I'm coming to the view that protocols don't have threat models, they only have characteristics. They meet requirements, and they get deployed according to the demands of higher layers. Applications have threat models, and in this is seen the mistake that was made with the ITM. Each application has to develop its own threat model, and from there, its security model. Once so developed, a set of requirements can be passed on to the protocol. Does SSL/TLS meet the requirements passed on from on high? That of course depends on the application and what requirements are set. So, yes, it is not really fair for a protocol designer to have to undertake an economic analysis, as much as they don't get involved in threat models and security models. It's up to the application team to do that. Where we get into trouble a lot in the crypto world is that crypto has an exaggerated importance, an almost magical property of appearing to make everything safe. Designers expect a lot from cryptographers for these reasons. Too much, really. Managers demand some special sprinkling of crypto fairy dust because it seems to make the brochure look good. This will always be a problem. Which is why it's important for the crypto guy to ask the question - what's *your* threat model? Stick to his scientific guys, as it were. In some ways, I think this is something that all standards face. For any particular application, the standard might be less cost effective than a custom solution. But it's much cheaper to design something once that works for everyone off the shelf than it would be to custom design a new one each and every time. Right. It is however the case that secure browsing is facing a bit of a crisis in security. So, there may have to be some changes, one way or another. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
Perry E. Metzger [EMAIL PROTECTED] writes: TLS is just a pretty straightforward well analyzed protocol for protecting a channel -- full stop. It can be used in a wide variety of ways, for a wide variety of apps. It happens to allow you to use X.509 certs, but if you really hate X.509, define an extension to use SPKI or SSH style certs. TLS will accommodate such a thing easily. Indeed, I would encourage you to do such a thing. Actually there's no need to even extend TLS, there's a standard and very simple technique which is probably best-known from its use in SSH but has been in use in various other places as well: 1. The first time your server fires up, generate a self-signed cert. 2. When the user connects, have them verify the cert out-of-band via its fingerprint. Even a lower-security simple phrase or something derived from the fingerprint is better than nothing. 3. For subsequent connections, warn if the cert fingerprint has changed. That's currently being used by a number of TLS-using apps, and works at least as well as any other mechanism. At a pinch, you can even omit (2) and just warn if a key that doesn't match the one first encountered is used, that'll catch everything but an extremely consistent MITM. Using something like SSH keys isn't going to give you any magical security that X.509 certs doesn't, you'll just get something equivalent to the above mechanism. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
- Original Message - From: Tom Otvos [EMAIL PROTECTED] As far as I can glean, the general consensus in WYTM is that MITM attacks are very low (read: inconsequential) probability. I'm not certain this was the consensus. We should look at the scenarios in which this is possible, and the tools that are available to accomplish the attack. I would say that the attack is more easily done inside a local network (outside the network you have to get control of the ISP or some node, and this is more for the elite). But statistics show that most exploits are accomplished because of employees within a company (either because they are not aware of basic security principals, or because the malicious person was an employee within), so I find this scenario (attack from inside the network) to be plausible. Take for an example a large corporation of 100 or more employees, there has got to be a couple of people that do on-line purchasing from work, on-line banking, etc... I would say that it is possible that an employee (just curious, or really malicious) would want to intercept these communications So how difficult is it to launch an MITM attack on https? Very simple it seems. My hacker friends pointed out to me two softwares, ettercap and Cain: http://ettercap.sourceforge.net/ http://www.oxid.it/cain.html Cain is the newest I think, and remarkably simple to use. It has a very nice GUI and it doesn't take much hacking ability to use it. I've been using it recently for educational purposes and find it very easy to use, and I don't consider myself a hacker. Cain allows you to do MITM (in HTTPS, DNS and SSHv1) on a local network. It can generate certificates in real time with the same common name as the original. The only thing is that the certificate will probably not be signed by a trusted CA, but most users are not security aware and will just continue despite the warning. So given this information, I think MITM threats are real. Are these attacks being done in practice? I don't know, but I don't think they would easily be reported if they were, so you can guess what my conclusion is... --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: SSL, client certs, and MITM (was WYTM?)
Internet groups starts anit-hacker initiative http://www.computerweekly.com/articles/article.asp?liArticleID=125823liArti cleTypeID=1liCategoryID=2liChannelID=22liFlavourID=1sSearch=nPage=1 one of the threats discussed in the above is the domain name ip-address take-over mentioned previously http://www.garlic.com/~lynn/aadsm15.htm#28 which was one of the primary justifications supposedly for SSL deployment (am i really talking to the server that I think i'm talking to). -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
At 07:11 PM 10/22/03 -0400, Perry E. Metzger wrote: Indeed. Imagine if we waited until airplanes exploded regularly to design them so they would not explode, or if we had designed our first suspension bridges by putting up some randomly selected amount of cabling and seeing if the bridge collapsed. That's not how good engineering works. No. But how quickly we forget how many planes *did* break up, how many bridges *did* fall apart, because engineering sometimes goes into new territory. Even now. You start using new composite materials in planes, and wonder why they fall out of the sky when their tails snap off. Eventually (though not yet) Airbus et al will get a clue how they fail differently from familiar metals. Even learning about now-mundane metal fatigue in planes involved breakups and death. (Safety) engineering *is* (unfortunately, but perhaps by practical necessity) somewhat reactive. It tries very hard not to be, but it is. dh - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
I'm not sure how you come to that conclusion. Simply use TLS with self-signed certs. Save the cost of the cert, and save the cost of the re-evaluation. If we could do that on a widespread basis, then it would be worth going to the next step, which is caching the self-signed certs, and we'd get our MITM protection back! Albeit with a bootstrap weakness, but at real zero cost. I know of some environments where this is done. For example to protect the connection to a corporate mail server, so that employees can read their mail from outside of work. The caching problem is easily solved in this case by having the administrator distribute the self-signed cert to all employees and having them import it and trust it. This costs no more than 1 man day per year. This is near 0 cost however, and gives some weight to Perry's argument. Any merchant who wants more, well, there *will* be ten offers in his mailbox to upgrade the self-signed cert to a better one. Vendors of certs may not be the smartest cookies in the jar, but they aren't so dumb that they'll miss the financial benefit of self- signed certs once it's been explained to them. I have a hard time believing that a merchant (who plans to make $ by providing the possibility to purchase on-line) cannot spend something like 1000$ [1] a year for an SSL certificate, and that the administrator is not capable of properly installing it within 1-2 man days. If he can't install it, just get a consultant to do it, you can probably get one that does it within a day and charges no more than 1000$. So that would make the total around 2000$ a year, let's generously round it up to 10K$ annum. I think your 10-100 million $ annum estimate is a bit exaggerated... [1] this is the price I saw at Verisign http://www.verisign.com/products/site/commerce/index.html I'm sure you can get it for cheaper. This was already discussed on this list I think... --Anton - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
Thor Lancelot Simon wrote: Can you please posit an *exact* situation in which a man-in-the-middle could steal the client's credit card number even in the presence of a valid server certificate? Sure. If I can assume you're talking about SSL/https as it is typically used in ecommerce today, that's easy. Subvert DNS to redirect the user to a site under controller of the attacker. Then it doesn't matter whether the legitimate site has a valid server cert or not. Is this the kind of scenario you were looking for? http://lists.insecure.org/lists/bugtraq/1999/Nov/0202.html Can you please explain *exactly* how using a client-side certificate rather than some other form of client authentication would prevent this? Gonna make me work harder on this one, eh? Well, ok, I'll give it a try. Here's one possible way that you might be able to use client certs to help (assuming client certs were usable and well-supported by browsers). Beware: I'm making this one up as I go, so it's entirely possible there are security flaws with my proposal; I'd welcome feedback. When I establish a credit card with Visa, I generate a new client certificate for this purpose and register it with www.visa.com. When I want to buy a fancy hat from www.amazon.com, Amazon re-directs me to https://ssl.visa.com/buy.cgi?payto=amazonamount=$29.99item=hat My web browser opens a SSL channel to Visa's web server, authenticating my presence using my client cert. Visa presents me a description of the item Amazon claims I want to buy, and asks me to confirm the request over that authenticated channel. If I confirm it, Visa forwards payment to Amazon and debits my account. Visa can tell whose account to debit by looking at the mapping between my client certs and account numbers. If Amazon wants to coordinate, it can establish a separate secure channel with Visa. (Key management for vendors is probably easier than for customers.) I can't see any MITM attacks against this protocol. The crucial point is that Visa will only initiate payment if it receives confirmation from me, over a channel where Visa has authenticated that I'm on the other end, to do so. A masquerading server doesn't learn any secrets that it can use to authorize bogus transactions. Does this work? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
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: 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. 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 times? 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. iang - 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?)
On 10/22/2003 04:33 PM, Ian Grigg wrote: The frequency of MITM attacks is very low, in the sense that there are few or no reported occurrences. We have a disagreement about the facts on this point. See below for details. This makes it a challenge to respond to in any measured way. We have a disagreement about the philosophy of how to measure things. One should not design a bridge according to a simple measurement of the amount of cross-river traffic in the absence of a bridge. One should not approve a launch based on the observed fact that previous instances of O-ring failures were non-fatal. Designers in general, and cryptographers in particular, ought to be proactive. But this philosophy discussion is a digression, because we have immediate practical issues to deal with. 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. According to the definitions I find useful, MITM is basically a double impersonation. For example, Mallory impersonates PayPal so as to get me to divulge my credit-card details, and then impersonates me so as to induce my bank to give him my money. This threat is entirely within my threat model. There is nothing hypothetical about this threat. I get 211,000 hits from http://www.google.com/search?q=ID-theft SSL is distinctly less than 100% effective at defending against this threat. It is one finger in a dike with multiple leaks. Client certs arguably provide one additional finger ... but still multiple leaks remain. == The expert reader may have noticed that there are other elements to the threat scenario I outlined. For instance, I interact with Mallory for one seemingly trivial transaction, and then he turns around and engages in numerous and/or large-scale transactions. But this just means we have more than one problem. A good system would be robust against all forms of impersonation (including MITM) *and* would be robust against replays *and* would ensure that trivial things and large-scale things could not easily be confused. Et cetera. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: SSL, client certs, and MITM (was WYTM?)
At 05:08 PM 10/22/2003 -0400, Tom Otvos wrote: 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. the statement was SSL domain name certificate is 1) am i really talking to who I think I'm talking to 2) encrypted channel obviously #1 addresses MITM (am i really talking to who I think I'm talking to). The issue for CC is that it really is a shjared secret and is extremely vulnerable ... as I've commented before 1) CC needs to be in the clear in a dozen or so business processes 2) much simpler to harvest a whole merchant file with possibly millions of CC numbers in about the same effort to evesdrop one off the net (even if there was no SSL) return on investment for approx. same amount of effort get one CC number or get millions 3) all the instances in the press are in fact involved with harvesting large files of numbers ... not one or two at a time off the wire 4) burying the earth in miles of crypto still wouldn't eliminate the current shared-secret CC problem slightly related security proportional to risk: http://www.garlic.com/~lynn/2001h.html#61 so the requirement given the X9 financial standards working group X9A10 http://www.x9.org/ was to preserve the integrity of the financial infrastructure for all electronic retail payment (regardless of kind, origin, method, etc). The result was X9.59 standard http://www.garlic.com/~lynn/index.html#x959 which effectively defines a digitally signed, authenticated transaction no certificate required ... and the CC number used in X9.59 authenticated transactions shouldn't be used in non-authenticated transactions. Since the transaction is now digitally signed transactions and the CC# can't be used in non-authenticated transactions you can listen in on X9.59 transactions and harvest all the CC# that you want to and it doesn't help with doing fraudulent transactions. In effect, X9.59 changes the business rules so that CC# no longer need to be treated as shared secrets. misc. past stuff about ssl domain name certificates http://www.garlic.com/~lynn/subpubkey.html#sslcert misc. past stuff about relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo misc. past stuff about using certificateless digital signatures in radius authentication http://www.garlic.com/~lynn/subpubkey.html#radius misc. past stuff about using certificateless digital signatures in kerberos authentication http://www.garlic.com/~lynn/subpubkey.html#kerberos misc. fraud exploits (including some number of cc related press announcements) http://www.garlic.com/~lynn/subtopic.html#fraud some discussion of early SSL deployment for what is now referred to as electronic commerce http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 -- Anne Lynn Wheelerhttp://www.garlic.com/~lynn/ Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm - 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]
Re: SSL, client certs, and MITM (was WYTM?)
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? I'm not aware of any such consensus. I suspect you'd get plenty of debate on this point. But in any case, widespread exploitation of a vulnerability shouldn't be a prerequisite to deploying countermeasures. If we see a plausible future threat and the stakes are high enough, it is often prudent to deploy defenses in advance against the possibility that attackers. If we wait until the attacks are widespread, it may be too late to stop them. It often takes years (or possibly a decade or more: witness IPSec) to design and widely deploy effective countermeasures. It's hard to predict with confidence which of the many vulnerabilities will be popular among attackers five years from now, and I've been very wrong, in both directions, many times. In recognition of our own fallibility at predicting the future, the conclusion I draw is that it is a good idea to be conservative. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
Ian Grigg [EMAIL PROTECTED] writes: 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? I have to find I find this argument very odd. You argue that TLS defends against man in the middle attacks, but that we do not observe man in the middle attacks, so why do we need the defense? Well, we don't observe the attacks much because they are hard to undertake. Make them easy and I am sure they would happen frequently. Protocols subject to such attacks are frequently subjected to them, and there are whole suites of tools you can download to help you in intercepting traffic to facilitate them. You argue that we have to make a cost/benefit analysis, but we're talking about computer algorithms where the cost is miniscule if it is measurable at all. Why should we use a second-best practice when a best practice is in reality no more expensive? It is one thing to argue that a bridge does not need another million dollars worth of steel, but who can rationally argue that we should use different, less secure algorithms when there is no obvious benefit, either in computation, in development costs or in license fees (since TLS is after all free of any such fees), and the alternatives are less secure? In such a light, a cost/benefit analysis leads inexorably to Use TLS -- second best saves nothing and might cost a lot in lower security. Some of your arguments seem to come down to there wasn't enough thought given to the threat model. That might have been true when the SSL/TLS process began, but a bunch of fairly smart people worked on it, and we've ended up with a pretty solid protocol that is at worst more secure than you might absolutely need but which covers the threat model in most of the cases in which it might be used. You've yet to argue that the threat model is insufficiently secure -- only that it might be more than one needs -- so what is the harm? Honestly the only really good argument against TLS I can think of is that if one wants to use something like SSH keying instead of X.509 keying the detailed protocol doesn't support it very well, but the protocol can be trivially adapted to do what one wants and the underlying security model is almost exactly what one wants in a majority of cases. Such an adaptation might be a fine idea, but it can be done without giving up any of the fine analysis that went into TLS. Actually, there is one other argument against TLS -- it does not protect underlying TCP signaling the way that IPSec does. However, given where it sits in the stack, you can't fault it for that. 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. This is not a failure of TLS. This is a failure of the browsers and web servers. There is no reason browsers couldn't do exactly that, tomorrow, and that sites couldn't operate on an SSH accept only what you saw the first time model. TLS is fully capable of supporting that. If you want to argue against X.509, that might be a fine and quite reasonable argument. I would happily argue against lots of X.509 myself. However, X.509 is not TLS, and TLS's properties are not those of X.509. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
On Wed, Oct 22, 2003 at 05:08:32PM -0400, Tom Otvos wrote: 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. Can you please posit an *exact* situation in which a man-in-the-middle could steal the client's credit card number even in the presence of a valid server certificate? Can you please explain *exactly* how using a client-side certificate rather than some other form of client authentication would prevent this? Thor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
[EMAIL PROTECTED] (David Wagner) writes: 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? I'm not aware of any such consensus. I will state that MITM attacks are hardly a myth. They're used by serious attackers when the underlying protocols permit it, and I've witnessed them in the field with my own two eyes. Hell, they're even well enough standardized that I've seen them in use on conference networks. Some such attacks have been infamous. MITM attacks are not currently the primary means for stealing credit card numbers these days both because TLS makes it harder to do MITM attacks and thus it is usually easier just to break in to the poorly defended web server and steal the card numbers directly. However, that is not a reason to remove anti-MITM defenses from TLS -- it is in fact a reason to think of them as a success. I suspect you'd get plenty of debate on this point. But in any case, widespread exploitation of a vulnerability shouldn't be a prerequisite to deploying countermeasures. Indeed. Imagine if we waited until airplanes exploded regularly to design them so they would not explode, or if we had designed our first suspension bridges by putting up some randomly selected amount of cabling and seeing if the bridge collapsed. That's not how good engineering works. If we see a plausible future threat and the stakes are high enough, it is often prudent to deploy defenses in advance against the possibility that attackers. This is especially true when the marginal cost of the defenses is near zero. The design cost of the countermeasures was high, but once designed they can be replicated with no greater expense than that of any other protocol. It's hard to predict with confidence which of the many vulnerabilities will be popular among attackers five years from now, and I've been very wrong, in both directions, many times. In recognition of our own fallibility at predicting the future, the conclusion I draw is that it is a good idea to be conservative. Ditto. -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
Tom Weinstein wrote: Ian Grigg wrote: 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. This sort of statement bothers me. In threat analysis, you have to base your assessment on capabilities, not intentions. If an attack is possible, then you must guard against it. It doesn't matter if you think potential attackers don't intend to attack you that way, because you really don't know if that's true or not and they can always change their minds without telling you. In threat analysis, you base your assessment on economics of what is reasonable to protect. It is perfectly valid to decline to protect against a possible threat, if the cost thereof is too high, as compared against the benefits. This is the reason that we cannot simply accept the possible as a basis for engineering of any form, let alone cryptography. And this is the reason why, if we can't measure it, then we are probably justified in assuming it's not a threat we need to worry about. (Of course, anecdotal evidence helps in that respect, hence there is a lot of discussion about MITMs in other forums.) iang Here's Eric Rescorla's words on this: http://www.iang.org/ssl/rescorla_1.html The first thing that we need to do is define our ithreat model./i A threat model describes resources we expect the attacker to have available and what attacks the attacker can be expected to mount. Nearly every security system is vulnerable to some threat or another. To see this, imagine that you keep your papers in a completely unbreakable safe. That's all well and good, but if someone has planted a video camera in your office they can see your confidential information whenever you take it out to use it, so the safe hasn't bought you that much. Therefore, when we define a threat model, we're concerned not only with defining what attacks we are going to worry about but also those we're not going to worry about. Failure to take this important step typically leads to complete deadlock as designers try to figure out how to counter every possible threat. What's important is to figure out which threats are realistic and which ones we can hope to counter with the tools available. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
Ian Grigg [EMAIL PROTECTED] writes: In threat analysis, you base your assessment on economics of what is reasonable to protect. It is perfectly valid to decline to protect against a possible threat, if the cost thereof is too high, as compared against the benefits. The cost of MITM protection is, in practice, zero. Indeed, if you wanted to produce an alternative to TLS without MITM protection, you would have to spend lots of time and money crafting and evaluating a new protocol that is still reasonably secure without that protection. One might therefore call the cost of using TLS, which may be used for free, to be substantially lower than that of an alternative. How low does the risk have to get before you will be willing not just to pay NOT to protect against it? Because that is, in practice, what you would have to do. You would actually have to burn money to get lower protection. The cost burden is on doing less, not on doing more. There is, of course, also the cost of what happens when someone MITM's you. You keep claiming we have to do a cost benefit analysis, but what is the actual measurable financial benefit of paying more for less protection? Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
RE: SSL, client certs, and MITM (was WYTM?)
At 05:42 PM 10/22/2003 -0400, Tom Otvos wrote: 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? ok, the original SSL domain name certificate for what became electronic commerce was 1) am I really talking to the server that I think I'm talking to 2) encrypted session. so the attack in #1 was plausably some impersonation ... either MITM or straight impersonation. The issue was that there was a perceived vulnerability in the domain name infrastructure that somebody could contaminate the domain name look up and get the ip-address for the client redirected to the impersonater. The SSL domain name certificates carry the original domain name the client validates the domain name certificate with one of the public keys in the browser CA table ... and then validates that the server that it is communicating with can sign/encrypt something with the private key that corresponds to the public key carried in the certificate ... and then the client compares the domain name in the certificate with the URL that the browser used. In theory, if all of that works then it is highly unlikely that the client is talking to the wrong ip-address (since it should be the ip-address of the server that corresponds to the server). So what are the subsequent problems: 1) the original idea was that the whole shopping experience was protected by the SSL domain name certificate preventing MITM impersonation attacks. However, it was found that SSL overhead was way to expensive and so the servers dropped back to just using it for encryption of the shopping experience. This means that the client ... does all their shopping ... with the real server or the imposter ... and then clicks on a button to check out that drops the client into SSL for the credit card number. The problem is that if it is an imposter ... the button likely carries a URL for which the imposter has a valid certificate for. or 2) the original concern was possible ip-address hijacking in the domain name infrastructure so the correct domain name maps to the wrong ip address and the client goes to an imposter (whether or not the imposter needs to do an actual MITM or not). The problem is that when somebody approaches a CA for a certificate the CA has to contact the domain name system as to the true owner of the domain name. It turns out that integrity issues in the domain name infrastructure not only can result in ip-address take-over but also domain name take-over. The imposter exploits integrity flaws in the domain name infrastructure and does a domain name take-over approaches a CA for a SSL domain name certificate ... and the CA issues it ... because the domain name infrastructure claims it is the true owner. So somewhat from the CA industry ... there is a proposal that people register a public key in the domain name database when they obtain a domain name. After that ... all communication is digitally signed and validated with the database entry public key (notice this is certificate-less). This has the attribute of improving the integrity of the domain name infrastructure ... so the CA industry can trust the domain name infrastructure integrity so the rest of the world can trust the SSL comain name certificates? This has the opportunity for simplifying the SSL domain name certificate requesting process. The entity requesting the SSL domain name certificate digitally signs the request (certificate-less of course). The CA validates the SSL domain name certificate request by retrieving the valid owner's public key from the domain name infrastructure database to authenticate the request. This is a lot more efficient and has less vulnerabilities than the current infrastructure. The current infrastructure has some identification of the domain name owner recorded in the domain name infrastructure database. When an entity requests a SSL domain name certificate ... they provide additional identification to the CA. The CA now has to retrieve the information from the domain name infrastructure database and map it to some real world identification. They then have to take the requester's information and also map it to
Re: SSL, client certs, and MITM (was WYTM?)
Ian Grigg wrote: Tom Weinstein wrote: In threat analysis, you have to base your assessment on capabilities, not intentions. If an attack is possible, then you must guard against it. It doesn't matter if you think potential attackers don't intend to attack you that way, because you really don't know if that's true or not and they can always change their minds without telling you. In threat analysis, you base your assessment on economics of what is reasonable to protect. It is perfectly valid to decline to protect against a possible threat, if the cost thereof is too high, as compared against the benefits. This is the reason that we cannot simply accept the possible as a basis for engineering of any form, let alone cryptography. And this is the reason why, if we can't measure it, then we are probably justified in assuming it's not a threat we need to worry about. The economic view might be a reasonable view for an end-user to take, but it's not a good one for a protocol designer. The protocol designer doesn't have an economic model for how end-users will end up using the protocol, and it's dangerous to assume one. This is especially true for a protocol like TLS that is intended to be used as a general solution for a wide range of applications. In some ways, I think this is something that all standards face. For any particular application, the standard might be less cost effective than a custom solution. But it's much cheaper to design something once that works for everyone off the shelf than it would be to custom design a new one each and every time. -- Give a man a fire and he's warm for a day, but set | Tom Weinstein him on fire and he's warm for the rest of his life. | [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
Perry E. Metzger wrote: Ian Grigg [EMAIL PROTECTED] writes: In threat analysis, you base your assessment on economics of what is reasonable to protect. It is perfectly valid to decline to protect against a possible threat, if the cost thereof is too high, as compared against the benefits. The cost of MITM protection is, in practice, zero. Not true! The cost is from 10 million dollars to 100 million dollars per annum. Those certs cost money, Perry! All that sysadmin time costs money, too! And all that managerial time trying to figure out why the servers don't just work. All those consultants that come in and look after all those secure servers and secure key storage and all that. In fact, it costs so much money that nobody bothers to do it *unless* they are forced to do it by people telling them that they are being irresponsibly vulnerable to the MITM! Whatever that means. Literally, nobody - 1% of everyone - runs an SSL server, and even only a quarter of those do it properly. Which should be indisputable evidence that there is huge resistance to spending money on MITM. Indeed, if you wanted to produce an alternative to TLS without MITM protection, you would have to spend lots of time and money crafting and evaluating a new protocol that is still reasonably secure without that protection. One might therefore call the cost of using TLS, which may be used for free, to be substantially lower than that of an alternative. I'm not sure how you come to that conclusion. Simply use TLS with self-signed certs. Save the cost of the cert, and save the cost of the re-evaluation. If we could do that on a widespread basis, then it would be worth going to the next step, which is caching the self-signed certs, and we'd get our MITM protection back! Albeit with a bootstrap weakness, but at real zero cost. Any merchant who wants more, well, there *will* be ten offers in his mailbox to upgrade the self-signed cert to a better one. Vendors of certs may not be the smartest cookies in the jar, but they aren't so dumb that they'll miss the financial benefit of self- signed certs once it's been explained to them. (If you mean, use TLS without certs - yes, I agree, that's a no-won.) How low does the risk have to get before you will be willing not just to pay NOT to protect against it? Because that is, in practice, what you would have to do. You would actually have to burn money to get lower protection. The cost burden is on doing less, not on doing more. This is a well known metric. Half is a good rule of thumb. People will happily spend X to protect themselves from X/2. Not all the people all the time, but it's enough to make a business model out of. So if you were able to show that certs protected us from 5-50 million dollars of damage every year, then you'd be there. (Mind you, where you would be is, proposing that certs would be good to make available. Not compulsory for applications.) There is, of course, also the cost of what happens when someone MITM's you. So I should spend the money. Sure. My choice. You keep claiming we have to do a cost benefit analysis, but what is the actual measurable financial benefit of paying more for less protection? Can you take that to the specific case? iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: SSL, client certs, and MITM (was WYTM?)
Ian Grigg [EMAIL PROTECTED] writes: Perry E. Metzger wrote: The cost of MITM protection is, in practice, zero. Not true! The cost is from 10 million dollars to 100 million dollars per annum. Those certs cost money, Perry! They cost nothing at all. I use certs every day that I've created in my own CA to provide MITM protection, and I paid no one for them. It isn't even hard to do. Repeat after me: TLS is not only for protecting HTTP, and should not be mistaken for https:. TLS is not X.509, and should not be mistaken for X.509. TLS is also not buy a cert from Verisign, and should not be mistaken for buy a cert from Verisign. TLS is just a pretty straightforward well analyzed protocol for protecting a channel -- full stop. It can be used in a wide variety of ways, for a wide variety of apps. It happens to allow you to use X.509 certs, but if you really hate X.509, define an extension to use SPKI or SSH style certs. TLS will accommodate such a thing easily. Indeed, I would encourage you to do such a thing. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
