Dan Stromberg suggested that Sun could have avoided the problem (Java applets
being able to connect to arbitrary hosts) by passing back the IP address
instead of the host name. It isn't clear to me that this solves anything.
Given the obvious accuracy of Dan's comments about how the client could be
talking to a proxy (i.e. it can't trust the getpeername return value),
how can the client trust an IP address passed inside the data stream?
Another way of putting it is: how can a client know which IP address an
applet came from?
There would seem to be a few alternatives:
1) trust the getpeername result - doesn't work because the peer might
be a proxy instead of the real server.
2) trust something in the data stream - doesn't work without a considerably
more elaborate authentication mechanism (anybody want to suggest that
applets that want to connect back to the server MUST be served to you
by a server that has a verifiable certificate (eg. an SSL certificate)?).
3) the client must realize that the applet was obtained from a proxy host.
If the applet tries to connect back to the server then the client must
ask the proxy host to establish the connection. This requires that
one of the following be true:
a) the client remembers where it originally got the applet from.
b) the proxy host tells the client where the applet came from.
c) the proxy host 'remembers' where the applet came from.
4) the client remembers the IP address of the server that it originally
downloaded the applet from (i.e. the IP address that it connected to
to get the applet or the URL that it passed to the proxy when it asked
the proxy to download the applet).
Unless I'm missing something, option 4 (which is equivalent to option 3a) seems
cleanest. Options 3c and the certificate idea in option 2 are also workable
although not exactly clean.
-Danny
Follow-Ups:
|
|
