The Maginot Web

[Ian Grigg]

The Maginot Web

http://www.iang.org/ssl/maginot_web.html



The by-now infamous signed certificate was
deployed for two reasons, being, a) to stop the
MITM, and b) to stop the spoof. 

The MITM - man in the middle - is an attack
possible when the attacker is already in the middle
of two communicating endpoints, and thus has an
ability to change the packets as they go through
his service. 

Then, he simply presents one sequence of packets
upstream, and a second, distinct sequence of
packets upstream.  If those packets were intended
to set up a secure session, our attacker can set
up two secure sessions, one upstream, the other
downstream, and copy from one to the other. 

The certificate is used to defeat this, by using
an authenticated key exchange to bootstrap into a
secure session.  As the key exchange is signed (a
brief description not doing justice to the full
story) the MITM cannot change the signed key without
revealing the attack. 



The spoof, on the other hand, is where the attacker
tricks a victim into communicating directly with him,
by pretending to be someone else.  For example, a
spoofer pretends to be a site of some repute, rather
than going to that site directly. 

Once so tricked, the victim can set up the secure
connection to the pretended site.  But, again, as a
signed certificate for the site includes the real
address and can bootstrap a secure session, the
browser can avoid being fooled. 



As described above, at least, that makes for two
forms of attack - as defended by the cert.  What
makes the situation murky is that the attacks are
not totally distinct; the MITM could use his attack
to redirect to the same site or to a spoofed site, and
the spoofer might often pass the traffic back to the
original site, thus converting his attack into the
MITM. 

The essence of the difference then would seem to
be in the initiation; the MITM is already in the
middle, whilst the spoofer needs to trick one end
or other into letting him be in the middle. 

Either way, these are the definitions used here,
but have a care with them!  Switching between
threats and amongst purposes, aims, interests and
whimsical and personal desires is endemic within
the SSL community, and can suffer the outsider a
permanent headache. 



I looked at the MITM in a previous rant [1].  The
assumption is that the cert does stop your common
or garden variety MITM, as defined above.  I went
on to ask whether implementations need to in fact
defend against it, an odd question, given that SSL is
fairly universally deployed with certs in place [2]. 

The accepted dogma is "of course!" 

A slightly less quick and much more accurate
answer is: "a definite maybe." 

The frequency of a true MITM - one defined above
where someone has the ability to control an
intermediate node at low level and take central
position - is so low as to be difficult to measure.
Using risk analysis, there is no economically viable
support for mandating protection, so the deployment
of a cert should be optional if there is any cost
involved. 

What about the spoof?  In total contrast to the
MITM, spoofs are common.  As common as dirt, and
as equally unclean. 

E-commerce sites with real value for thieving suffer
spoofing attacks (or perhaps, to be more pernickety,
their users are attacked) on a regular basis. 

(I have most experience with the world of internet
gold (IG) systems, a small, rabid band of gold bugs,
libertarians, and other intellectual misfits that, to
their credit, actually made net payments work.  I will
rely on their experiences as a benchmark.) 

Within what we call the gold community, every week
or so, a spoof attack is launched [3]. 

Here is how it is done.  An email is sent to a
(big, targeted) list of addresses, encouraging the
recipient to click on a link.  The link takes the user
to a site that is not the IG, but instead is a mere
pretence at the targetted IG.  The user types in her
account number and password into the pretend site. 

Our faithful and persistent attacker collects the
details, logs into the *real* site, and scarfs up
the gold.  As there is a ready and reliable exchange
market, the funds are washed more quickly than any
response can occur in higher layers in the protocol
[4]. 



Does the Cert stop the Spoof?  Nope.  Well, of course
not - not as described above.  Obviously the user is
at fault for entering - clicking - the wrong address,
and not checking... 

Well, hold on there!  Wasn't the cert supposed to
stop the spoofed URL? 

What we have here is a clash of expectations.  The
security model claims that the cert will protect from
the spoof, in that the URL typed will be the one that
is reached. 

But, the user's actions derive the URL from some
email or other source; a click launches the URL into
the browser, and no typing is done.  The browser
accepts the 'click' and, as the user has already
signalled acceptance, there is no need of further
checking! 

But - say the security types - the user shouldn't
click on a URL that is wrong.  Um, ok, but users do,
because that's what their trusty browser asks them
to do! 

But (3) they say - the precise spelling should be
checked!  And, sometimes, our dear user does even
check the URL.  And, it is perfect, within the text
of the email.  And ... And ... 



The ways to create a spoofed URL are many and
imaginative [5].  Scammers have an infinite amount
of time, and the ways of the URL are complex,
flexible, artistic even.  Browsers and Email clients
boast much facility at hiding critical security
information, under the guise of user-friendliness.
Presenting users with easy choices and other such
marketing-driven imperitives rules. 

Perhaps, worse of all, these scams don't seem to
worry about SSL at all.  Well, why should they?  That
would only mean that the attacker would have to
fork out good money to get some nonsense string of
numbers so that the victim's browser didn't interfere
with the attack by giving the game away. 



What a sad state of affairs.  The CA-signed
certificate, far from being the key to browsing
security, is the Maginot Line that preserves the
masses in a state of blissful ignorance. 

It works perfectly against the attacks conceived
and theorised as the dramatic threat to mankind,
commerce and the Internet, a decade ago.  Problem
is, the attackers bypassed it, with as much disdain
as any invading army against the last war's dug-in
defence. 

Problem is, the security model had unreasonable
expectations.  Problem is, the users didn't subscribe
to their part of the protocol.  (To be fair, it's hard
to communicate to users that they are even expected
to be part of anything.) 

Problem is, the browser manufacturers that were
sold on the need for the certs also got sold on the
convenience of click and launch.  So, they turned
around and sold the security model down the river
faster than one can say "check the URL..." 



In the wider picture of the web, the goal of the
security model is to protect value and information.
Within that wider picture, the systems in place -
browsing and ecommerce and implementations thereof
- lost sight of the security model, paying only lip
service to the security needs, while scrabbling to
please the customer with more click-and-buy
models. 

The parallels with the original Maginot Line are
embarrassing.  The real Maginot Line was erected
by the French during the years between WWI and
WWII.  This marvel of engineering was designed
to defend against a massive attack by Germany,
Evidently, an event that France fully expected,
and planned for! 

At an initial budget of 3.3 billion francs, it stretched
from Switzerland to the Ardennes (an impenetrable
forest) for some 240 kilometres (150 miles). 

It might have done its job, had the German army
been so polite as to stick to the French security
model. 

Instead, the Germans bypassed it.  The main
invasion went through the impassable forest, and
the Maginot line itself was mostly ignored.  The
garrisons surrended a few months later, as a sort
of afterthought. 



There are some who say that Maginot Line did its
job.  In fact, the line created a sense of false
security; it placed all of France under what was
later termed "Maginot mentality." 

Likewise, the CA-signed cert.  It has created the
appearance of security, at massive cost.  The real
attacks on users go right past it.  Probably, if
one were to ask an attacker about the certificate
protection, it's odds-on that he would think us mad
for even suggesting that he pay attention to it. 

Not only do the attackers ignore the convention of
presenting the certificate, they have the temerity
to hack sites on mass, stealing whole databases of
credit card numbers. 

Which is not the effect we expected!  Precisely the
reverse, if the 100%ers intent were to hold sway. 

( The notion of 100% cryptography is that if a
threat can be protected against, it should be.  This
is the underlying design principle that places the
CA-signed cert as the lynchpin of SSL security; the
final keystone that brings the arch of complete
browsing protection to a reality. ) 

Obscurely, if one has the gall to question the need
for the cert, one is informed that dropping it would
result in a "false sense of security," amongst
other crimes.  Yet, this is precisely the state of
SSL implementations today; those that have stuff
to protect are molested by attacks they do not
understand, over protocols they were sold as
secure. 



How to change the Maginot mentality of the SSL
systems; that is the question that faces us. 

It might prove hard to change the mentality, but
luckily it is not hard to fix the systems once that
change is achieved.  There are a few minor tweaks
that will redeem the protocol. 

It is not, as with the Maginot Line, that the SSL
implementations are a complete waste of energy;
more, that there is an imbalance in the security
model as deployed. 

The blindspot from the Ardennes and on across the
Belgian frontier was the scene of much hurried
attention from 1936, after the declaration to
independence by a weary and jaundiced Belgium. 

In the case of SSL, it is a likewise attention to the
blindspots that will improve the overall security.  It
goes like this. 

    1. Browsers now force the use of CA-signed
       certs on merchants, for some unmeasurable
       security benefit. 

       They should not! 

    2. Instead, Browsers should accept ADH and
       other techniques such as self-signed certs. 

       These should be deployed as intermediate-
       level security models. 

    3. The single binary lock of security, as
       presented by the browser, results in a
       compressed message to the user.  This
       forces a binary choice between what is
       accepted and what is unaccepted.  Hence,
       the false sense of security, as described
       above. 

       Browsers should cease this binary choice. 

    4. Browsers should present compelling
       imagery to show the user the nature of the
       security: 

          *   ADH is better than HTTP, 

          *   self-signed better than ADH, and 

          *   trusted third party (arguably)
              best of all. 

       The user may not understand the message,
       or merely choose not accept it, but, the
       message must be present as an initial step
       in encouraging the user to participate in
       the security protocol! 

    5. Browsers - not web sites - should show who
       signed the cert.  Not with a click, nor on the
       untrusted page, but, on some protected area
       of the browser. 

These steps are needed to fulfill the promise of
an increase in security; they would go a long way
towards preventing spoofs (which are now
practically unprevented). 

What would be the downside of this?  Certainly not
the decommissioning of the CA architecture, as
feared by some.  What would then be deployed would
be a graduated ramp of security, where each server
enjoys the best it can afford. 

No longer would the choice be: security, but only if
your merchant can spend the price of erecting his
own personal Maginot Line.  With the above series
of choices, security could be delivered according to
cost, the only way that we would know that it was
the right security [6]. 

iang 



[1] "Who's afraid of Mallory Wolf?" posted 23rd
March 2003 on cryptography list.
http://www.iang.org/ssl/mallory_wolf.html 

[2] "How effective is open source crypto?" posted
15 March 2003 on cryptography list.
http://www.iang.org/ssl/how_effective.html 

[3] Here's several all collected in the month of
writing this rant: 

    *  http://www.iang.org/ssl/spoof1.html -
       repeated several times over ensuing days, 

    *  http://www.iang.org/ssl/spoof2.html - not
       really a spoof, but a harvesting, and 

    *  http://www.iang.org/ssl/spoof3.html. 

[4] This has been going on for a long time in the
e-gold community, but now seems to have crossed
over to credit cards: 

       New way to steal password. A
       Discover credit card customer
       receives an e-mail telling him that
       his account is on hold due to
       inactivity, and that in order to
       reactivate his account, he must log
       in to this phony Web site. The
       information collected includes plenty
       of data that would enable identity
       theft: Social Security number,
       mother's maiden name, account
       number, and passwords. Similar
       scams have targeted PayPal and
       eBay customers.
       <http://www.msnbc.com/news/884810.asp>
       <http://www.computerworld.com/securitytopics/security/cybercrime/story/0,10801,79380,00.html>
       or <http://tinyurl.com/7mgh>

Cryptogram, 15th April, 2003. 

[5] It's probably worth stressing that these
attacks are extraordinary in their inventiveness!
Emails encouraging great things, warning of dire
consequences, alerting to supposed controls, all
sorts of things.  Wonderfully accurate sites,
convincing URLs.  It makes you want to employ
these people, as their resumes are impeccable,
and often, economically productive! 

[6] Analysis would go like this: If each spoof
managed to grab $100, and there are 2 per month
against that one site, he and his customers (same
thing) will incur losses of $2400 per year. 

So, spending money on a cert would be justified for
that site, assuming that the cert protected against
the spoofs.  To meet that assumption, however,
would involve fixing the browsers as described
above. 



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