> I don't see at all how this would fix the problem. If it was
> accessible last time so it could be cached it will be accessible this
> time, too (unless remote config changed).
But it may be a different user/client, even though it's from the same
cache server... For example, the UK has a cache at Kent University,
> which serves anyone in the UK...
> HEAD is so terribly
> inefficient anyway it should be completely buried.
Agreed :)
> No, the problem is that with the proxy the server sees the proxy IP
> and not the client IP. The solution would be to have the proxy tell
> the remote server the client IP address.
this wouldn't work if going through multiple proxies/caches. E.g. proxy
through a firewall onto a cache somewhere else and finally to the real
server, or using hierachial caching servers. (these examples are
innocent paths; you could also maliciously use this to attempt to get
around host based authentication, bouncing around different proxies. Or
do it just for the sake of it, like people used to do with the phone
> system in the UK... :)
> Then again, without a secure
> protocol the proxy can give whichever address it likes, so this is
> very very vulnerable. You really need a secure protocol before this
> works at all.
Well yes, but if you really care, you can always do "real"
authentication on the document, if it's that much of a problem. I'm
just looking at the case where you want the document given out only to a
certain set of sites, without requiring secrecy/confidentiality on the
docs. I am prepared to believe what people tell me: if they are faking
addresses or anything similar to that, then they are the ones who are
liable in legal terms, as they are comitting electronic forgery.
> > (a) the client should always fills in the from field (if nothing else,
> > with "nobody"@current-domain-name).
> The great public fiercely disagrees having their email address
> automatically sent -- it's a privacy issue, and I so wouldn't enforce
> the From field.
Then they would have "nobody"@current-domain sent to the server, which
reveals nothing (the server could have told that from the peer address)
and things still work fine. The critical point here is that "From"
field is either (a) set and can be believed if you want to, or (b) it
isn't set and the address "nobody"@client-address refers to the
originating requestor (and not to an intermediate cache or proxy).
> >From field is much easier forge than peer address, even a newbie could
> do it.
I realise this, but then that user is either lying, in which case they
are committing fraud or something like that, and the server becomes an
unwitting victim or, they're telling the truth and the 'From' field
really does refer to the user, no matter what machine/domain/country
they happen to be at the time, allowing them consistent access to those
loosely protected documents.
I feel I need to emphasise here that I'm not interested in absolute
guaranteed authentication on the originating user: there are very nice
systems for doing that, thankyou. All I'm interested in is something
which will be correct in all cases unless the user is *deliberately*
lying to me (i.e., it will never be wrong because of the fact that it's
a cache, or a proxy, or some other weird system invented in the future).
Nick Williams, Systems Architecture Research Centre, City University,
London, EC1V 0HB. UK.
Web: http://web.cs.city.ac.uk/finger?njw
E-mail: [email protected] (MIME and ATK)
Work Telephone: +44 71 477 8551
Work Fax: +44 71 477 8587