Re: Transparent Proxy and HEAT.NET

Henrik Nordstrom wrote:
> > Yes, basically you have to have a direct connection to them, the
> > webservers will reject with then mentioned error when the IP for
> > the SSL socket does not match the IP for the HTTP socket. This of
> > course could have changed since I have been there but it sounds
> > like the exact same thing..
>
> Alias yet another site who have misunderstood the concept of IP
> addresses and HTTP security. See numberous posts and articles why IP
> based security in WWW applications is close to void today.

Hi there. I have went back and read through the past squid-user discussions
that I could find related to this. I do understand that using just IP for
security is fairly pointless because it is so easily faked. However, Heat.net
uses this a little differently and I am not certain the same issues apply. Of
course, I'm sure someone can correct me -- so please do. :) Ok, basically,
the problem with heat.net through Squid is that it wants to know what IP the
requests came from because it uses that IP to talk back to the originator via
a Java applet. Now I agree that just using the IP for security would be dumb,
but what about for something like this -- when they are actually talking back
to the IP. It seems that it would make "faking" your IP pointless since then
they would not be able to talk to you. As a quick analogy, I see this similar
to giving out your phone number -- if you call someone and all they ask is
your phone number to verify who you are, then that is poor security -- but if
they then take that number and CALL YOU BACK, then that seems significantly
more secure (granted, it certainly may not be the best answer -- that is not
what I'm saying at all) -- but isn't it at least reasonable security (relative
to just check the IP itself and not really talking back to it).

So, it is the Java applet itself that does the security checking -- and it
wants to talk back to the originator -- is that unreasonable? I guess I just
hear so many people right off the bat saying: "Oh, they use your IP for
security checking -- they must be morons and are completely insecure" --
while, in fact, it seems that if you actually talk to that IP (to a Java
applet), then you are actually doing some reasonable security verification.

Again -- feel free to correct me if I have missed some obvious way to
circumvent this or any other reason why it isn't even reasonable and is "close
to void" today. (Note again that I'm not trying to sound angry here -- I
completely acknowledge that I may be missing something and therefore simply
want it explained to me -- and, again, I do agree that the simple "IP
checking" security methods that were mainly being discussed earlier by the
group are pretty much worthless -- but mainly because they don't really DO
anything with the IP besides trust that it is yours and compare it to where
they think you should be.)

> This will not only fail in environments using transparent proxying
> for port 80, but it will also fail if a cache hierarchy is used or
> even if a cache array is used.

Agreed -- but doesn't that just mean that there are certainly circumstances
where, for security reasons, using a cache or proxy might just not be
reasonable? Or does it mean that the server site should be using a different
form of security? It seems that if you want to do direct communication with a
client for verification purposes, then a proxy or cache is going to be a
problem...

 - John (Goggan)...
Received on Thu Dec 17 1998 - 16:47:28 MST