secure WWW on UNsecure servers

I know several people who want to share private information on
some web pages but do not trust any publicly-accessible web server
not to leak the information on those pages.   The normal IP
address or password-based web page protection mechanisms thus
are not sufficient since they assume that the server is secure
from non-web-based mechanisms for retrieving the pages.  Also,
encryption schemes such as SSL will not solve the problem because
they protect only against interception between the server and
the client, not at the server itself.  Instead, it looks like
the web pages must reside on the server in encrypted form.

How might one arrange for these encrypted web pages residing on an
(unsecure) server to get decrypted only at the client's machine?
This should work as transparently as possible for the user;
except possibly for a userid/password query it should look like a
normal web browsing session.  For now, we can assume that the
decrypted web pages contain only HTML and images in .gif format.

Might this best be done with some combination of special MIME
types and helper applications or plug-ins?  Has someone already
done it?  Thanks.

    Kevin Q. Brown
    kqb@c2.org

> How might one arrange for these encrypted web pages residing on an
> (unsecure) server to get decrypted only at the client's machine?
> This should work as transparently as possible for the user;
> except possibly for a userid/password query it should look like a
> normal web browsing session.  For now, we can assume that the
> decrypted web pages contain only HTML and images in .gif format.

It seems like it could be done by writing a plug-in that passed the
encrypted page to pgp (or had it internally) and used that to decrypt it.
The plug-in could store  the pass-phrase locally and clear when the user
disconnected.

It *might* also be possible to do this with java. I don't know enough java
to say for sure, but couldn't you build an interface that took the
encrypted data passed it though whatever and then displayed it on the local
screen. The applet could produce a viewer with a 'sigoff' button telling
the applet to forget the pass-phrase. Comments?


Joseph Sokol-Margolis
joseph@genome.wi.mit.edu
Systems Administrator

Joseph Sokol-Margolis writes:
> > How might one arrange for these encrypted web pages residing on an
> > (unsecure) server to get decrypted only at the client's machine?
> > This should work as transparently as possible for the user;
> > except possibly for a userid/password query it should look like a
> > normal web browsing session.  For now, we can assume that the
> > decrypted web pages contain only HTML and images in .gif format.
> 
> It seems like it could be done by writing a plug-in that passed the
> encrypted page to pgp (or had it internally) and used that to decrypt it.
> The plug-in could store  the pass-phrase locally and clear when the user
> disconnected.

The "Right Way" to do what was asked is to use S/HTTP. However,
Netscape, in their wisdom, has not implemented it.

Perry

Perry E. Metzger enscribed thusly:
> Joseph Sokol-Margolis writes:
> > > How might one arrange for these encrypted web pages residing on an
> > > (unsecure) server to get decrypted only at the client's machine?
> > > This should work as transparently as possible for the user;
> > > except possibly for a userid/password query it should look like a
> > > normal web browsing session.  For now, we can assume that the
> > > decrypted web pages contain only HTML and images in .gif format.

> > It seems like it could be done by writing a plug-in that passed the
> > encrypted page to pgp (or had it internally) and used that to decrypt it.
> > The plug-in could store  the pass-phrase locally and clear when the user
> > disconnected.

> The "Right Way" to do what was asked is to use S/HTTP. However,
> Netscape, in their wisdom, has not implemented it.

	Uh...  Wait a minute...  The only ones to blame for the dearth
of S/HTTP systems are Tereasa systems and EIT.  While the rest of us have
been working on and developing for SSL those guys have stonewalled and
sat on it.  I know.  You ever try browsing for S/HTTP information.  Most of
the links on their site with any useful information refuse access to anyone
other that EIT members.  We've had a freely available SSL reference
implentation available for ages.  AFAIK they STILL don't have a working
reference implementation.  When they do, you can bet it will be EIT only.
They're so hell bent on keeping total control over it that they now
strangled it to death.  We now have freeware SSLeay and nobody is even
interested in screwing S/HTTP.  Forget that it's a better idea.  The idea
was stillborn because the parents strangled it a birth.

> Perry

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (The Mad Wizard)      |  (770) 925-8248   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

On Fri, 28 Jun 1996, Joseph Sokol-Margolis wrote:

> > How might one arrange for these encrypted web pages residing on an
> > (unsecure) server to get decrypted only at the client's machine?


Given the cost of high bandwidth connections and the practical necessity
of surrendering control of the actual machine on which the server resides
to have a decent connection at all, it seems to me that this possibility
should be very seriously considered.

It will allow virtual anonyminity of browsing and (with cooperative ISPs)
allow anonymous maintaince of a page itself.

The other alternative (maintaining control of the server and machine
itself) requires substantially more work to foil traffic analysis and
jurisdictional savvy employment to achieve the same effect.

As usual, the mathamatic defense vastly exceeds the utility of the
physical defense.

To what extent will it be possible, e.g., to run a financial services web
page from a server and still keep the server staff from knowing what the
page is?

It provides the ISP providing the server with liability protection, and
presents many more anonymous possibilities.

This, clearly, must be the best answer to turning web pages and WWW
transactions into the kind of personal and private exchanges that PGP
affords e-mail today.