thanks for addressing the issues with some actual anecdotal evidence. The conclusions still don't hold, IMHO.
Steven M. Bellovin wrote:
In message <[EMAIL PROTECTED]>, Ian Grigg writes:
Right... It's easy to claim that "it went away" because we protected against it. Unfortunately, that's just a claim - there is no evidence of that.
This is why I ask whether there has been any evidence of MITMs, and listening attacks. We know for example that there were password sniffing attacks back in the old days, by hackers. Hence SSH. Costs -> Solution.
But, there is precious little to suggest that credit cards would be sniffed - I've heard one isolated and unconfirmable case. And, there is similar levels of MITM evidence - anecdotes and some experiences in other fields, as reported here on this list.
I think that Eric is 100% correct here: it doesn't happen because it's a low-probability attack, because most sites do use SSL.
The trick is to show cause and effect. We know the effect and we know the cause(s). The question is, how are they related? The reason it is important is that we may misapply one cause if the effect results from some other cause.
I think that people are forgetting just how serious the password capture attacks were in 1993-94. The eavesdropping machines were on backbones of major ISPs; a *lot* of passwords were captured.
Which led to SSH, presumably, and was pre-credit card days, so can only be used as a prediction of eavesdropping.
Question - are we facing a situation today whereby it is easy to eavesdrop from the backbone of a major ISP and capture a lot of traffic? As far as I can see, that's not likely to happen, but it could happen.
Secondly, who were the people doing those attacks? Back in 93-94, I'd postulate they weren't criminal types, but hacker types. That is, they were hackers looking for machines. Those people are still around - defeated by SSH in large measure - and use other techniques now. (Hackers had no liability in those days. Criminals do have liability, and are more concerned to cover their tracks. This makes active attacks less useful to them. Criminals are getting braver though.)
Thirdly, why aren't we seeing more reports of this on 802.11b networks? I've seen a few, but in each case, the attack has been to hack into some machine. I've yet to see a case where listeners have scarfed up some free email account passwords, although I suppose that this must happen.
The point of all this is that we need to establish how frequent and risky these things are. Back in the pre- commerce days, a certain amount of FUD was to be expected. Now however, it's been a decade - whether that FUD was warranted then is an issue for the historians, but now we should be able to scientifically make a case that the posture matches the threats. Because it's been a decade (almost).
As far as I can see, there *some* justification for expecting eavesdropping attacks to credit cards. There is a lot more justification with unprotected non-commerce. And in contrast, there is little justification for expecting active attacks for purposes of theft.
What this leads to is not whether SSL should have been deployed or changed in its current form (it is fruitless to debate that, IMHO, except in order to lay down the facts) but a discussion of certificates.
There seems some justification in suggesting that SSL be (continued to be) deployed in any form. Mostly, IMHO, in areas outside commerce, and mostly, in the future, not now.
There seems a lot of justfication for utilising certs as they enable relationship-protection. There seems quite a bit of justification for utilising CA-signed certs because they permit more advanced relationship protection such as Amir's logo ideas and my branding ideas, and more so every day.
What there doesn't appear to be any justification for is the effective or defacto mandating of CA-signed certs. And there appears to be a quite serious cost involved in that mandating - the loss of protection from the resultant *very* low levels of SSL deployment.
This all hangs on the MITM - hence the question of frequency. It seems to be very low, an extraordinarily desparate attack for a criminal, especially in the light of experience. He does phishing and hacking with ease, but he doesn't like leaving tracks in the infrastructure that point back to him.
If the MITM cannot be justified as an ever-present danger, then there is no justification for the defacto mandating of CA-signed certs. Permitting and encouraging self-signed certs would then make deployment of SSL much easier, and thus increase use of SSL - in my view, dramatically - which would lead to much better protection. (Primarily by relationship management on the client side, and also by branding/logo management with the CAs, but that needs to be enabled in code first at the browsers.)
(It has to be said that encouraging anon-diffie-hellman SSL would also lead to dramatically improved levels of SSL deployment and thus protection as well. But since RFC deprecates that, it simply becomes a higher burden to show.)
Furthermore, the technology has improved -- have you looked at dsniff lately, with the ARP-based active attack capability? And credit cards are much easier to grab -- they're probably sent in one packet, instead of several, and the number is a self-checking string of digits.
Well, I think the thing here would be that credit cards are sent in forms, so POSTs, and some sort of scanning and interpretation would be required. If it was an issue, it would be a mildly interesting problem to design and test scanning software. But it's not an issue, so we don't hear of it. I believe the reason we don't hear of it is that even over the open nets, the notion of scanning for masses of credit cards would be too risky. Poor ROI, to use Lynn's term. I think eavesdropping is a much bigger risk for other purposes, and deploying more SSL would address that. But, for reasons outlined logic above, deployment of SSL remains constrained.
It's also worth remembering that an SSL-like solution -- cryptographically protecting the transmission of credit card number, instead of digitally signing a funds transfer authorization linked to some account -- was more or less the only thing possible at the time. The Internet as a medium of commerce was too new for the banks to have developed something SET-like, and there wasn't an overwhelmingly-dominant client platform at the time for which custom software could be developed. (Remember that Windows 95 was the first version with an integral TCP/IP stack.) *All* that Netscape could deploy was something that lived in just the browser and Web server. SET itself failed because the incentives were never there -- consumers didn't perceive any benefit to installing funky software, and merchants weren't given much incentive to encourage it.
(That's plausible, and has some good observations which I'd love to debate but feel the need to focus on SSL and now and low levels of deployment and thus protection.)
PS: in all the above I refer to SSL as the protocol, sans key exchange.
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]