"Joseph A. Knapka" wrote:
>
> Harmen van der Wal wrote:
> >
<...>
> > > The Java applet -- aah. Probably doesn't know it has to go through port
> > > 80 to get to the VNC server. It is probably trying to use 5900 or
> > > similar.
> > >
> > > I will investigate this. It will probably mean adding an option to the
> > > Java viewer to select which port to connect on.
> > >
> > > -- Joe
> > >
> >
> > Keep in mind that the Java applet loaded through a HTTP proxy, doesn't
> > use that proxy with the rfb protocol. So having both http & rfb on port
> > 80 alone doesn't help those who can't use direct TCP/IP connections (or
> > some kind of transparent proxy), but must use their LAN's HTTP proxy.
> > (Anyone can test this by telnetting to the rfb host+port)
>
> I had not thought about that. This seems to make my patch useless,
> since the only situation in which it would really be necessary
> is the one where there is an HTTP proxy involved. Oh well.
Not entirely. With bare client side packet filtering on all outgoing
ports but 80, your patch would work, and be much faster than my route
through a HTTP proxy outside the firewall.
<...>
> > For those who must go through their LAN's HTTP proxy there's a bunch of
> > http-tunnel-tools out there, but it would be ideal in my mind to have a
> > Java applet do it, becuase you can use it wherever you might happen to
> > be. Off course this would also require adjustment on the server-side.
>
> I am not sure I understand this point. You seem to be saying,
>
> (1) It is possible, with no client or server changes, to tunnel
> both HTTP and RFB connections through a third-party HTTP tunnel
> host, and achieve a connection;
Well, the client connects to the client-side tunnel software instead of
to the actual vnc-server; the actual vnc-server gets a connection from
the server-side tunnel software. Both vnc client and server need not
know whats actually going on.
>
> (2) the applet and server should just wrap the RFB protocol inside
> HTTP, and thus eliminate the http-tunnel host.
I would like to have at least incorporated the client-side http-tunnel
software in the Java viewer. The whole purpose of the Java viewer is
that you will always have a viewer available wherever you are. You
shouldn't have to bring your own tunnel software along in order to be
able to use it.
Unfortunately, Java security restrictions make things even more
complicated. That's why my Java viewer will not work through any LAN
HTTP-proxy as an applet. It will work only through a LAN HTTP proxy in
the following cases:
1)Your HTTP proxy is Delegate.
2)You can host the applet on the proxy host.
3)You have an appletviewer, which allows for easy security settings
4)You can run the Java viewer as an app.
But if I'm not mistaken, an applet talking HTTP (besides HTTP CONNECT
off course) will automatically use the browsers proxy configuration,
without raising security objections as far as the HTTP-proxy-host is
concerned. This would allow for an applet encapsulating rfb in HTTP,
transparently using any LAN HTTP proxy.
Now that would render both your and my patch useless;-) Well at least in
most cases:-((
<...>
--
Harmen
Firewall VNC Client: http://www.workspot.net/~harmen/vnc/readme.html
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
