Defending users of unprotected login pages with TrustBar 0.4.9.93

David Wagner daw at cs.berkeley.edu
Mon Sep 19 18:32:24 EDT 2005


Amir Herzberg writes:
>However, quite a few of these sites invoke SSL/TLS only _after_ user has
>typed in her user name and pw, and clicked `submit`. This allows a MITM
>adversary to send a modified login page to the user, which sends the pw
>to the attacker (rather than encrypting it and sending to the site). See
>below link to a `Hall of Shame (HoS)` listing such sites.
>
>There are few things we can do about this. We can try to convince these
>sites to use SSL/TLS _before_ asking for userid and pw; I tried, and few
>fixed, but most did not.

But this isn't enough.  The only way for a user to be secure against such
attacks is to type in a https:-style URL into the address bar directly, or
to load a https:-style URL from a bookmark.  Users have to always remember
to type in https://www.bank.com; they must never use http://www.bank.com,
or they will be insecure.  Training users to follow this discipline is not
a trivial task.

I'm not sure it is fair to blame this solely on the web sites.
The problem is that the https: model for web security is broken, if
attackers are mounting active attacks, DNS spoofing, and other kinds of
man-in-the-middle attacks.  The problem is not with SSL; the problem is
with the model for how SSL is applied to solve the web security problem,
and with the user interaction model.  Fixing this probably requires
changes to web browsers and/or web servers.  So, a Hall of Shame seems
a little over the top to me, since there is no obvious way that the
web site could fix this on its own.

TrustBar's solution to this conundrum is a nice one.  I like it.
But it does require changing the web browser.

One thing that web sites could do to help is to always make
https://www.foo.com work just as well as http://www.foo.com, and
then browser plug-ins could simply translate http://www.foo.com ->
https://www.foo.com for all sensitive sites.  Of course, web site
operators may be reluctant to take this step on performance grounds.

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



More information about the cryptography mailing list