Hi,

Background (for sake of context) -

I am trying to create a VNC solution which uses tightvnc. The idea is
basically that the TightVNC server does a reverse connect to a VNC Reflector
(so that the server doesn't have to listen on any port). Then a viewer can
do a connect to the VNC Reflector and then basically see the desktop where
TightVNC server is running. VNC Reflector acts as a *client* to the TightVNC
server and as a *server* to a VNC Client. Basically, this lets us have a
solution where the reflector can be on a remote server and the users don't
have to listen to any port.

I got this working against a squid proxy (TCP tunnel).

Issue - Proxies :

Libcurl is used in a modified TightVnc Server code, where curl does the
initial handshakes - reverse connection - , tunneling
(CURLOPT_HTTPPROXYTUNNEL) and gives back the raw socket for the TightVNC
server to use.
The issue is this, there seems to be quite a few good proxy servers /
firewalls out there, which can figure out if the tunnel is actually carrying
TLS/SSL traffic, without doing any Deep Packet Inspection. Basically they
can figure out if we are cheating.

Possible Solution:

A possible solution I am thinking of is to try and use an SSL tunnel. If it
is possible to have a HTTPS server which can act as a gateway - i.e. the
libcurl client does the SSL handshakes, authentication and then there is a
tunnel ready to transport tcp data as usual, which the server then directly
passes on to the actual VNC Reflector, the traffic itself would appear to be
SSL so the proxies wouldn't have anything to complain, unless they do deep
inspection.

Has any one tried this ? I have seen some solutions with stunnel and ssh.
But when it comes to VNC, I am at a loss. I seem to be able to do SSL
certificate exchange, but after that the channel breaks.
I do not understand SSL / TLS (infact, HTTP itself.. I feel lucky that I
found out about the HTTPPROXYTUNNEL option itself) all too well, so it would
be great to see if anyone knows that this is atleast possible.

Bharat Varma
Received on 2008-11-26