Re: VNC client/server combo doing VNC over HTTP
On 3/11/06, Mark Fletcher <email@example.com> wrote:
> 2 short infos to clarify :
> 1. VNC over http doesn´t exist
Is that strictly true? Both Ultra@VNC and RealVNC Personal Edition offer
a version that allows access through a web browser on the client side,
specifically to be more firewall-friendly; what are they doing if they
are not putting VNC over HTTP(S)?
They only provide the ssh-client as an java-applet via browser : the connection itself still goes the "normal" way
> 2. Port-Numbers can be altered with any version
I do know that much, but that's only half the problem; the protocols
allowed by the corporate firewall are the other half...
Thats why i suggested to tunnel it through Port 443 (SSL)
> Solution would be : ssh on Port 443 ... with that you can trick most
> proxies with the "connect" method to use any proxy-capable ssh-client
> (putty for example)
> -> after ssh-connection is ok .. you can do vnc-over-ssh (simple
> more professional :
> use SSL-VPN-software like ssl-explorer(
), which can do
> port-forwarding in y very simple manner
Thanks for the suggestion, I'll try it right away, but I don't expect it
to work as I expect I'll find the firewall is not configured to allow
SSH going out of the network to the internet any more than it would
allow incoming SSH (we are talking about a multinational corporation
Both the first and second sultion trick the proxy to believe its a regular ssl-connection.
In the Second-Cast it is. So if your corprate-firewall doesn´t break up ssl-connections (very unlikely !! - and not that simple) the ssl-explorer thing will work.
I use this way here in my company (4 Proxie in arow - squids, netaches and viruswalls ..) And they all can´t stop ssl-explorer from opening that ssl-tunnel-
SSL-VPNs in general are built to address your problems (Tunnel over Proxies)
Unless I am being inordinately stupid, in which case please have
patience with me and correct me, hard-core firewalls are filtering based
not only on port number but also on protocol. I am not sufficiently
senior in my organisation, nor is what I'm trying to do sufficiently
strategically important, to give me the power to influence my company's
internet facing firewall policy; so the only option left is to find a
way to tunnel this traffic over an existing open port/protocol combo.
The most reliably available is HTTP(S) over the usual HTTP(S) ports eg
80, 81, 443, etc...
You are right, but also "hardcore" firewalls or Layer-7 (Apllication-Layer) Firewalls only can analyse the data within a tcp-connection if it is not encryptes. An SSL-Connection works this way :
The Broser sends a "connect" request to a destionation ip (and port 443) ... after that the proxy opens that connection for the client and everything after that (in a regulat https session this would be the http-dialog and data ("
e.g. the get index.html) ) is encrypted an unvisible for the proxy .. so it can´t tell if this is http in the data-stream or something else.