Eric Rescorla wrote:
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

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
(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 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

(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

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

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

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:


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]

Reply via email to