From: Ian Grigg <iang@systemics.com>
To: cryptography@wasabisystems.com
Subject: Who's afraid of Mallory Wolf?
Date: Sun, 23 Mar 2003 23:10:22 -0500
Who's afraid of Mallory Wolf?
By common wisdom, SSL is designed to defeat
the so-called "Man in the Middle" attack, or
MITM for short.
Also known as Mallory, in crypto circles.
The question arises, why? For what reason is
the MITM a core part of the SSL threat model?
And, why do all the implementations assume this?
(It is, in fact, possible to use SSL, or TLS
as it is now known, without regard to the MITM
protection that is part of the model - certs -
but I ignore that here, as do implementations!)
One has to go back to the original invention
of SSL, back in 1994 or so: the web was storming
the barricades as the 2nd great killer application
for the net (email was the 1st). Companies were
dipping their toes into the endless possibilities
of commerce.
Netscape was evolving as the master of the new
net, the challenge to Microsoft, the owner of
all things it surveyed.
And, as with all dot-com crazies to follow, it
had nothing spectacular in the way of a business
model. Selling a few secured servers, was all.
This whole commerce thing was, at that time, a
great wonder, because it involved earning money,
and money that was honestly earnt was a precious
short commodity at Netscape in those days.
To cut a long story off at the knees, Netscape
put together a variant of the HTTP protocol
layered over crypto. This was sold in addition
to its servers as the way to secure credit card
payments over the net.
The analysis of the designers of SSL indicated
that the threat model included the MITM.
On what did they found this? It's hard to pin
it down, and it may very well be, being blessed
with nearly a decade's more experience, that
the inclusion of the MITM in the threat model
is simply best viewed as a mistake.
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.)
Even worse, there's not been any known MITM of
any aggresive form. The only cases known are
a bunch of demos, under laboratory conditions.
They don't count, and MITM remains a theoretical
attack, more the subject of learnings and design
exercises than the domain of business or crypto
engineering.
How hard is this fact? A bit softish, actually,
but given the amount of traffic we have seen
in the last decade, one would think that MITMs
would have made their appearance in aggressive
attacks by now, perhaps by scanning emails,
perhaps by listening to unprotected HTTP.
(In fact, there are now fertile grounds for the
attack, with the advent of 802.11b. There are
even kits available for it.)
But so far, no cases have been found. (In
fact, there isn't too much evidence, beyond
the circumstantial bemoanings of those that
can't, to indicate that aggressors are even
passively listening, let alone trying more
sophisticated MITM attacks.)
Within the world of credit cards, the people
who work directly within the ecommerce industry
admit privately that this is true [1]. All lost
credit card events are based on other attacks.
Which leads one to wonder what the threat is?
And if there is a threat? That is, should the
MITM be in the threat model for SSL, or should
it be excluded?
Internet cryptography gives us one answer:
If it can be protected against, it should
be, as to do otherwise results in a false
sense of security.
This is what I call "100% cryptography" for want
of a better term. It's a sort of journeyman
phase of crypto-plumbing, at that time when as
beginners, we read from the big red* book. We
imagined how to deal with many dark and scary
threats and we all agreed, no question, the goal
was to cover more of them than the next guy.
We would swap conspiracy theories well into the
night, all the while, bemoaning the lack of usage
of real cryptography, the poverty of our opponent's
wit, and the fruitiness of our cheap red wine.
I miss those days, if not the product of those
mad times. It was also a time where we rarely
saw the real life implications of our code,
deployed in a threatening environment. In
short, we 100%-ers built systems based on
expectations, but we did not close the feedback
loop to push the real life results back into
the deployed systems.
Economics gives us another answer: a standard
approach to deciding how to spend money.
1. estimate the average cost of each attack.
2. estimate the number of attacks
3. multiply the above two to get a total
cost.
4. likewise, estimate the total cost of
avoiding the attacks.
5.a if you can avoid these attacks by
spending less money, you profit.
5.b if you spend more than you save, you lose.
It's just economics, and statistics, and the
validity here is simply that credit cards are
nothing if they are not economically- and
statistically-based models of commerce and
fraud.
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.
What does that mean? This theory predicts
that if you spend one cent protecting against
the MITM, you lose. Because according to an
economics and statistics analysis, based on
there being no measurable risk to you of MITM,
there is no reason to spend any money to avoid
it.
If one believes in economics - or, at least,
the above risks and costs model, then it
becomes very important indeed to quantify the
threat. If there is no experience of MITMs
and there are no consequent costs, then the
model suggests no threat.
Is there a compromise? Well, there is the other
side of the equation. Let's look at that: the
inclusion of MITM protection comes at a cost.
That cost should be estimated and compared to
the losses from any MITMs.
(If there were any. Regardless, we can be more
ready for that day; I feel in my bones it is
going to happen one day. I mean, 10 million
unprotected sites, there's gotta be a time
coming soon!)
A "good" server cert costs about $700. The
average cost of installing it - from start to
finish - at an average company seems to run to
many days elapsed, but let's estimate it at 6
hours time.
Why so long? Because it is infrequent and
unautomated. There are dozens of single
steps to go through. Due diligence, documents,
and the like all of which befuddle the techie,
challenge the manager, and daunt the quality
controller.
Call the cost at your average western company
as $50 per hour, and we have an estimate of
$300 for time. Forget other costs, but what
we can do is estimate the cost per certificate
as $1000 as a ballpark.
I think it is more, but call it $1000. Multiply
by the number of certificates in operation,
about 100,000, and we get a cost incurred of
$100 million to protect against the MITM.
Every year, or however often the certificates
expire, we, as a networked society, are spending
$100 million dollars to avert something that
doesn't exist.
Back to that compromise.
Imagine 10 MITMs successfully steal credit
cards and organise successful heists of $1000
each. $10,000 of value is thus being protected.
Society - that's us, all of us - is losing big
time. We would need to see 100,000 MITMs at
that size to justify the infrastructure.
Or, 100 sheiks with million dollar cards!
And that's just to break even. We need more
to cut a profit.
This is totally ludicrous. These numbers are
just unmalleable to achieving any sort of
aggregate benefit to society.
So, we can suggest that, not only is there no
measureable threat from the MITM (Mallory is
not to be found anywhere near any credit cards
known to the issuers of same) there is also
rampant waste going on in protecting servers
against some imagined bogey man with a silly
name like Mallory.
Now, for a particular server, any given server,
it *might* be prudent to protect against the MITM.
Maybe the server owner has a higher threat model
than the ordinary purveyor of goods. Maybe the
users demand it. Or maybe the owner has more
money and simply doesn't care about saving it.
All of which is well and good, *if* the owner
was solely capable of this decision. That is,
spending own money. But, in the web world of
today, the owner has no choice. If encrypted
communications are required - useful to stop a
simple listening attack - then a certificate is
required!
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 threat is not present, but the browsers
mandate the protection. As they migrate from
unprotected to protected browsing, users are
coralled into certware, as if that made any
difference.
Clearly, the browsers should not discriminate
against cert-less browsing opportunities.
Indeed, I'd go further. If a self-signed cert
was encountered, the browser should praise the
user's choice:
Congratulations!
You have selected a site that wisely protects
our communications with a FREEDOM CERTIFICATE,
designed to thwart scurillous and undesired
spies and help win the war against the axis
of evil listeners!
As the servers cannot communicate so readily
with the user, they would have to limit their
fight against waste and misallocated resources
by configuring with the best protection fastest
and up front. Automatically generated self-
signed FREEDOM CERTIFICATES, as a convenient
temporary measure until widespread Anonymous-
Diffie-Hellman is deployed in the field, would
appear to strike the quickest and most cost-
effective blow for Browsing Liberty [2].
iang
[1] See for example, Lynn Wheeler, 17th March,
2003:
.... Now SSL protects credit card numbers
while in flight. However, we never
actually saw a reported exploit against
credit card numbers in flight. All the
reported instances of major credit card
exploits have to do with harvesting
of credit card merchant files ... at
rest at the merchant. So for the major
exploit, SSL has no effect on.
http://www.garlic.com/~lynn/subpubkey.html#fraud
[2] 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.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@wasabisystems.com
* [Author's note - I corrected one spelling mistake from the original email: big read book ==> big red book.]