Using crypto against Phishing, Spoofing and Spamming...

[Eric Rescorla]

Ian Grigg <iang at systemics.com> writes:

> Eric Rescorla wrote:
>> Ian Grigg <iang at systemics.com> writes:
>>
>>>Notwithstanding that, I would suggest that the money
>>>already lost is in excess of the amount paid out to
>>>Certificate Authorities for secure ecommerce certificates
>>>(somewhere around $100 million I guess) to date.  As
>>>predicted, the CA-signed certificate missed the mark,
>>>secure browsing is not secure, and the continued
>>>resistance against revision of the browser's useless
>>>padlock display is the barrier to addressing phishing.
>> I don't accept this argument at all.
>> There are at least three potential kinds of attack here:
>> (1) Completely passive capture attacks.
>> (2) Semi-active attacks that don't involve screwing with
>>     the network infrastructure (standard phishing attacks)
>
> 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.

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


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

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


> (2) Then we come to (2), what i'd call a bypass MITM.  Or
> a phish or a spoof.   (I'm not sure what "semi active"
> and "infrastructure" have to do with it.) 

What they have to do with it is that although the attacker
is actively sending you mail, they're not intercepting the
connection as they would in a standard active attack.


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


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

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.

-Ekr

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com