Re: Defending users of unprotected login pages with TrustBar 0.4.9.93

On 9/23/05, Gervase Markham <gerv@xxxxxxxx> wrote:

...
>     How could you prevent compromise of the signature if the page was
>     compromised?
>
> This is actually easy. The server digitally signs the page and puts the
> signature in the page;

Wouldn't that break the signature?

No, the signature is not done over itself (this tag is excluded) - this is a standard solution, see e.g. in XML-DSIG, don't worry about this.

> TrustBar (or browser) can easily validate the
> signature, using the public key of the server (of course extracted
> securely from a certificate signed by a trusted CA). So this is as
> secure as SSL. But does require site cooperation, of course.

And if the site is going to cooperate, it would be much easier for them
to provide an SSL login!

Let's not invent inadequate solutions where good ones exist :-)

Well, I almost agree; however, I must say, that there are some legitimate issues that sites have with using SSL over their homepage, and they still want (for business considerations) to have login in their homepage - this is why they don't use SSL in the first place. So while I'll love them to use SSL, I'm trying to find a solution that will allow them to work w/o SSL in the homepage. Still, as I said, the fact sites must cooperate is the real problem with signing these non-SSL login pages.

> Suppose that whenever a user assigns name/logo to an unprotected page,
> we also save a copy of that page, and compare such copies for five
> accesses (or over a period of at least five days). If we find the page
> is static (except possibly for few bytes here and there),

How many? I can control a page if I can inject:

<script src="" href="http://x.yz/q"/">http://x.yz/q"/>

Yes, I know, this is tricky, we definitely will need to try to prevent such changes... This seems hard.

> The difference is in what we do if the page does change (in new
> locations). What I think of doing is simply to *display the archived
> version* - with a message / button allowing user to use the new version
> instead if needed. I think in most cases, even if there are changing
> fields in the page, using the old version will still work.

My first thought is that it'll break websites in a non-discoverable way.
If, for example, the name of the login parameter form field changes, the
old page will still be submitting the wrong value.

Yes, this is a valid concern, and maybe killer.

One alternative would be that when such a change is detected, TrustBar will try to load the page from another channel, e.. via some secure proxy. That will protect against most attacks, which exploit some local vulnerability (typically of DNS).

--

Amir Herzberg
Associate Professor, dept. of Computer Science
Bar Ilan University
http://AmirHerzberg.com