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.) > >  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 nothing wrong, the browser shouldn't say there is something wrong! So, what is this "risk of MITM" that the browser is protecting us against? -- iang --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]