Re: Who's afraid of Mallory Wolf?
On Tuesday 25 March 2003 15:22, Bill Stewart wrote: I get the impression that we're talking at cross-purposes here, with at least two different discussions. Yep. I haven't counted them up yet, but the full discussion includes at least 6 disparate threads. The challenge is to not arbitrarily switch from one thread to another without losing the context of the first. The way I got where (I think) I am is this: Fact: The SSL cert that is required for the server is expensive. Question: Why do we have to pay that expense, and what happens if we use a self-signed cert? Answer: the MITM! Spoofing! OK, so now let's challenge the assumptions: Question: What is the MITM? And why should we care? And, when we've answered that question, let's plug that truth back into the 1st question. (And, the same for spoofing.) Let's look at several cases: 1 - Sites that have SSL and Expensive Certs that need them and need MITM protection 1a - These sites, but with other security holes making it easy to break in. 1b - These sites, broken by SSL bugs or browser bugs 2 - Sites that have SSL and Expensive Certs that don't need them, as long as they've got some crypto like self-signed certs, which don't give MITM protection 3 - Sites that don't have SSL today because it's too annoying, for which crypto would be useful, and ADH or self-signed certs would be good enough, because MITM isn't a big threat for them. 4 - Sites that don't need crypto. Fantastic! a 2 x 2: GOTHTTP SSL+ ONLY cert Want Crypto1 Want (may have bugs) certs Want 2 3 Crypto (adh/ssc) Don't4 want Crypto Totals: 1% 99% Hmm, it drew out as a 2 x 3 (only in fixed font). So, I wonder what the totals on the right would be? How many people want crypto/MITM, how many would be happy with crypto/no MITM protection, and how many don't want any crypto? -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
That's using a questionable measuring stick. The damages paid out in a civil suit may be very different (either higher, or lower) than the true cost of the misconduct. Remember, the courts are not intended to be a remedy for all harms, nor could they ever be. The courts shouldn't be a replacement for our independent judgement. Let me quote what the (U.S.) 2nd Circuit Court of Appeals said in the T.J. Hooper case (60 F.2d 737, 1932): Indeed in most cases reasonable prudence is in face common prudence; but strictly it is never its measure; a whole calling may have unduly lagged in the adoption of new and available devices. It may never set its own tests, however persuasive be its usages. Courts must in the end say what is required; there are precautions so imperative that even their universal disregard will not excuse their omission But here there was no custom at all as to receiving sets; some had them, some did not; the most that can be urged is that they had not yet become general. Certainly in such a case we need not pause; when some have thought a device necessary, at least we may say that they were right, and the others too slack. Given that there were published warnings of *practical* MITM attacks (my papers, Radia Perlman's dissertation on secure routing, Lawrence Joncheray's paper on TCP hijacking, etc.), I have no doubt whatsoever what a (U.S.) court would have ruled if there had ever been a real attack. Given that MITM attacks have happened, I have just about as little doubt that they would have been used to steal credit card numbers if SSL had no protection. Look at it this way -- we've already had passowrd-eavesdropping (vintage 1993), off-the-shelf TCP hijacking code (Dug Song's package), and moderate-scale hacked machines for credit card number and account number theft (Internet cafes in Japan, about a month ago -- I'm on the train, and don't have the precise citation handy.) Given all that, do you doubt that the hackers would have combined the easily-available pieces into a MITM attack? I don't. The real issue in the original post seems to be the cost of a trusted certificate. I submit that there are other ways to solve that problem than abandoning a very necessary protection. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tuesday 25 March 2003 22:34, Steven M. Bellovin wrote: Let me quote what the (U.S.) 2nd Circuit Court of Appeals said in the T.J. Hooper case (60 F.2d 737, 1932): Indeed in most cases reasonable prudence is in face common prudence; but strictly it is never its measure; a whole calling may have unduly lagged in the adoption of new and available devices. It may never set its own tests, however persuasive be its usages. Courts must in the end say what is required; there are precautions so imperative that even their universal disregard will not excuse their omission But here there was no custom at all as to receiving sets; some had them, some did not; the most that can be urged is that they had not yet become general. Certainly in such a case we need not pause; when some have thought a device necessary, at least we may say that they were right, and the others too slack. Given that there were published warnings of *practical* MITM attacks (my papers, Radia Perlman's dissertation on secure routing, Lawrence Joncheray's paper on TCP hijacking, etc.), I have no doubt whatsoever what a (U.S.) court would have ruled if there had ever been a real attack. I'm sorry, I won't be able to do more than speculate on this, and I wasn't aware of your legal background, so please take the below as not advice. I.e., IANAL and all that. Courts are notoriously difficult to predict. That's why they say take legal advice :-) And, it may very well be that Netscape took legal advice, and at that time, it did seem that MITM protection at the level of CA-certificates was a reasonable choice (c.f., David Wagner's post) amongst other reasonable choices, so I don't think there is any doubt that what was done back in '94 was reasonable in the circumstances. But, on the face of it, you appear to be saying that because the court saw warnings then it ruled that the warnings were sufficient. I don't read that at all. I see that interpretatation as a Chicken Little argument. This opens the way to Info-war style consultants saying that because you were warned, you are liable. That above snippet says there are precautions so imperative which implies the court had already reached its opinion on the merits of this protection, which is precisely what this discussion has aimed to address. In fact, the court said very clearly that it is the one to decide what the test is - not the industry. The court then went on to say that, as it found the precautions imperitive, and as the industry had warned, albeit contraversially, then, it concluded, relying on the lack of industry custom and agreement as a defence was insufficient. So, with respect, I would say that the above should be read as do not rely on discordant others, be they so-called experts or Chicken Littles on either side, in applying your own prudential measures, which is quite the reverse of your reading. Now, the above is speculation; not having the full ruling and the full training, one can't do more. But, to take mere warnings as liabilities is to forgoe ones profession as an engineer, and hand ones responsibilities over on the one hand to the religious seers of doom, and on the other, to the lawyers. The ludicrousness of this approach is perhaps more crystallised when we consider that half of the world's web servers are shipped for free (c.f Apache). The crypto components are still, AFAIK, dealt with outside America for the most part. And, a growing share of browsers are now shipping for free or near-free. We've seen over the last year or so, Konqueror, Mozilla, and Safari rise to take back the forgotten gauntlet of browser for the rest of us. These are not sold products. There are no contracts that imply security. The world of open source is not necessarily going to be treated in the courts the same as a purchased product with implicit liabilities of a consumer nature. I grant that America may be moving towards a world where Eric Y or Ben L will be norieged and hailed before a california court in some case for inadequate MITM protection, but, I personally don't see that as a world that I would accept on the face value of some legal handwaving. Is that really what we want for our Internet? -- iang PS: It is apropos that the CA industry uses the same approach in trying to define industry custom as sufficient; see Jane K Winn, _Courriers without Luggage_ for her expose of the fallacy in this. In contrast to your implied claim that SSL providers would be at risk if they didn't do the MITM approach, I'd suspect that CAs are on the hook, because of the very arguments that Winn and, now, Hooper advance. ) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
At 10:02 PM 3/24/2003 +, David Wagner wrote: You could take your argument even further and ask whether any crypto was needed at all. After all, most attacks have worked by compromising the endpoint, not by sniffing network traffic. I'll let you decide whether to count this as a success story for SSL, or as indication that the crypto wasn't needed in the first place. (I'm a little skeptical of this argument, by the way, but hey, if we're playing devil's advocate, why not aim high?) I assert that there may be more sites that transmit credit card numbers w/o crypto, as sites that use SSL (although transaction rates are highly skewed so they even if it were ten times the number of sites, it might represent fewer actual transmissions). I don't have actual numbers, but I am aware of significant number of sites. However, I would contend that harvesting numbers from end-point merchant files has significantly higher return (ROI, expected results for the effort) than any sort of network evesdropping ... and that it is practically impossible to provide the necessary armoring as countermeasure for this vulnerability; end point attacks by either insider and outsider (historically, insider attacks on financial infrastructure have represented vast majority of incidents. While it may be possible to do a single armored site it isn't practical to do a million such sites (for one thing, people make too many mistakes) ... as per previous ref to security proportional to risk (and the merchant file risk is proportional to the credit limits of the accounts, not the specific merchant transaction). I would expect that network evesdropping would be employed where vulnerability was something other than kind of fraud do'able by attacking the end-point merchant file. Note however, skimming (various kinds of electronic non-electronic recording) does go on in the physical world. Part of the issue may be that the target object (account number) has much lower occurance in general internet traffic (physical world skimming involves traffic that is almost solely account numbers). If you just have to skim, there are some number of points that are much more target rich environments (better fraud ROI) than internet traffic. There is some phrase that if the only thing you know how to use is a hammer, then every solution may involve a nail. The fundamental problem with account numbers is that they are effectively a kind of shared-secret acquiring/harvesting the numbers enables fraud. There are significant number of business processes that require the availability of the account numbers. This is one of the reasons for the end-point merchant files and also why SET (with significantly more complex crypto infrastructure and essentially only, also addressing data in-flight) offered very little additional over what my wife and I were involved with setting up the original SSL for e-commerce. http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 The point of x9.59 wasn't to add even more layers of crypto and information hiding to protect these shared-secrets but to change the business model so that the account numbers were no longer shared-secrets. X9.59 uses simple digital signature for authenticated payment transactions and a business rule that account numbers used in x9.59 transactions can't be used in non-authenticated payment transactions. http://www.garlic.com/~lynn/index.html#x959 aka just by evesdropping an x9.59 transactions or harvesting account numbers used in x9.59 transactions doesn't enable a crook to initiate a fraudulent payment transaction. -- 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: Who's afraid of Mallory Wolf?
On Monday 24 March 2003 19:26, bear wrote: On Mon, 24 Mar 2003, Peter Clay wrote: On Sun, 23 Mar 2003, Ian Grigg wrote: Consider this simple fact: There has been no MITM attack, in the lifetime of the Internet, that has recorded or documented the acquisition and fraudulent use of a credit card (CC). (Over any Internet medium.) There have, however, been numerous MITM attacks for stealing or eavesdropping on email. A semi-famous case I'm thinking of involves a rabid baptist minister named fred phelps and a topeka city councilwoman who had the audacity to vote against him running roughshod over the law. He set up routing tables to fool DNS into thinking his machine was the shortest distance from the courthouse where she worked to her home ISP and eavesdropped on her mail. Sent a message to every fax machine in town calling her a Jezebellian whore after getting the skinny on the aftermath of an affair that she was discussing with her husband. I love it! Then, I'm wrong on that point, we do in fact have some aggressive MITMs occuring in some mediums over the net. Steve Bellovin pointed one out, this is another. Which gets us to the next stage of the analysis (what did they cost!). And as for theft of credit card numbers, the lack of MITM attacks directly on them is just a sign that other areas of security around them are so loose no crooks have yet had to go to that much trouble. Weakest link, remember? No need to mount a MITM attack if you're able to just bribe the data entry clerk. I'd say, SSL with the cert protection is the strongest link in the chain. In fact, it's ludicrously strong. It's like a Chubb vault lock on a screen door. If we were getting physical here, the door wouldn't be strong enough to hold up the lock. So, cut to the chase: if we mandate that from now on, all commerce servers use ADH, just hypothetically, for the sake of argument, do you think that the connection would then become anything other than the strongest link in the chain? (I think it would remain the strongest link, by far. In fact, even if it was unencrypted, I think it would be one of the stronger links, c.f., David Wagner's devilish advocacy. But, nobody would suggest we throw away the current cert infrastructure, just that we back off a little and accept the intermediate path of ADH / self-signed certs.) Just because most companies' security is so poor that it's not worth the crook's time and effort doesn't mean we should throw anyone who takes security seriously enough that a MITM vulnerability might be the weakest link to the wolves. Nobody's saying that we should. I'm saying that the server and browser should offer the choice to deploy and use more convenient levels of security. The message should congratulate the user for moving up to a more secure channel than HTTP, not annoy them with imponderables about how self-signed certs might be insecure under a certain hard-to-measure threat model... as is the case now. -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Monday, Mar 24, 2003, at 18:57 US/Eastern, Ed Gerck wrote: I'm sorry to say it but MITM is neither a fable nor restricted to laboratory demos. It's an attack available today even to script kiddies. For example, there is a possibility that some evil attacker redirects the traffic from the user's computer to his own computer by ARP spoofing. With the programs arpspoof, dnsspoof and webmitm in the dsniff package it is possible for a script kiddie to read the SSL traffic in cleartext (list of commands available if there is list interest). For this attack to work the user and the attacker must be on the same LAN or ... the attacker could be somewhere else using a hacked computer on the LAN -- which is not so hard to do ;-) This is good info! ... Clearly, the browsers should not discriminate against cert-less browsing opportunities The only sign of the spoofing attack is that the user gets a warning about the certificate that the attacker is presenting. It's vital that the user does not proceed if this happens -- contrary to what you propose. True. Based on his first post however I think that IanG is saying something like: 1. Presently 1% of Internet traffic is protected by SSL against MITM and eavesdropping. 2. 99% of Internet traffic is not protected at all. 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) 4. The SSL infrastructure (the combination of browsers, servers and the protocol) does not allow the use of SSL for privacy protection only. AnonDH is not supported by browsers and self-signed certificates as a workaround don't work well either. 5. The reason for (4) is that the MITM attack is overrated. People refuse to provide the privacy protection because it doesn't protect against MITM. Even though MITM is not a realistic attack (2), (3). (That is not to say that (1) can do without MITM protection. I suspect that IanG agrees with this even though his post seemed to indicate the contrary.) 6. What is needed is a system that allows hassle-free, incremental deployment of privacy-protecting crypto without people whining about MITM protection. Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* displayed when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons. BTW, this is NOT the way to make paying for CA certs go away. A technically correct way to do away with CA certs and yet avoid MITM has been demonstrated to *exist* (not by construction) in 1997, in what was called intrinsic certification -- please see www.mcg.org.br/cie.htm Phew, that is a lot of pages to read (40?). Its also rather though material for me to digest. Do you have something like an example approach written up? I couldn't find anything on the site that did not require study. Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] The python has, and I fib no fibs, 318 pairs of ribs. In stating this I place reliance On a séance with one who died for science. This figure is sworn to and attested; He counted them while being digested. -- Ogden Nash - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Jeroen C. van Gelderen wrote: 1. Presently 1% of Internet traffic is protected by SSL against MITM and eavesdropping. 2. 99% of Internet traffic is not protected at all. I'm sorry, but no. The bug in MSIE, that prevented the correct processing of cert path restraints and which led to easy MITM attacks, has been fixed for some time now. Consulting browser statistics sites will show that the MSIE update in question, fueled by the need for other security updates, is making good progress. 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) I'm sorry but the a priori truth above is false . Ignorance about the flaw, that is now fixed, and the need to do a LAN attack (if you want not to mess with the DNS) have helped avert a major public exploit. The hole is now fixed and the logic fails for this reason as well. 4. The SSL infrastructure (the combination of browsers, servers and the protocol) does not allow the use of SSL for privacy protection only. AnonDH is not supported by browsers and self-signed certificates as a workaround don't work well either. There is a good reason -- MITM. AnonDH and self-signed certs cannot prevent MITM. 5. The reason for (4) is that the MITM attack is overrated. People refuse to provide the privacy protection because it doesn't protect against MITM. Even though MITM is not a realistic attack (2), (3). But it is, please see the spoof/MITM method in my previous post. Which, BTW, is rather old info in some circles (3 years?) and is easy to do by script kiddies with no knowledge about anything we are talking here -- they can simply do it. Anyone can do it. (That is not to say that (1) can do without MITM protection. I suspect that IanG agrees with this even though his post seemed to indicate the contrary.) I think Ian's post, with all due respect to Ian, reflects a misconception about cert validation. The misconception is that cert validation can be provided as an absolute reference -- it cannot. The *mathematical* reasons are explained in the paper I cited. This misconception was discussed some 6 years in the ssl-talk list and other lists, and clarified at the time -- please see the archives. It was good, however, to post this again and, again, to allow this to be clarified. 6. What is needed is a system that allows hassle-free, incremental deployment of privacy-protecting crypto without people whining about MITM protection. You are asking for the same thing that was asked, and answered, 6 years ago in the ssl-talk and other lists. There is a way to do it and the way is not self-signed certs or SSL AnonDH. Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* displayed when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons. Problem -- SSL AnonDH cannot prevent MITM. The solution is not to deny the problem and ask who cares about MITM? Ed Gerck wrote: BTW, this is NOT the way to make paying for CA certs go away. A technically correct way to do away with CA certs and yet avoid MITM has been demonstrated to *exist* (not by construction) in 1997, in what was called intrinsic certification -- please see www.mcg.org.br/cie.htm Phew, that is a lot of pages to read (40?). Its also rather though material for me to digest. Do you have something like an example approach written up? I couldn't find anything on the site that did not require study. ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. OTOH, some practical code is being developed, and has been sucessfully tested in the past 3 years with up to 300,000 simultaneous users, which may provide the example you ask for. Please write to me privately if you'd like to use it. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tuesday, Mar 25, 2003, at 02:20 US/Eastern, Ed Gerck wrote: Jeroen C. van Gelderen wrote: 1. Presently 1% of Internet traffic is protected by SSL against MITM and eavesdropping. 2. 99% of Internet traffic is not protected at all. I'm sorry, but no. The bug in MSIE, that prevented the correct processing of cert path restraints and which led to easy MITM attacks, has been fixed for some time now. Consulting browser statistics sites will show that the MSIE update in question, fueled by the need for other security updates, is making good progress. Heu? I am talking about HTTPS (1) vs HTTP (2). I don't see how the MSIE bug has any effect on this. -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Be precise in the use of words and expect precision from others -- Pierre Abelard - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
At 11:10 PM 03/23/2003 -0500, Ian Grigg wrote: Consider this simple fact: There has been no MITM attack, in the lifetime of the Internet, that has recorded or documented the acquisition and fraudulent use of a credit card (CC). (Over any Internet medium.) One of the major reasons for this, of course, is the requirement for certificates, which give at least some vague level of authentication that you're talking to the site you wanted, as well as some much vaguer level of authentication that the web site might correspond to some actual business that at least had enough capital to buy a cert. Sure, there are a variety of subtle and entertaining ways to pull of MITM attacks, but one crude and obvious one is to forge either an entire site or at least the parts of it that ask for your credit card number, and use something like DNS hacking or minor name misspellings to get people to visit your site instead of the real one. If you need to forward some of the requests on to the real site, that's a bit more work, and makes you easier to trace, so if you can be a MITM without bothering with the back half, great. And of course the cruder and more obvious attack was to create a site for a company that wasn't actually on the web yet, so nobody's watching the site, and then fly-by-night out of there. Is it perfect? No, but it does tend to raise the bar on attacks to the point that keeps out lots of the anklebiters and makes it more effective to attack a badly-administered server instead of forging a better-administered server. Oh, and it also let merchants who desperately wanted the public to trust them enough to give them credit card numbers tell their potential customers See, we've got *cryptography*! instead of See, we've got servers sitting exposed to the net, which is a social engineering problem, and also let them say See, the certificates let you know you're talking to the REAL Example Inc. instead a some faker putting up example.com. Because the real economics is whether you can get customers to show up. (Well, ok, and whether you can make money if they do show up :-) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
At 12:17 AM 3/25/2003 -0500, Ian Grigg wrote: I'd say, SSL with the cert protection is the strongest link in the chain. In fact, it's ludicrously strong. It's like a Chubb vault lock on a screen door. If we were getting physical here, the door wouldn't be strong enough to hold up the lock. except the certification authorities ... when doing the certification of who owns a domain name still asks the domain name infrastructure as to who really owns the domain name when they get a request for a SSL domain name certificate. SSL domain name certificate request after a domain name hijack still is possible (aka a chubb vault lock with a possible backdoor). the other scenario that has been raised before is that the browsers treat all certification authorities the same aka if the signature on the certificate can be verified with any of the public keys in a browser's public key table ... it is trusted. in effect, possibly 20-40 different manufactures of chubb vault locks with a wide range of business process controls ... and all having the same possible backdoor. Furthermore, the consumer doesn't get to choose which chubb lock is being chosen. -- 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: Who's afraid of Mallory Wolf?
On Tue, 25 Mar 2003, Ian Grigg wrote: On Monday 24 March 2003 19:26, bear wrote: him running roughshod over the law. He set up routing tables to fool DNS into thinking his machine was the shortest distance from the courthouse where she worked to her home ISP and eavesdropped on her mail. Sent a message to every fax machine in town calling her a Jezebellian whore after getting the skinny on the aftermath of an affair that she was discussing with her husband. I love it! Then, I'm wrong on that point, we do in fact have some aggressive MITMs occuring in some mediums over the net. Steve Bellovin pointed one out, this is another. Which gets us to the next stage of the analysis (what did they cost!). Wait. Time out. Setting aside the increased monetary cost of her reelection campaign in a fairly conservative state capitol, and setting aside the increased difficulty of raising money for that campaign, the main costs here are intangible. On a professional level, she had reduced power in office because of the scandal this clown created publishing her personal email, but the intangible costs go both directions from there. Toward the personal end of the spectrum, discussing the aftermath of an affair with one's husband is sensitive and personal, and making that whole thing public can't have done either of them, or their marriage for that matter, any good. In the public sphere, this is a case in which information gained from an attack on email was being employed directly for undeserved influence on government officials. Being timed to interfere with her reelection makes it a direct means of removing political opponents from office, and it has probably had a chilling effect on other council members in that benighted city who might otherwise have voted in ways Phred didn't like. What he did was nothing less than a direct assault on the democratic process of government. I don't think mere monetary costs are even germane to something like this. The costs, publicly and personally, are of a different kind than money expresses. And we're going to continue to have this problem for as long as we continue to use unencrypted SMTP for mail transport. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Ed Gerck wrote: BTW, this is NOT the way to make paying for CA certs go away. A technically correct way to do away with CA certs and yet avoid MITM has been demonstrated to *exist* (not by construction) in 1997, in what was called intrinsic certification -- please see www.mcg.org.br/cie.htm Phew, that is a lot of pages to read (40?). Its also rather though material for me to digest. Do you have something like an example approach written up? I couldn't find anything on the site that did not require study. ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. AFAICS, what it suggests, in a very roundabout way, is that you may be able to verify the binding between a key and some kind of DN by being given a list of signatures attesting to that binding. This is pretty much PGP's Web of Trust, of course. I could be wrong, I only read it quickly. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tue, 25 Mar 2003, Anne Lynn Wheeler wrote: the other scenario that has been raised before is that the browsers treat all certification authorities the same aka if the signature on the certificate can be verified with any of the public keys in a browser's public key table ... it is trusted. in effect, possibly 20-40 different manufactures of chubb vault locks with a wide range of business process controls ... and all having the same possible backdoor. Furthermore, the consumer doesn't get to choose which chubb lock is being chosen. Of course the consumer gets to make that choice. I can go into my browser's keyring and delete root certs that have been sold, ever. And I routinely do. A fair number of sites don't work for me anymore, but I'm okay with that. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tuesday 25 March 2003 12:07, bear wrote: On Tue, 25 Mar 2003, Ian Grigg wrote: Which gets us to the next stage of the analysis (what did they cost!). Wait. Time out. good stuff snipped I don't think mere monetary costs are even germane to something like this. The costs, publicly and personally, are of a different kind than money expresses. I'm sorry to disagree, but I'm sticking to my cost-benefit analysis: monetary costs are totally germane. You see, we need some way in which to measure the harm. It's either subjective as you describe above, which can't support an infrastructure decision, or its objective, which means, money. But, luckily, there is a way to turn the above subjective morass of harm into an objective hard number: civil suit. Presumably, (you mentioned America, right?) this injured party filed a civil suit against the person and sought damages. Now, even if the case did not get filed, I imagine that you would be able to find a few legal types to provide an upper and lower bound on the sort of damages that case would go for. And there's your number! From my ignorant position, I'd scratch in a figure of about a million dollars there, and wait for someone to refine it. And we're going to continue to have this problem for as long as we continue to use unencrypted SMTP for mail transport. I would agree. Which is why we are having this discussion - how can we get this poor victim's traffic onto some form of crypto so she doesn't get her life ripped apart by some dirtbag? As far as SSL goes (switching from the context of her mail to the system we are discussing here), here's the answer: Make ADH / self-signed certs a respectable half-way house to CA-signed certs. Encourage all servers to accept them, by default. Encourage all browsers to switch up to ADH / self-signed secured traffic. Don't discourage it, encourage it. The problem is, it is just too darned hard expensive for sites to get into SSL. That's what we are looking at, here, lowering the cost of entry into SSL. -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tuesday, Mar 25, 2003, at 12:28 US/Eastern, bear wrote: On Tue, 25 Mar 2003, Anne Lynn Wheeler wrote: the other scenario that has been raised before is that the browsers treat all certification authorities the same aka if the signature on the certificate can be verified with any of the public keys in a browser's public key table ... it is trusted. in effect, possibly 20-40 different manufactures of chubb vault locks with a wide range of business process controls ... and all having the same possible backdoor. Furthermore, the consumer doesn't get to choose which chubb lock is being chosen. Of course the consumer gets to make that choice. I can go into my browser's keyring and delete root certs that have been sold, ever. And I routinely do. A fair number of sites don't work for me anymore, but I'm okay with that. Go tell that to Joe Average. Or your mom. Or my sister. Or the average MSN user. You know, the insignificant group of people that make up the majority of the Internet population these days. If the lock icon is displayed it is safe. Of course the consumer doesn't get to choose. Just like the consumer never, ever gets to use all of the features on his VCR[*]. This is an software agent deficiency. A UI issue: presently the UI doesn't facilitate the consumer in making that choice. Cheers, -J [*] I'm *not* talking about TiVo here, just about old-fashioned VCRs. -- Jeroen C. van Gelderen - [EMAIL PROTECTED] Be precise in the use of words and expect precision from others -- Pierre Abelard - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Ian Grigg writes: I don't think mere monetary costs are even germane to something like this. The costs, publicly and personally, are of a different kind than money expresses. I'm sorry to disagree, but I'm sticking to my cost-benefit analysis: monetary costs are totally germane. You see, we need some way in which to measure the harm. It's either subjective as you describe above, which can't support an infrastructure decision, or its objective, which means, money. I'm skeptical. Just because the cost is subjective doesn't mean we should ignore the cost. But, luckily, there is a way to turn the above subjective morass of harm into an objective hard number: civil suit. That's using a questionable measuring stick. The damages paid out in a civil suit may be very different (either higher, or lower) than the true cost of the misconduct. Remember, the courts are not intended to be a remedy for all harms, nor could they ever be. The courts shouldn't be a replacement for our independent judgement. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Ben Laurie wrote: Ed Gerck wrote: ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. AFAICS, what it suggests, in a very roundabout way, is that you may be able to verify the binding between a key and some kind of DN by being given a list of signatures attesting to that binding. This is pretty much PGP's Web of Trust, of course. I could be wrong, I only read it quickly. This would still depend on what the paper calls extrinsic references, that are outside the dialogue and create opportunity for faults (intentional or otherwise). The resulting problems for PGP are summarized in www.mcg.org.br/cert.htm#1.2. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Jeroen van Gelderen wrote: Heu? I am talking about HTTPS (1) vs HTTP (2). I don't see how the MSIE bug has any effect on this. Maybe we're talking about different MSIE bugs, which is not hard to do ;-) I was referring to the MSIE bug that affects the SSL handshake in HTTPS, from the context in discussion. BTW, HTTP has no provision to prevent MITM in any case -- in fact, establishing a MITM is part of the HTTP tool box and used in reverse proxies for example. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tuesday, Mar 25, 2003, at 13:55 US/Eastern, Ed Gerck wrote: Jeroen van Gelderen wrote: Heu? I am talking about HTTPS (1) vs HTTP (2). I don't see how the MSIE bug has any effect on this. Maybe we're talking about different MSIE bugs, which is not hard to do ;-) I am NOT talking about MSIE bugs at all. I didn't mention them and I don't know where you pull the reference from. I am talking about HTTPS traffic (1%) vs. HTTP traffic (99%) on the Internet: 1. Presently 1% of Internet traffic is protected *by SSL* against MITM and eavesdropping. 2. 99% of Internet traffic is not protected at all (because it travels over plain HTTP). I was referring to the MSIE bug that affects the SSL handshake in HTTPS, from the context in discussion. BTW, HTTP has no provision to prevent MITM in any case -- in fact, establishing a MITM is part of the HTTP tool box and used in reverse proxies for example. Well, that is *exactly* the point I made: 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) Hence the a priori truth. 4. The SSL infrastructure (the combination of browsers, servers and the protocol) does not allow the use of SSL for privacy protection only. AnonDH is not supported by browsers and self-signed certificates as a workaround don't work well either. That is, we cannot add just privacy protection to HTTP by enabling SSL. That sucks because HTTP with just privacy protection is preferable over plain HTTP. But the present SSL infrastructure insists that I pay to defend against MITM even if I have no need for that. That is the problem I (and I suspect IanG) is talking about. 5. The reason for (4) is that the MITM attack is overrated. People refuse to provide the privacy protection because it doesn't protect against MITM. Even though MITM is not a realistic attack for (2), (3). (That is not to say that (1) can do without MITM protection. I suspect that IanG agrees with this even though his post seemed to indicate the contrary.) 6. What is needed is a system that allows hassle-free, incremental deployment of privacy-protecting crypto without people whining about MITM protection. Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* displayed when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons. Cheers, Jeroen -- Jeroen C. van Gelderen - [EMAIL PROTECTED] They accused us of suppressing freedom of expression. This was a lie and we could not let them publish it. -- Nelba Blandon, Nicaraguan Interior Ministry Director of Censorship - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Jeroen van Gelderen wrote: 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) Let me summ up my earlier comments: Protection against eavesdropping without MITM protection is not protection against eavesdropping. In addition, when you talk about HTTPS traffic (1%) vs. HTTP traffic (99%) on the Internet you are not talking about user's choices -- where the user is the party at risk in terms of their credit card number. You're talking about web-admins failing to protect third-party information they request. Current DO liability laws, making the officers of a corporation personally responsible for such irresponsible behavior, will probably help correct this much more efficiently than just a few of us decrying it. My personal view is that ALL traffic SHOULD be encrypted, MITM protected, and authenticated, with the possibility of anonymous authentication if so desired. Of course, this is not practical today -- yet. But we're working to get there. BTW, a source once told me that about 5% of all email traffic is encrypted. So, your 1% figure is also just a part of the picture. Cheers --/Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tue, 25 Mar 2003, Ian Grigg wrote: On Tuesday 25 March 2003 12:07, bear wrote: But, luckily, there is a way to turn the above subjective morass of harm into an objective hard number: civil suit. Presumably, (you mentioned America, right?) this injured party filed a civil suit against the person and sought damages. You honestly haven't heard of Fred Phelps? He has thirteen children and nine of them are lawyers. Estimated costs to sue the guy are in the hundreds of thousands of dollars. Estimated costs for him to defend are near zero. Plus the instant you file that civil suit you'll have his zombies loudly picketing your home (that's right, your private residence) 24/7 until you stop. And we're going to continue to have this problem for as long as we continue to use unencrypted SMTP for mail transport. I would agree. Which is why we are having this discussion - how can we get this poor victim's traffic onto some form of crypto so she doesn't get her life ripped apart by some dirtbag? ISP's don't want to support encrypted links because it raises their CPU costs. And mail clients generally aren't intelligently designed to handle encrypted email which the mail servers could just pass through without decrypting and encrypting. I think a new protocol is needed. The fact that SMTP is unencrypted by default makes it impossible for an encrypted email form to be built on top of it. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
I get the impression that we're talking at cross-purposes here, with at least two different discussions. Let's look at several cases: 1 - Sites that have SSL and Expensive Certs that need them and need MITM protection 1a - These sites, but with other security holes making it easy to break in. 1b - These sites, broken by SSL bugs or browser bugs 2 - Sites that have SSL and Expensive Certs that don't need them, as long as they've got some crypto like self-signed certs, which don't give MITM protection 3 - Sites that don't have SSL today because it's too annoying, for which crypto would be useful, and ADH or self-signed certs would be good enough, because MITM isn't a big threat for them. 4 - Sites that don't need crypto. Some people are arguing Many Sites with SSL Certs are Type 2, Not Type 1 (No they're not! Yes, they are!) Some people are arguing There are lots of Type 3, so we should support them better than we do today instead of requiring them to do Type 1 (I suspect that's what Ian was really trying to say, but most of the replies have been to the other question, e.g. There are lots of Type 3! No, there aren't many Type 2! Yes there *are* lots of Type 3! No there ARENT'T many Type 2! Yes, there are lots of 1a, but that doesn't imply 2! Type 1+2 is 1% and 3+4 is 99%! No, 1b was fixed One of the big reasons for DNSSEC was MITM protection, at least before virtual hosting took over, because it gave you a way to trust that the IP address you used was the correct IP address for the domain name you wanted, so you were probably talking to the right machine. Of course that doesn't get you ARP-spoofing protection, or eavesdropping protection unless you also use it as a crypto key or at least a signature key for DH parts, and doesn't protect you against other users on your machine (but a shared machine doesn't have much protection anyway, at least from root, so that was already part of your threat model, and that's another 1-vs-1a variant, like the heavy-duty lock on your apartment building front door when your own apartment door has a wimpy lock.) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Jeroen van Gelderen wrote: On Tuesday, Mar 25, 2003, at 14:38 US/Eastern, Ed Gerck wrote: Let me summ up my earlier comments: Protection against eavesdropping without MITM protection is not protection against eavesdropping. You are saying that active attacks have the same cost as passive attacks. That is ostensibly not correct. Cost is not the point even though cost is low and within the reach of script kiddies. What we would like to do however is offer a little privacy protection trough enabling AnonDH by flipping a switch. I do have CPU cycles to burn. And so do the client browsers. I am not pretending to offer the same level of security as SSL certs (see note [*]). I agree with this. This is helpful. However, supporting this by asking Who's afraid of Mallory Wolf? is IMO not helpful -- because we should all be afradi fo MITM attacks. It's not good for security to deny an attack that is rather easy to do today. I'm proposing a slight, near-zero-cost improvement[*] in the status quo. You are complaining that it doesn't achieve perfection. I do not understand that. Your proposal is, possibly, a good option to have. However, it does not: provide a credible protection against eavesdropping. It is better than ROT13, for sure. Essentially, you're asking for encryption without an authenticated end-point. This is acceptable. But I suggest that advancing your idea should not be prefaced by denying or trying to hide the real problem of MITM attacks. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tuesday, Mar 25, 2003, at 14:38 US/Eastern, Ed Gerck wrote: Jeroen van Gelderen wrote: 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) Let me summ up my earlier comments: Protection against eavesdropping without MITM protection is not protection against eavesdropping. You are saying that active attacks have the same cost as passive attacks. That is ostensibly not correct. In addition, when you talk about HTTPS traffic (1%) vs. HTTP traffic (99%) on the Internet you are not talking about user's choices -- where the user is the party at risk in terms of their credit card number. You're talking about web-admins failing to protect third-party information they request. Not at all. That assertion is nowhere to be found in my original post either. I am talking about a website like -say- Cryptix (or Dilbert, or The Onion, or whichever). Websites where we do not have any requirement of offering the user any privacy whatsoever. Where we do not collect CC numbers. Where we do in fact not collect much of anything. And where we definitely don't have money for an SSL certificate. Where in fact any effort spent on this stuff is an incredible waste of resources. What we would like to do however is offer a little privacy protection trough enabling AnonDH by flipping a switch. I do have CPU cycles to burn. And so do the client browsers. I am not pretending to offer the same level of security as SSL certs (see note [*]). Enabling AnonDH will eliminate passive attacks at near zero cost and thus *raise* *the* *cost* of eavesdropping. For one it will render mere recording of HTTP traffic useless, which, in my book is a plus. We obviously don't care to *eliminate* eavesdropping because we are happily putting up with that today. You seem to be asserting that increasing the cost of eavesdropping by a small amount is worthless. I'm sorry but I don't see how that makes sense. It is the difference between simply mirroring Google's OC48 to and NSA-owned port on the switch and redirecting the OC48 trough a real-time, low-latency NSA-owned MITM device. Without being detected. I'm proposing a slight, near-zero-cost improvement[*] in the status quo. You are complaining that it doesn't achieve perfection. I do not understand that. Cheers, Jeroen [*] Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* *displayed* when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons. -- Jeroen C. van Gelderen - [EMAIL PROTECTED] They accused us of suppressing freedom of expression. This was a lie and we could not let them publish it. -- Nelba Blandon, Nicaraguan Interior Ministry Director of Censorship - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Tuesday 25 March 2003 13:17, David Wagner wrote: I'm skeptical. Just because the cost is subjective doesn't mean we should ignore the cost. I agree with that ... I was converting the subjective harm into an objective cost. I certainly wasn't intending to ignore it :-) But, luckily, there is a way to turn the above subjective morass of harm into an objective hard number: civil suit. That's using a questionable measuring stick. That being part and parcel of the problem. It's a subjective harm, there is no solid way to move subjective to objective, by definition. We can only make estimates. What is beneficial here is that - at least - we have one way to do this. And, it is a way that has lots of disinterested observers, lots of experience, and lots of interested parties. Much as I dislike courts, it is a fair and auditable way of dollarising a harm. Bear says: You honestly haven't heard of Fred Phelps? Nope. But, all we want is an estimated cost of the attack. Ask some lawyers for a quote. Ignore the guy's family, we are only after an estimate of the cost. David says: The damages paid out in a civil suit may be very different (either higher, or lower) than the true cost of the misconduct. Remember, the courts are not intended to be a remedy for all harms, nor could they ever be. The courts shouldn't be a replacement for our independent judgement. This of course is true especially with the low level of MITM activity that we've found to date. If such a case were to happen once a year, I'd not be really confident of the accuracy of the numbers, especially if we were estimating based on lawyer's opinions rather than awarded damages. (But that wouldn't so much matter if the numbers came out as also too low to consider, as I suspect they will.) If however, we had such MITMs once per month, then costs could be averaged over the size of the activity. Something like this: There are 500 million email users in the world today (guess!). Cost of failures that could be rectified with proper crypto (amounts to 12 cases per year) is 12 million dollars. Some judgements less than a million, some more. [ if you like, you could add in a fudge factor for unreported harms and other judgement calls. ] Now, the cost of prevention: assume we pass a law to make every ISP sell every user a copy of OpenPGP to protect their privacy. Bulk discount gives us $1 each copy, annually updated to cover for the inevitable new release. So, cost to protect: 500 million x $1. Saved costs in cases: $12million. That law won't get passed :-) -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Ed Gerck wrote: Ben Laurie wrote: Ed Gerck wrote: ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. AFAICS, what it suggests, in a very roundabout way, is that you may be able to verify the binding between a key and some kind of DN by being given a list of signatures attesting to that binding. This is pretty much PGP's Web of Trust, of course. I could be wrong, I only read it quickly. This would still depend on what the paper calls extrinsic references, that are outside the dialogue and create opportunity for faults (intentional or otherwise). The resulting problems for PGP are summarized in www.mcg.org.br/cert.htm#1.2. It seems to me that the difference between PGP's WoT and what you are suggesting is that the entity which is attempting to prove the linkage between their DN and a private key is that they get to choose which signatures the relying party should refer to. Am I wrong? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
At 12:09 PM 3/25/2003 -0800, bear wrote: ISP's don't want to support encrypted links because it raises their CPU costs. And mail clients generally aren't intelligently designed to handle encrypted email which the mail servers could just pass through without decrypting and encrypting. circa '95 there were comments that ISP's didn't want to verify from/spoofed packet addresses on DHCP modem connections because it increased their router cpu costs (actually one of the most common routers didn't have enuf processor power to implement even trivial packet filtering on modem lines). http://www.garlic.com/~lynn/2001m.html#27 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#28 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#29 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#30 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement http://www.garlic.com/~lynn/2001m.html#31 Internet like city w/o traffic rules, traffic signs, traffic lights and traffic enforcement now there is the observation in this thread (or the previous thread) that many websites use SSL very sparingly because it cuts their web traffic capacity by 80-90 percent (http vis-a-vis https given the same hardware). Typical sequence is that person clicks-on/types something and goes to a site with straight HTTP, they shop for a while ... until they are ready to check-out, they then click on the check-out button. That button supplies a URL that sends them off to a HTTPS site (aka the user didn't actually originated the HTTPS url) ... where all the payment information is provided. Now since the client/consumer never provided the actual HTTPS sequence but it was provided for them by a webpage at the HTTP site they were shopping at it is presumably trivial for the HTTP site that they are shopping at to make sure that the HTTPS URL domain that clients are sent to matches the certificate domain at that site (and a lot of shopping URLs have a lot of appended history so that it is relatively easily contrived that the consumer doesn't notice the domain name of the check-out/payment page). A lot of the requirement for encryption is end-to-end ... or at least VPN-like so encrypted packets should mostly be transparent to operations in their ISP roles. This isn't as true on the web-hosting side of the house ... where SSL or similar encryption activity can represent significant additional CPU processing load. -- 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: Who's afraid of Mallory Wolf?
- Original Message - From: Ed Gerck [EMAIL PROTECTED] To: Jeroen C. van Gelderen [EMAIL PROTECTED] Cc: Ian Grigg [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 24, 2003 11:20 PM Subject: Re: Who's afraid of Mallory Wolf? Jeroen C. van Gelderen wrote: 1. Presently 1% of Internet traffic is protected by SSL against MITM and eavesdropping. 2. 99% of Internet traffic is not protected at all. I'm sorry, but no. The bug in MSIE, that prevented the correct processing of cert path restraints and which led to easy MITM attacks, has been fixed for some time now. Consulting browser statistics sites will show that the MSIE update in question, fueled by the need for other security updates, is making good progress. Their is another bug that has not been fixed by MS that allows signed but invalid certificates to be used to MITM the browser as well with no notification. 3. A significant portion of the 99% could benefit from protection against eavesdropping but has no need for MITM protection. (This is a priori a truth, or the traffic would be secured with SSL today or not exist.) I'm sorry but the a priori truth above is false . Ignorance about the flaw, that is now fixed, and the need to do a LAN attack (if you want not to mess with the DNS) have helped avert a major public exploit. The hole is now fixed and the logic fails for this reason as well. 4. The SSL infrastructure (the combination of browsers, servers and the protocol) does not allow the use of SSL for privacy protection only. AnonDH is not supported by browsers and self-signed certificates as a workaround don't work well either. There is a good reason -- MITM. AnonDH and self-signed certs cannot prevent MITM. 5. The reason for (4) is that the MITM attack is overrated. People refuse to provide the privacy protection because it doesn't protect against MITM. Even though MITM is not a realistic attack (2), (3). But it is, please see the spoof/MITM method in my previous post. Which, BTW, is rather old info in some circles (3 years?) and is easy to do by script kiddies with no knowledge about anything we are talking here -- they can simply do it. Anyone can do it. (That is not to say that (1) can do without MITM protection. I suspect that IanG agrees with this even though his post seemed to indicate the contrary.) I think Ian's post, with all due respect to Ian, reflects a misconception about cert validation. The misconception is that cert validation can be provided as an absolute reference -- it cannot. The *mathematical* reasons are explained in the paper I cited. This misconception was discussed some 6 years in the ssl-talk list and other lists, and clarified at the time -- please see the archives. It was good, however, to post this again and, again, to allow this to be clarified. 6. What is needed is a system that allows hassle-free, incremental deployment of privacy-protecting crypto without people whining about MITM protection. You are asking for the same thing that was asked, and answered, 6 years ago in the ssl-talk and other lists. There is a way to do it and the way is not self-signed certs or SSL AnonDH. Now, this is could be achieved by enabling AnonDH in the SSL infrastructure and making sure that the 'lock icon' is *not* displayed when AnonDH is in effect. Also, servers should enable and support AnonDH by default, unless disabled for performance reasons. Problem -- SSL AnonDH cannot prevent MITM. The solution is not to deny the problem and ask who cares about MITM? Ed Gerck wrote: BTW, this is NOT the way to make paying for CA certs go away. A technically correct way to do away with CA certs and yet avoid MITM has been demonstrated to *exist* (not by construction) in 1997, in what was called intrinsic certification -- please see www.mcg.org.br/cie.htm Phew, that is a lot of pages to read (40?). Its also rather though material for me to digest. Do you have something like an example approach written up? I couldn't find anything on the site that did not require study. ;-) If anyone comes across a way to explain it, that does not require study, please let me know and I'll post it. OTOH, some practical code is being developed, and has been sucessfully tested in the past 3 years with up to 300,000 simultaneous users, which may provide the example you ask for. Please write to me privately if you'd like to use it. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
I get the impression that we're talking at cross-purposes here, with at least two different discussions. I suspect that the discussion started from commercial motivations; cf www.systemics.com /r$ - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Ben Laurie wrote: It seems to me that the difference between PGP's WoT and what you are suggesting is that the entity which is attempting to prove the linkage between their DN and a private key is that they get to choose which signatures the relying party should refer to. PGP's WoT already does that. To be clear, in PGP the entity that is attempting to prove the linkage between a DN and a public key chooses which signatures are acceptable, their degree of trust, and how these signatures became acceptable in the first place. BTW, a similar facility also exists in X.509, where the entity that is attempting to prove the linkage may accept or reject a CA for that purpose (unfortunately, browsers make this decision automatically for the user but it does not need to be so). That said, the paper does not provide a way to implement the method I suggested. The paper only shows that such a method should exist. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Who's afraid of Mallory Wolf?
Who's afraid of Mallory Wolf? By common wisdom, SSL is designed to defeat the so-called Man in the Middle attack, or MITM for short. Also known as Mallory, in crypto circles. The question arises, why? For what reason is the MITM a core part of the SSL threat model? And, why do all the implementations assume this? (It is, in fact, possible to use SSL, or TLS as it is now known, without regard to the MITM protection that is part of the model - certs - but I ignore that here, as do implementations!) One has to go back to the original invention of SSL, back in 1994 or so: the web was storming the barricades as the 2nd great killer application for the net (email was the 1st). Companies were dipping their toes into the endless possibilities of commerce. Netscape was evolving as the master of the new net, the challenge to Microsoft, the owner of all things it surveyed. And, as with all dot-com crazies to follow, it had nothing spectacular in the way of a business model. Selling a few secured servers, was all. This whole commerce thing was, at that time, a great wonder, because it involved earning money, and money that was honestly earnt was a precious short commodity at Netscape in those days. To cut a long story off at the knees, Netscape put together a variant of the HTTP protocol layered over crypto. This was sold in addition to its servers as the way to secure credit card payments over the net. The analysis of the designers of SSL indicated that the threat model included the MITM. On what did they found this? It's hard to pin it down, and it may very well be, being blessed with nearly a decade's more experience, that the inclusion of the MITM in the threat model is simply best viewed as a mistake. Consider this simple fact: There has been no MITM attack, in the lifetime of the Internet, that has recorded or documented the acquisition and fraudulent use of a credit card (CC). (Over any Internet medium.) Even worse, there's not been any known MITM of any aggresive form. The only cases known are a bunch of demos, under laboratory conditions. They don't count, and MITM remains a theoretical attack, more the subject of learnings and design exercises than the domain of business or crypto engineering. How hard is this fact? A bit softish, actually, but given the amount of traffic we have seen in the last decade, one would think that MITMs would have made their appearance in aggressive attacks by now, perhaps by scanning emails, perhaps by listening to unprotected HTTP. (In fact, there are now fertile grounds for the attack, with the advent of 802.11b. There are even kits available for it.) But so far, no cases have been found. (In fact, there isn't too much evidence, beyond the circumstantial bemoanings of those that can't, to indicate that aggressors are even passively listening, let alone trying more sophisticated MITM attacks.) Within the world of credit cards, the people who work directly within the ecommerce industry admit privately that this is true [1]. All lost credit card events are based on other attacks. Which leads one to wonder what the threat is? And if there is a threat? That is, should the MITM be in the threat model for SSL, or should it be excluded? Internet cryptography gives us one answer: If it can be protected against, it should be, as to do otherwise results in a false sense of security. This is what I call 100% cryptography for want of a better term. It's a sort of journeyman phase of crypto-plumbing, at that time when as beginners, we read from the big read book. We imagined how to deal with many dark and scary threats and we all agreed, no question, the goal was to cover more of them than the next guy. We would swap conspiracy theories well into the night, all the while, bemoaning the lack of usage of real cryptography, the poverty of our opponent's wit, and the fruitiness of our cheap red wine. I miss those days, if not the product of those mad times. It was also a time where we rarely saw the real life implications of our code, deployed in a threatening environment. In short, we 100%-ers built systems based on expectations, but we did not close the feedback loop to push the real life results back into the deployed systems. Economics gives us another answer: a standard approach to deciding how to spend money. 1. estimate the average cost of each attack. 2. estimate the number of attacks 3. multiply the above two to get a total cost. 4. likewise, estimate the total cost of avoiding the attacks. 5.a if you can avoid these attacks by spending less money, you profit. 5.b if you spend more than you save, you lose. It's just economics, and statistics, and the validity here is simply that credit cards are nothing if they are not economically- and statistically-based models of commerce and fraud. So, let's guess the cost of each CC lost to our MITM as $1000. (Pick your own number if you don't
Re: Who's afraid of Mallory Wolf?
On Sun, 23 Mar 2003, Ian Grigg wrote: Consider this simple fact: There has been no MITM attack, in the lifetime of the Internet, that has recorded or documented the acquisition and fraudulent use of a credit card (CC). (Over any Internet medium.) How do you view attacks based on tricking people into going to a site which claims to be affiliated with e.g. Ebay or Paypal, getting them to enter their login information as usual, and using that to steal money? It's not a pure MITM attack, but the current system at least makes it possible for people to verify with the certificate whether or not the site is a spoof. So, let's guess the cost of each CC lost to our MITM as $1000. (Pick your own number if you don't like that one.) Then, how many attacks? None, from the above. Multiplied together, and you get ... nothing. So, you claim that a system designed to make MITM attacks impossible has not suffered a successful MITM attack. Sounds rather tautologous to me. The software mandates it: mostly the browsers, but also the servers, are configured to kick up a stink at the thought of talking to a site that has no certificate. As such, SSL, as implemented, shows itself to include a gross failure of engineering. The system was engineered very well to requirements with which you disagree. [2] AFAIR, Anonymous-Diffie-Hellman, or ADH, is inside the SSL/TLS protocol, and would represent a mighty fine encrypted browsing opportunity. Write to your browser coder today and suggest its immediate employment in the fight against the terrorists with the flappy ears. Just out of interest, do you have an economic cost/benefit analysis for the widespread deployment of gratuitous encryption? It's just not that important. If your browsing privacy is important, you're prepared to click through the alarming messages. If the value of privacy is less than the tiny cost of clicking accept this certificate forever for each site, then it's not a convincing argument for exposing people who don't understand crypto to the risk of MITM. Pete - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
At 11:10 PM 3/23/2003 -0500, Ian Grigg wrote: Who's afraid of Mallory Wolf? slight observations ... i've heard of no cases of credit card number intercepted on the internet in flight (requiring crypto) ... and no known cases of MITM attack (requiring certificates) However there have been some cases of impersonation ... being directed to a counterfeit web-site. I know of no cases of that being done with DNS cache poisoning ... which is also what certificates are targeted at ... both MITM and other impersonations of various kind. the ones i'm aware of is that the person clicks on some URL and goes to that site which is a counterfeit website. This isn't caught by SSL ... since it just compares the domain name in the URL against the domain name in the certificate presented by the server. Since the subterfuge happens well before any DNS cache is involved ... the SSL check of matching domain names doesn't catch anything. There have also been various impersonation involving frames and other screen painting techniques. There have been cache poisonings (ip-address take over) ... there have been also incidents in the press of domain name hijacking ... sending updates to domain name infrastructure convincing them that somebody else is the new domain name owner. getting a new certificate as the new domain name owner is also a way of subverting the SSL check of matching domain names. http://www.garlic.com/~lynn/aepay4.htm#dnsinteg1 http://www.garlic.com/~lynn/aepay4.htm#dnsinteg2 people registering public keys at the same time they register domain names was one of the suggested countermeasures to domain name hijacking. There was another press thing last week regarding DNS attacks. The issue raised by the DNS attack last fall and the latest warning is that these have the potential to bring the internet to a halt. http://www.computerworld.com/securitytopics/security/story/0,10801,79576,00. html so there is some effort regarding dns integrity because of its critical importance for just having internet function at all. past dns attack refs: http://www.garlic.com/~lynn/2003.html#49 also http://www.computerworld.com/securitytopics/security/cybercrime/story/0,1080 1,75564,00.html http://www.zdnetindia.com/news/commentary/stories/73781.html http://www.zdnetindia.com/print.html?iElementId=73777 from a cost of business standpoint ... i've suggested why not use the existing DNS infrastructure to distribute server public keys in the same way they distribute ip-address (they are pieces of information bound to the domain name, a function of the domain name infrastructure) and are capable of distributing other things ... like administrative technical contacts although that is getting restricted ... some bleed over from pkix http://www.garlic.com/~lynn/aadsm13.htm#38 The case against directories http://www.garlic.com/~lynn/aadsm14.htm#0 The case against directories they could be naked public keys ... which would also be subject to DNS cache poisoning ... or they could be signed public keys doesn't need all the baggage of x509 certs ... can just be really simple signed public key. Slightly related to the above posting about long ago and far away when looking at allowing people (20 plus years ago) on business trips to use portable terminals/PCs to dial in and access the internal network/email a vulnerability assesement found that one of the highest problem areas was hotel PBXs. as a result a special 2400 baud encrypting modem was created. encrypting modem anecdote from the time: http://www.garlic.com/~lynn/2002d.html#11 Security Proportional to Risk (was: IBM Mainframe at home) ... these weren't in any related to the link encrypters from the previous reference (aka supposedly over half of the link encrypters in the world were installed on the internal network). in any case, there was a big concern about numerous kinds of evesdropping ... requiring encryption for information hiding. however, the current internet credit card scenario seems to be that it is so much easier to harvest a whole merchant file with tens or hundreds of thousands of numbers ... than trying to get them one or two at a time off some internet connection. note that the x9.59 approach has always been to remove the credit card numbers as a point of attack (form of shared-secret) by requiring all transactions to be authenticated. as a result, just knowing the number isn't sufficient for fraud (countermeasure against all account number harvesting regardless of the technique and whether insider or outsider attack): http://www.garlic.com/~lynn/index.html#x959 the low-hanging fruit theory is that if merchant sites were armored then there could be more interest in evesdropping-based harvesting ... (leading to more demand for internet encryption). However. armoring merchant sites is difficult since 1) there are potentially millions, 2) human mistake is frequent/common
Re: Who's afraid of Mallory Wolf?
In message [EMAIL PROTECTED], Ian Grigg writes: Who's afraid of Mallory Wolf? Even worse, there's not been any known MITM of any aggresive form. The only cases known are a bunch of demos, under laboratory conditions. They don't count, and MITM remains a theoretical attack, more the subject of learnings and design exercises than the domain of business or crypto engineering. Sorry, that's flat-out false. If nothing else, there was a large-scale MITM attack on the conference 802.11 net at the 2001 Usenix Security Symposium. Spammers are hijacking BGP prefixes; see http://www.merit.edu/mail.archives/nanog/2002-10/msg00068.html for one such incident. Eugene Kashpureff was pleaded guilty to domain-name hijacking; used very slightly differently, that's a MITM attack. See http://www.usdoj.gov/criminal/cybercrime/kashpurepr.htm for details. I warned of the possibility of hijacking via routing attacks in 1989, and via DNS attacks in 1995. (See the 'papers' directory on my Web site.) Given that the attacks were demonstrably feasible, Netscape would have been negligent not to design for it. Given that such attacks or their near cousins have actually occurred, I'd say they were right. And yes, you're probably right that no one has stolen credit card numbers that way. Of course, since the defense was in place before people had an opportunity to try, one can quite plausibly argue that Netscape prevented the attack - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Grigg counts the benefits of living in a MITM-protected world (no MITM attacks recorded), as though they would happen with or without MITM protection. Is there any reason to believe that's this is, in fact, true? That is, if zero dollars were spent on MITM protection, would there still be no recoreded attacks? Until that's answered, Grigg's economic analysis is flawed. I used to get picked on, but since I bulked up and learned karate, nobody's picked on me. I guess it was pointless to do those things. On Sun, 2003-03-23 at 23:10, Ian Grigg wrote: The question arises, why? For what reason is the MITM a core part of the SSL threat model? And, why do all the implementations assume this? [...] The analysis of the designers of SSL indicated that the threat model included the MITM. [...] Consider this simple fact: There has been no MITM attack, in the lifetime of the Internet, that has recorded or documented the acquisition and fraudulent use of a credit card (CC). -- -Dave Turner Stalk Me: 617 441 0668 I believe there is no righteousness in the situation in which we find ourselves. -Real Live Preacher - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
At 11:10 PM 3/23/2003 -0500, Ian Grigg wrote: Automatically generated self- signed FREEDOM CERTIFICATES, as a convenient temporary measure until widespread Anonymous- Diffie-Hellman is deployed in the field, would appear to strike the quickest and most cost- effective blow for Browsing Liberty [2]. Even if Anonymous DH was widely deployed, it might be better to use self-signed certs, or certs signed by an untrusted root - the browser could remember the cert, and warn the user this site has a different identity than last time. Or the browser could log the certs that are used for connections, and at some later date, if the user suspected MITM attacks, the user could review the logs for discrepancies - thus giving, if not tamper resistance against MITM attacks, at least the possibility for post-facto tamper detection. However, changing https to allow untrusted root certs without warnings might not be a good idea - users expect an https URL to be authenticated, so this changes the semantics. Maybe unauthenticated, ie opportunistic, encryption in HTTP with SSL/TLS should happen via something like the RFC 2817 upgrade mechanism? (I believe this particular mechanism has problems). The server could advertise that it supports opportunistic encryption, and a browser could choose it automatically, and the user wouldn't even be notified. Then https semantics could be left unchanged. Trevor - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Monday 24 March 2003 11:37, Peter Clay wrote: On Sun, 23 Mar 2003, Ian Grigg wrote: Consider this simple fact: There has been no MITM attack, in the lifetime of the Internet, that has recorded or documented the acquisition and fraudulent use of a credit card (CC). (Over any Internet medium.) How do you view attacks based on tricking people into going to a site which claims to be affiliated with e.g. Ebay or Paypal, getting them to enter their login information as usual, and using that to steal money? Yes, that's definately an attack. As was pointed out, the use of the cert seems to do two things: stop the MITM (via a secured key exchange so the listener cannot see inside the packets) and confirm the site as per what is stated in the URL. My post of last night addressed the MITM only. I completely ignored the issue of spoofing, which would only be possible if there is no complex relationship between them - which is a debateable point. It's not a pure MITM attack, but the current system at least makes it possible for people to verify with the certificate whether or not the site is a spoof. Does the cert stop spoofing? That's the question! If it does, then there might be value there. In which case we can measure it and construct a cost- benefit analysis to decide whether to protect against it. So, let's guess the cost of each CC lost to our MITM as $1000. (Pick your own number if you don't like that one.) Then, how many attacks? None, from the above. Multiplied together, and you get ... nothing. So, you claim that a system designed to make MITM attacks impossible has not suffered a successful MITM attack. Sounds rather tautologous to me. No, there has been little evidence of MITMs *outside* the system. (I said none, Steve Bellovin said some...) The fact that there are none within the system, yes, that would only show either the attacks were defeated, or there weren't going to be any, or that there are better pickings elsewhere... It doesn't allow you to conclude anything about the need for protection. Check Lynn Wheeler's new post (thanks Lynn!) which points to a lot of inside knowledge about the absence of any aggressive MITM activity inside the credit card world. And, see Steve Bellovin's post for some evidence of MITM outside the credit card world. The software mandates it: mostly the browsers, but also the servers, are configured to kick up a stink at the thought of talking to a site that has no certificate. As such, SSL, as implemented, shows itself to include a gross failure of engineering. The system was engineered very well to requirements with which you disagree. :-) Terms are always debatable! I'd say that engineering *includes* the appropriateness of the requirements. Science does not. Where I would agree: the _protocol_ was engineered very well to meet its requirements. It's not a bad protocol, by any logic. However, no protocol exists within a vacuum, this one exists within a _system_ that is commonly also known as SSL. (Therein lies a big problem here: I know of no separate term to distinguish SSL the protocol from SSL, the secure browsing system that you or I use to send our credit card numbers safely.) [2] AFAIR, Anonymous-Diffie-Hellman, or ADH, is inside the SSL/TLS protocol, and would represent a mighty fine encrypted browsing opportunity. Write to your browser coder today and suggest its immediate employment in the fight against the terrorists with the flappy ears. Just out of interest, do you have an economic cost/benefit analysis for the widespread deployment of gratuitous encryption? No, but it would be an interesting exercise! It's just not that important. It's interesting that you say that ... why is it then that people like Ben Laurie, Eric Young, Eric Rescola and others spent years writing and deploying software for free? Why do the people at Safari and Mozilla and Konqueror also spend all that time getting SSL to work? I don't claim to know the answer. But, if their answer is to protect credit card numbers well, actually, I don't think so! And that's the point of the rant: to identify some of these underlying assumptions like SSL protects your credit card numbers and reveal the truth or otherwise. Hopefully, if we can strip out the myths, we'll find the truth. If your browsing privacy is important, you're prepared to click through the alarming messages. If the value of privacy is less than the tiny cost of clicking accept this certificate forever for each site, then it's not a convincing argument for exposing people who don't understand crypto to the risk of MITM. People don't think like us techies do. They see the messages, and they ask for explanations from other people. Who may or may not know what it all means. The end result is the lowest common denominator - if there is a message, then something is wrong. And that's the point: if there is
Re: Who's afraid of Mallory Wolf?
On Monday 24 March 2003 13:02, Steven M. Bellovin wrote: In message [EMAIL PROTECTED], Ian Grigg writes: Who's afraid of Mallory Wolf? Even worse, there's not been any known MITM of any aggresive form. The only cases known are a bunch of demos, under laboratory conditions. They don't count, and MITM remains a theoretical attack, more the subject of learnings and design exercises than the domain of business or crypto engineering. Sorry, that's flat-out false. If nothing else, there was a large-scale MITM attack on the conference 802.11 net at the 2001 Usenix Security Symposium. Thanks Steve, now we are getting closer. 802.11b is where I'd been expecting it to happen, as the costs of the MITM come right down there. Would you characterise the attack as a bunch of techies mucking around, or would you characterise it as an aggressive attempt to gain a commercial advantage? I.e., did the attackers steal anything? Or did they just annoy people by showing how cool they were? I would surmise that's a techie conference, and is thus a demonstration, not a measurable risk. Spammers are hijacking BGP prefixes; see http://www.merit.edu/mail.archives/nanog/2002-10/msg00068.html for one such incident. I'm can't see clearly whether this is an MITM or a spoofing - did they stand in the middle and listen and divert? Or, did they just tell innocent servers to start re-routing traffic? It seems like an announcement of routes, and the listeners just believed... (But, it is an aggressive attack, someone tried to steal traffic for commercial gain.) I think you may be right in that my use of the term MITM is too broad. The cert in SSL protects against a cryptographic MITM in, for example, an ADH session. But, MITMs outside that are important measurable risks so we can create our threat model. The fact that this attack appears not to be analogous to the SSL-style MITM may or may not be relevant. Eugene Kashpureff was pleaded guilty to domain-name hijacking; used very slightly differently, that's a MITM attack. See http://www.usdoj.gov/criminal/cybercrime/kashpurepr.htm for details. From what I recall, this was a demo. He didn't do it to steal. He did it to highlight the business aspects. Sadly for him, he miscalculated (grossly, it seems). But, his case fits in the sense of not a criminal seeking to steal value, and therefore not a case of measurable risk. I warned of the possibility of hijacking via routing attacks in 1989, and via DNS attacks in 1995. (See the 'papers' directory on my Web site.) I certainly accept them as possible. That's not disputed, and never has been, as indeed, that was the whole thrust of the discussion: The SSL designers put the protection in because the threat was possible. They quite rightly offered the choice in the protocols. Where I am concerned is that they also wrongly forced the certificate path on browsers and servers. To our detriment, and to theirs.) Given that the attacks were demonstrably feasible, Netscape would have been negligent not to design for it. Given that such attacks or their near cousins have actually occurred, I'd say they were right. No, I'm afraid that does not hold. The reason we protect against attacks is because when they happen, they incur costs. But, designing in protection also incurs costs. We must do a cost-benefit analysis to decide if it is appropriate to protect against it. To say that attacks are feasible and therefore must be defended against is not how we work. We can guaruntee that you are immune to car accidents, simply by asking you to stay at home. You (probably) chose not to do so, because you chose to enjoy the higher benefit of travelling, as against the smaller expected cost of a suffering an accident. And yes, you're probably right that no one has stolen credit card numbers that way. Of course, since the defense was in place before people had an opportunity to try, one can quite plausibly argue that Netscape prevented the attack Right. But it's an empty argument if there is no need. We don't carry umbrellas when the sun is shining, only when the sky is grey. And, we don't build meteorite protection at all, even though we could, and they happen! We use information about real threats and how they hurt us to decide whether to worry about them. And that's why the question about MITMs is so key! The question is, is there a need? From several economic points of view, the need fails to show itself. And, the cost is quite high, both in cash, and lost security. Taking your links above at face value, I'll assume that the cost of stolen/hijacked IP number there was about $10,000 in lost business and customers being annoyed at unexpected porn. Say that happens once a metric month to some random victim ... or, $100,000 per year. That cost simply fails to justify any level of signed-certificate infrastructure, so, I'd conclude that the BGP protocol designers have done
Re: Who's afraid of Mallory Wolf?
Ian Grigg wrote: By common wisdom, SSL is designed to defeat the so-called Man in the Middle attack, or MITM for short. The question arises, why? One possible reason: Because DNS is insecure. If you can spoof DNS, you can mount a MITM attack. A second possible reason: It's hard to predict what attacks will become automated. Internet attacks seem to have an all-or-nothing feel: either almost noone exploits them, or they get exploited en masse. The latter ones can be really painful, if you haven't built in protection in advance. You could take your argument even further and ask whether any crypto was needed at all. After all, most attacks have worked by compromising the endpoint, not by sniffing network traffic. I'll let you decide whether to count this as a success story for SSL, or as indication that the crypto wasn't needed in the first place. (I'm a little skeptical of this argument, by the way, but hey, if we're playing devil's advocate, why not aim high?) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
Ian Grigg wrote: ... The analysis of the designers of SSL indicated that the threat model included the MITM. On what did they found this? It's hard to pin it down, and it may very well be, being blessed with nearly a decade's more experience, that the inclusion of the MITM in the threat model is simply best viewed as a mistake. I'm sorry to say it but MITM is neither a fable nor restricted to laboratory demos. It's an attack available today even to script kiddies. For example, there is a possibility that some evil attacker redirects the traffic from the user's computer to his own computer by ARP spoofing. With the programs arpspoof, dnsspoof and webmitm in the dsniff package it is possible for a script kiddie to read the SSL traffic in cleartext (list of commands available if there is list interest). For this attack to work the user and the attacker must be on the same LAN or ... the attacker could be somewhere else using a hacked computer on the LAN -- which is not so hard to do ;-) ... Clearly, the browsers should not discriminate against cert-less browsing opportunities The only sign of the spoofing attack is that the user gets a warning about the certificate that the attacker is presenting. It's vital that the user does not proceed if this happens -- contrary to what you propose. BTW, this is NOT the way to make paying for CA certs go away. A technically correct way to do away with CA certs and yet avoid MITM has been demonstrated to *exist* (not by construction) in 1997, in what was called intrinsic certification -- please see www.mcg.org.br/cie.htm Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Monday 24 March 2003 14:11, David Turner wrote: Grigg counts the benefits of living in a MITM-protected world (no MITM attacks recorded), as though they would happen with or without MITM protection. Is there any reason to believe that's this is, in fact, true? That is indeed the question, sans personal issues. That is, if zero dollars were spent on MITM protection, would there still be no recoreded attacks? Actually, I think that if zero dollars had been spent on MITM protection for SSL, then there may well have been some MITM attacks. That then would be a good position to be in, because we could measure the costs of those attacks, and decide from a monetary perspective whether protection at the level of requiring signed certificates is a good thing or just a waste of money. My own guess is that MITM activity is so low across all domains of the net that we would not be able to reliably measure it, and if we could measure it, we'd find it not sufficient to mandate certificates as is currently done. Which - to repeat - is not to remove certs from the servers or browser, but to change the way in which we assume that only cert-protected browsing is good enough. The certs are really good for high end sites (because, economically, they return benefits even if there was no MITM threat). But why are they needed for smaller things? Why do I need a certficate to run an SSL server so that my family can share snapshots for instance? Just a hypothetical... Until that's answered, Grigg's economic analysis is flawed. I used to get picked on, but since I bulked up and learned karate, nobody's picked on me. I guess it was pointless to do those things. You provided your own answer :-) You used to get picked on, so you had a measure of its cost. You acted to defend against those costs. Did you ever get MITM'd? Anywhere? Any time? Anyone you know? -- iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Mon, 24 Mar 2003, Peter Clay wrote: On Sun, 23 Mar 2003, Ian Grigg wrote: Consider this simple fact: There has been no MITM attack, in the lifetime of the Internet, that has recorded or documented the acquisition and fraudulent use of a credit card (CC). (Over any Internet medium.) There have, however, been numerous MITM attacks for stealing or eavesdropping on email. A semi-famous case I'm thinking of involves a rabid baptist minister named fred phelps and a topeka city councilwoman who had the audacity to vote against him running roughshod over the law. He set up routing tables to fool DNS into thinking his machine was the shortest distance from the courthouse where she worked to her home ISP and eavesdropped on her mail. Sent a message to every fax machine in town calling her a Jezebellian whore after getting the skinny on the aftermath of an affair that she was discussing with her husband. And as for theft of credit card numbers, the lack of MITM attacks directly on them is just a sign that other areas of security around them are so loose no crooks have yet had to go to that much trouble. Weakest link, remember? No need to mount a MITM attack if you're able to just bribe the data entry clerk. Just because most companies' security is so poor that it's not worth the crook's time and effort doesn't mean we should throw anyone who takes security seriously enough that a MITM vulnerability might be the weakest link to the wolves. How do you view attacks based on tricking people into going to a site which claims to be affiliated with e.g. Ebay or Paypal, getting them to enter their login information as usual, and using that to steal money? These, technically speaking, are impostures, not MITM attacks. The web makes it ridiculously easy. You can use any linktext or graphic to link to anywhere, and long cryptic URL's are sufficiently standard practice that people don't actually look at them any more to notice a few characters' difference. On the occasions where people have actually spoofed DNS to route the correct URL to the wrong server in order to get info on people's accounts, that is a full-on MITM attack. And that definitely has happened. I'm surprised to hear someone claim that credit card numbers haven't been stolen that way. I've been more concerned about email than credit cards, so I don't know for sure, but if credit cards haven't been stolen this way then the guys who want them are way behind the guys who want to eavesdrop on email. [2] AFAIR, Anonymous-Diffie-Hellman, or ADH, is inside the SSL/TLS protocol, and would represent a mighty fine encrypted browsing opportunity. Write to your browser coder today and suggest its immediate employment in the fight against the terrorists with the flappy ears. Just out of interest, do you have an economic cost/benefit analysis for the widespread deployment of gratuitous encryption? This is a simple consequence of the fact that the main market for SSL encryption is financial transactions. And no credit card issuer wants fully anonymous transactions; it leaves them holding the bag if anything goes wrong. Anonymous transactions require a different market, which has barely begun to make itself felt in a meaningful way (read: by being willing to pay for it) to anyone who has pockets deep enough to do the development. Bear - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
On Monday, Mar 24, 2003, at 11:37 US/Eastern, Peter Clay wrote: On Sun, 23 Mar 2003, Ian Grigg wrote: Consider this simple fact: There has been no MITM attack, in the lifetime of the Internet, that has recorded or documented the acquisition and fraudulent use of a credit card (CC). (Over any Internet medium.) How do you view attacks based on tricking people into going to a site which claims to be affiliated with e.g. Ebay or Paypal, getting them to enter their login information as usual, and using that to steal money? It's not a pure MITM attack, but the current system at least makes it possible for people to verify with the certificate whether or not the site is a spoof. Correct. On the other hand, in a lot of cases people cannot be expected to do the verification. This shows in the number of people that can be tricked into being spoofed out of their passwords, even when certificates are deployed. That is not an argument against certificates though, it is (partially) an argument against broken user interfaces. Just out of interest, do you have an economic cost/benefit analysis for the widespread deployment of gratuitous encryption? What makes you say it is gratuitous? Or: how can you state my privacy is gratuitous? It's just not that important. If your browsing privacy is important, you're prepared to click through the alarming messages. If the value of privacy is less than the tiny cost of clicking accept this certificate forever for each site, then it's not a convincing argument for exposing people who don't understand crypto to the risk of MITM. This is illogical. Even if a server operator would prefer to allow unauthenticated encryption, he cannot do so without annoying 90% of his customers because they too will be getting these alarming messages. In general, if my browsing privacy is important to me and the server operator is willing to accomodate me, he cannot do so. This however still does not constitute an argument against certificates. It can be morphed as an argument against browsers not supporting Anonymous-DH. (Note that I'm favoring treating sites offering ADH the same as sites offering a certificate. Each offers different functionality which should be distinguishable in the GUI.) Cheers, -J -- Jeroen C. van Gelderen - [EMAIL PROTECTED] The python has, and I fib no fibs, 318 pairs of ribs. In stating this I place reliance On a séance with one who died for science. This figure is sworn to and attested; He counted them while being digested. -- Ogden Nash - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Who's afraid of Mallory Wolf?
So far, as I see it, this is not an issue of specific SSL protocol, but of unrestrictive browser to user interfacing. The only MITM attacks that have been practical valid attacks as of lately were specific to microsoft browser issues when interfacing with SSL. On another note, MITM attacks on SSL, is strictly a user education issue. How many users know what a fingerprint is, or what it is designed for? Unless we either force the browser to be that strict and never interface with unseen or untrusted fingerprints (impractical), what can you do? - Original Message - From: Jeroen C. van Gelderen [EMAIL PROTECTED] To: Peter Clay [EMAIL PROTECTED] Cc: Ian Grigg [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, March 24, 2003 4:50 PM Subject: Re: Who's afraid of Mallory Wolf? On Monday, Mar 24, 2003, at 11:37 US/Eastern, Peter Clay wrote: On Sun, 23 Mar 2003, Ian Grigg wrote: Consider this simple fact: There has been no MITM attack, in the lifetime of the Internet, that has recorded or documented the acquisition and fraudulent use of a credit card (CC). (Over any Internet medium.) How do you view attacks based on tricking people into going to a site which claims to be affiliated with e.g. Ebay or Paypal, getting them to enter their login information as usual, and using that to steal money? It's not a pure MITM attack, but the current system at least makes it possible for people to verify with the certificate whether or not the site is a spoof. Correct. On the other hand, in a lot of cases people cannot be expected to do the verification. This shows in the number of people that can be tricked into being spoofed out of their passwords, even when certificates are deployed. That is not an argument against certificates though, it is (partially) an argument against broken user interfaces. Just out of interest, do you have an economic cost/benefit analysis for the widespread deployment of gratuitous encryption? What makes you say it is gratuitous? Or: how can you state my privacy is gratuitous? It's just not that important. If your browsing privacy is important, you're prepared to click through the alarming messages. If the value of privacy is less than the tiny cost of clicking accept this certificate forever for each site, then it's not a convincing argument for exposing people who don't understand crypto to the risk of MITM. This is illogical. Even if a server operator would prefer to allow unauthenticated encryption, he cannot do so without annoying 90% of his customers because they too will be getting these alarming messages. In general, if my browsing privacy is important to me and the server operator is willing to accomodate me, he cannot do so. This however still does not constitute an argument against certificates. It can be morphed as an argument against browsers not supporting Anonymous-DH. (Note that I'm favoring treating sites offering ADH the same as sites offering a certificate. Each offers different functionality which should be distinguishable in the GUI.) Cheers, -J -- Jeroen C. van Gelderen - [EMAIL PROTECTED] The python has, and I fib no fibs, 318 pairs of ribs. In stating this I place reliance On a séance with one who died for science. This figure is sworn to and attested; He counted them while being digested. -- Ogden Nash - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
