Re: cache-busting document

Shel Kaphan said:

>  >   Don't use secure servers to serve images and other non-sensitive
>  >     objects, since these will be uncacheable and may not be passed
>  >     through a cache hierarchy.
>  > 
> 
> Not a good recommendation:  some browsers will put up a dialog box
> whenever there's a reference from a secure page to a non-secure page,
> including embedded references such as image URLs.  This leads to a
> fairly infuriating experience as a user, as multiple dialog boxes are
> put up to display one page of results.

Correctly, in security terms. (though see below). After all, if one
can insert an insecure image into an otherwise secured document, one
has merely to substitute a dump of a HTML display instead of the image
and the "secure" document is effectively subverted - most people won't
notice they're looking at an image and not "real HTML", and the little
key still turns blue.

And Andrew Daviel said:
> In common I suspect with many of you when I access my banking services on
> the Web I want to get on and do the job at least as fast as on a
> touch-tone phone, not wait for a lot of background images, adverts, icons
> etc. to download over my phoneline. It seemed daft to serve these
> images from the uncacheable https channel. As it is, I turned on
> cache for https in Netscape. If someone gets root access to read my 
> cache files, they can snarf my passwords and credit card numbers
> right out of /dev/kmem. ... of course, they could just check the trash ...

True. I would advise everyone to use https only for genuinely
sensitive stuff such as PUTs which need to be authenticated or GETs
for a small, closed group of readers where there's no caching benefit
anyway, and to use the minimum of (preferably no) inlined images etc.
As there's no reason not to insert an authenticated image into an
unauthenticated document, it's arguable that if a logo *is* going to
be pulled via https at some point, then there's no point in pulling a
non-https version as well.

Has there been any thought on ways in which URI contents can be cached
with signatures so that pages which aren't secret - and hence *are*
cacheable - can be still trusted? Once I've obtained a site's public
key and told the browser to accept it (either explicitly or via a
certificate chain), then everything from the site can be cached as
normal, though browsers will need to be tagged such documents a
different colour to information which is "trusted but not secret". If
I wish to send credit card details, I'm not bothered that the *form*
isn't secret (and the bank's logo etc), but I do want to be sure that
I can trust it to send details to the right place once I press the
SUBMIT button. It's the *reply* - with my details in - that should be
secret.

Peter Lister                             Email: p.lister@cranfield.ac.uk
Computer Centre, Cranfield University    Voice: +44 1234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL UK        Fax: +44 1234 751814
   The more we look at structures of trust, the more we realise that
   democracy and subversion are closely related.     (Ross Anderson)

Received on Tuesday, 10 June 1997 03:42:03 UTC