By (2) I guess you mean a bypass MITM?
I'm not sure what you mean by "bypass". I'm talking about attacks where the attacker cons you into dereferencing the wrong URL.
That's what I mean. The normal security checks ot the system have been bypassed, in this case, by having the browser think that this is a different, never seen before URL that doesn't need checking.
(3) Active attacks on the network infrastructure.
By (3) I guess you mean a protocol level MITM.
Then, there is:
(4) Active attacks against the client. By this I mean hacking the client, installing a virus, malware, spyware or whathaveyou. (This is now real, folks.) (5) Active attacks against the server. Basically, hacking the server and stealing all the good stuff. (This has always been real, ever since there have been servers.) (6), (7) Insider attacks against client, server. Just read off the data and misuse it. (This has been real since the dawn of time...)
Of course, SSL/SB doesn't protect against any of these, and many people therefore assume the thinking stops there. Sadly, no. Even though SSL doesn't protect against these attacks, the frequency & cost of these attacks directly impacts on the design choices of secure browsing.
How? No COMSEC protocol that anybody is seriously considering protects against these attacks. The secure payment protocols that involve signing sort of do, except that they don't protect against all sorts of account-based attacks.
Well, there are two things here: firstly, as you recognise, there are protocols that protect against these things (some better than others, but that's not a debate for the moment).
Secondly, I can only repeat what I wrote:
"Of course, SSL/SB doesn't protect against any of these, and many people therefore assume the thinking stops there. Sadly, no. Even though SSL doesn't protect against these attacks, the frequency & cost of these attacks directly impacts on the design choices of secure browsing."
The assumption here that the SSL crowd made was something like what you said - No COMSEC protocol protects against these things. But, that doesn't mean that we now have an excuse to implement a COMSEC protocol and ignore those things. No, in contrast, it means that if we are in the unfortunate position of having to implement a COMSEC protocol that only achieves fairly minor protection, we should recognise the limitations of that, and not try any harder to get it right than is dictated by the other threats to the system.
E.g., if credit cards are being stolen in the thousands by hackers, insiders and viruses (the first two are true at least) then there may not be much point in protecting them on the wire with anything more serious than 10 bit crypto and ADH.
SSL does a fine job of protecting against (1) and a fairly adequate job of protecting against (3). Certainly you could do a better job against (3) if either: (a) You could directly connect to sites with SSL a la https://www.expedia.com/ (b) The identities were more user-friendly as we anticipated back in the days of S-HTTP rather than being domain names, as required by SSL. It does a lousy job of protecting against (3).
Sorry, I'm having trouble parsing "fairly adequate" versus "lousy job" for threat (3)... Both (a) and (b) seem to deserve some examples? I can connect directly to expedia, and https://www.paypal.com/ is friendly enough?
I thought they were fairly obvious: (a) Given that you know Expedia's URL and you type it in, and you get SSL, and the certificate is from a real CA, then you are indeed protected against all conceivable network-level MITM attacks.
Right, now I understand. Apologies for disagreeing in advance, but that's now what we'd consider to be an unlikely future for most normal practice. Nobody is going to take the customer's click URL feature away.
(b) If customers were able to actually examine the name of the site they were connecting to, and it was human readable, e.g. "Microsoft Expedia" or a logo or whatever, phishing would be a lot harder.
(Reference here to Amir's paper, and my comments on branding box.) I think we are stuck with the identities we have now. URLs aren't going to change, and not- withstanding calls for the abolition of this or that, the SSL/TLS/CA structure is here to stay.
Now, my threat model mostly includes (1), does not really include (3), and I'm careful not to do things that leave me susceptible to (2), so SSL does in fact protect against the attacks in my threat model. I know a number of other people with similar threat models. Accordingly, I think the claim that "secure browsing is not secure" rather overstates the case.
(1) OK. Now, granted, SSL protects against (1), "fairly finely." It does so in all its guises, although the CA-signed variant in secure browsing does so at some additional unneeded expense, as it eliminates certain secure options, being SSCs and ADH. OTOH, this is a really rare attack - actual damage from sniffing HTTP traffic doesn't seem to be recorded anywhere as a real attack on people, so forgive me if I downgrade this one as "almost not a threat."
Don't be silly. It's not a threat because people generally use SSL. Back in the old days, password capture was a very serious threat. It went away with SSH. It seems to me quite likely that it would be a problem with web browsing in the absence of SSL.
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.
In absence of enough data, we have to construct some sort of crook's equation to determine whether it is a threat. Every analysis of what a crook does shows that sniffing credit cards is the poorest way to acquire them. And conducting an MITM is just dumb - I suppose we could bother to worry about MITM in order to catch the dumbest of the dumb, but I'm not sure why anyone would want to spend a dime doing that, as they almost certainly are going to present other cheaper opportunities.
Further, there is a non-trivial proportion of activity where credit cards are in fact sent over the net - to merchants that simply don't care about the rules, and can't afford the high price set by the SSL system. Likewise, there is a huge amount of unprotected traffic of other forms, like legal documents, but we never hear of people being caught sniffing that.
The balance of evidence suggests that there is no high or serious threat to credit card info moving across the net in the clear. Nothing worth paying for, at the least.
...
(And we haven't even begun on (4) thru (7). What then, is a threat model that only includes some threats?)
So, your argument is that one shouldn't wear body armor (which only protects against bullets) because someone might nuke you? Don't be ridiculous.
No. My argument is that one shouldn't wear body armour because it costs money to buy, it is heavy, causes chaffing of the skin, and the point of it is lost as no-one is going to shoot you as you walk around the mall.
I don't see what is so ridiculous about that. Neither does the rest of humanity. It's only the cryptography community that likes to create the FUD, and then pretend to solve it, by telling people that they are being ridiculous for not wearing their body armour. Or by mandating it.
Perhaps we should ask the residents of the greater Washington, DC area how many of them decided to wear body armour when that sniper was at large? A few, I'll bet. But 99% of the people maintained their sense of reality and went about their lives with only a nod to the new situation - why? Because they knew it was ridiculous to consider changing their patterns when the risk levels changed in such an immeasurable fashion.
(Quick calculation - 4 million in the area? More than 100 deaths per day due to other causes. What's one more? The answer is: don't panic. Don't wear body armour.)
So in sum, I think my argument remains unchallenged: secure browsing fails to secure.
It certainly does not remain unchallenged. As I said, given the actual threat model as it actually obtains, secure browsing indeed provides some, but not total protection. Nothing wrong with that.
The threat model is really quite clear. Yes, we all agree on that. What is not clear is that it obtains. Try and show that - it's quite hard to do.
> Yes, it's
disappointing that there's a new attack, but at heart phishing is a con job. It's no more a failing of SSL/TLS that it doesn't protect against it than that it doesn't protect you if you're conned into typing your credit card in the clear.
Ah, so a) it's a con job, so it's important to recognise that we don't protect against it, because the victim was conned and we don't protect the stupid. Curiously, most don't agree. The whole browser community has worked on the principle that the system of secure browsing is designed to protect those who aren't as adept as the power users. So, phishing is right there in the ambit.
Then, b) it's secure browsing that we are talking about, not just the wire protocol - so we need to include SSL/TLS, the CA-signed certificate model that comes joined at the hip with it (check the RFC for warnings) and also the security presentation within the browser, which is strongly influenced by the other two things. That all is what is failing.
Then, c) as a matter of fact, secure browsing, and SSL/TLS *and* certs could do a mighty fine job of protecting against phishing - because the relationship exists, and the browser knows that. The problem is, the browser does its best to hide the relationship, when it should be doing its best to surface the relationship a user has with her bank.
Which leads to d) which is the assumption that in secure browsing, the connection that needs to be protected is one whereby there is no prior relationship. That's why we need the CA-signed cert, right? Because we don't have a prior relationship with the server, we need someone, a TTP, to stand in and provide that.
That assumption is wrong. In general, and in detail, but with phishing, it's completely the reverse - there is a prior relationship, and that relationship is strong. It's called a bank account.
Finally e), all logical and connected because security practice should be a science, not a belief system, and we have the fact that any certificate can protect the user's relationship with her bank, because it measures the *persistence* of that relationship. So, SSCs have much to offer in protecting against phishing, in fact, almost as much as CA-signed certs (unless TCA/branding comes into play).
Which leaves f) that if the SSL/TLS infrastructure were to be used to protect against phishing, then we would have to acknowledge that SSCs can do a good job, in which case, why did we spend so much time destroying their reputation in the last decade?
And, g) it is much much easier to simply state over and over that phishing is a con job and the user should protect themselves. Elsewise, we have to look into the abyss of what we really meant by the assumption that there is no prior relationship.
That said, I don't have any illusions that I'll convince you and I have no desire to get involved in an endless debate. Accordingly, I'll end my half of the conversation here. Feel free to have the last word.
Well, I apologise for writing all the above before reading your last words. You and me both:
http://www.financialcryptography.com/mt/archives/000169.html
iang
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
