ChunkVNC_https - proof of concept

[--Pennywise--]

Hi to all.

A few weeks ago I contacted supercoe regarding my idea of using https for firewall/proxy traversal in ChunkVNC. supercoe was interested in that and now I have something to show to the public.
My proof of concept is based on stunnel. http://stunnel.mirt.net/
Stunnel is used to encapsulate the vnc session into a encrypted https connection to the repeater.

The setup is as follows:
[InstantSupport]
VNC server connects at 127.0.0.1:5901
stunnel listens for connections to 127.0.0.1:5901 and connects to the repeater at port 443 via https
[repeater]
stunnel on the repeater decrypts and forwards to 127.0.0.1:5901
[viewer]
viewer connects the repeater at port 5500


How to use:
On the repeater you have to run the repeater and stunnel.
For the client and viewer use the https option in the compiler to get working executables.

What is missing:
- proxy detection for stunnel on InstantSupport side (registry?!?)
- generation of certificates for https via compiler
- ...

Where to download:
http://www.walkernerds.com/chunkvnc/ext ... _https.zip - thanks to supercoe

Whats next:
Feel free to discuss my idea. I can not say how much time I can spend for this to get out a stable version in near future. So help is very welcome.

Regards
--Pennywise--

[B]

Cool work and thank you so much for sharing. I haven't tried it yet, but I have the obvious question -- why isn't the leg from the Viewer to the repeater encrypted?

Are you assuming the Viewer and Repeater will be run on the same machine, making it unnecessary?

Edit: Oh, you're <b>proxying</b> the SSL connection, so while the above diagram shows the technical links, a conceptual version would indicate that a secure tunnel is established between server and client?

[supercoe]

Thanks Pennywise, can't wait to take a look at this!

[--Pennywise--]

My idea is not to add more security to ChunkVNC, because ChunkVNC already encrypts the connection, as far as I know.
Https/ssl is a nice way to get the connection passing a stateful or deep inspection firewall that does not permit/allow the vnc protocol.

[B]

Ohh. Interesting. Yes, Chunk uses the RC4 plugin, but its reliance on predefined shared keys always worries me.

So your project is intended to bypass firewalls that would otherwise block <b>outgoing</b> VNC connections.

Technically that's interesting. And not to be a complete dick about... but if an organization has gone out of its way to specifically block outbound VNC connections, isn't it a bit questionable (and dangerous from a staying-employed point of view) to be bypassing that?

I can't really conceive of a situation where that would be "okay" -- would the VNC server operator tell his or her IT department "but I really need to let XYZ control my PC, and the firewall wouldn't let me, so I bypassed company policy"?

Then again, I suppose this is exactly what LogMeIn and GoToMyPC have always done (which is one reason many IT departments hate them).

It's still good to have more tools! Maybe this could be a good basis for establishing the repeater as a CA so it could hand out session-based public keys rather than rely on RC4.

[--Pennywise--]

Ohh. Interesting. Yes, Chunk uses the RC4 plugin, but its reliance on predefined shared keys always worries me.

So your project is intended to bypass firewalls that would otherwise block <b>outgoing</b> VNC connections.

Technically that's interesting. And not to be a complete dick about... but if an organization has gone out of its way to specifically block outbound VNC connections, isn't it a bit questionable (and dangerous from a staying-employed point of view) to be bypassing that?

I can't really conceive of a situation where that would be "okay" -- would the VNC server operator tell his or her IT department "but I really need to let XYZ control my PC, and the firewall wouldn't let me, so I bypassed company policy"?

You are right. Maybe I have a different view on that and it's good to talk about this. Normally my contact or customer is the administrator of that specific company.
Sure, this couldn't be a "carte blanche". Everyone should know what the consequence is.

[supercoe]

Blocked connections don't always rely on company policy.

For instance I have a school district and everyone, even the superintendent has to access the internet through a proxy. I've been looking at this in a "yay SCIII type proxy support" kind of way more than a "can bypass company policy" way.

It's up to the end user to use the software in a legal way.

[B]

It's so nice to have a civil discussion on this sort of thing!

The school scenario is interesting and I've seen that before. They're big on proxies because of various (legal and/or perceived) requirements for content filtering.

But... do you mean to say that ChunkVNC_https can work with an existing outbound http / https proxy server? How?

Or is it that (a) you'd set up an internal UltraVNC Repeater in "SCIII" proxying mode, (b) connect to it from your internal VNC Server, (c) the Repeater makes outbound.... hmm, I give up. Where exactly is the school/company proxy in this example? Is the Repeater <b>outside</b> the school/company network? If so, how is using STunnel significantly different from simply leaving the repeater listening on port 80 or 443 instead? (Since the presumption is the school proxy only allows those ports.) I guess I'm still missing what stunnel is buying us here. Just the fact that the school proxy might also be checking for RFB packets?

[supercoe]

B,

I could be completely wrong about how stunnel works but I was hoping I could get ChunkVNC to work like this solution:

http://www.vncproxy.com/

It uses Java to tunnel RFB over HTTPS which allows it to work directly though a proxy server.

The repeater should always be outside of the customers network otherwise it kind of defeats the purpose of not having to forward ports on the customer side.

I've made a request in the past for the UltraVNC devs to add SCIII support to the main executable but they are busy with other projects I'm sure. This is the only way that the current repeaters port 443 mode will work AFAIK.

STunnel will aid in wrapping the InstantSupport data so it can be sent over HTTPS (443) so in my school situation I can send vnc data through their proxy/content filter. This is much more similar to the way Teamviewer works.

EDIT: clarity

[B]

Whoa, that thing looks right on. And they've got source code (or at least appear to) at http://sourceforge.net/projects/vnc-proxy/

I didn't know about that one. (Any reason not to use it? Or to try building one's own version from source?) Almost sounds too good to be true, as long as you have a web server to install it on (and aren't interesting in using theirs). I took a quick look and all the modules appear to be GPL3. People are always looking for exactly this kind of thing!

As to the current repeater (the one you use), I thought it COULD be used through ordinary proxies as long as you had it listening on port 80 or 443, but maybe I was assuming too much.

Certainly if the proxy/content filter is doing packet inspection and blocking known RFB packets, you'd need the tunneling solution. But I just thought you wouldn't need that in order to get through an "ordinary" proxy.

[supercoe]

B,

Yea it's a really cool project, all of the sources are included right in the binary. I've looked into it before as an option to base ChunkVNC on but there were a few things that put me off, I just can't think of what they were right now.

[JDaus]

GGood to see someone else thought of this ... i had one of those AHA moments a few weeks back, when i thought of using stunnel to make the connection, but never had time to do anything about it.

how is using STunnel significantly different from simply leaving the repeater listening on port 80 or 443 instead? (Since the presumption is the school proxy only allows those ports.) I guess I'm still missing what stunnel is buying us here. Just the fact that the school proxy might also be checking for RFB packets?

Stunnel will connect through the proxy (not just transparent proxies) ... allowing connection with the outside world ... SC (or any reverse VNC) relies on a direct connection to the viewer / repeater, and will not pass through proxied connections (silent proxies maybe, but not a "Proxified" connection where you need to give username & password)

stunnel would be a great addition to the ChunkVNC arsenal ... in my opinion ...

if only i still used VNC ... (my current employment means hands on, as 99.99% of systems are offline).

[B]

stunnel would be a great addition to the ChunkVNC arsenal ... in my opinion ...

if only i still used VNC ... (my current employment means hands on, as 99.99% of systems are offline).

Kind of ironic; the author of two serious remote control products is spending all his time on non-networked machines!

Thanks for the reply. You're right of course; I'd forgotten that most proxies require authentication.

I gather that perhaps your development on SCPrompt (which I still love) has slowed a bit. I had always hoped/planned to use it in conjunction with a static repeater to accomplish something similar to what ChunkVNC is doing. (In fact I probably will still do just that, since it already supports repeaters fine.)

I remember that SCPrompt's written in AutoIT but I don't see the source code for your executables on your web site any longer? Am I missing something, or maybe it was moved? I'm not much of a programmer, but I gather one would need the code for scprompt_{version/timestamp}.exe, VNC2Me_SC_7zip.exe, settings_manager.exe, Build_SCPrompt_7zip.exe, and/or scprompt.exe

Thanks in any case...

[bigdessert]

This would be extremely useful if both the viewer and the server could go through the https 443 connection. I find that sometimes I am at a hotel with my lappy and need to connect to someone and cannot because the hotel blocks all non standard ports.

[B]

I might have replied but I can't get past your calling your notebook computer your "lappy".

[bigdessert]

I might have replied but I can't get past your calling your notebook computer your "lappy".

Could have called her by her real name "veronica" but figured I would get even more flak for that.

[supercoe]

...and I thought I was a nerd...

[redge]

--Pennywise--

your picture mistake
instantsupport reverse connect on port 5500 and vncviewer direct connect on port 5901

[JDaus]

Kind of ironic; the author of two serious remote control products is spending all his time on non-networked machines!

actually, I started scprompt after I had finished using remote support.

nowadays the only remote support I do is for friends and family...

I gather that perhaps your development on SCPrompt (which I still love) has slowed a bit. I had always hoped/planned to use it in conjunction with a static repeater to accomplish something similar to what ChunkVNC is doing. (In fact I probably will still do just that, since it already supports repeaters fine.)

I have planned to get another GUI working with scprompt, and I may have some time to do it shortly...

I remember that SCPrompt's written in AutoIT but I don't see the source code for your executables on your web site any longer?

you already have the source code ... its included in the application as a resource. download reshacker and take a look ...

This would be extremely useful if both the viewer and the server could go through the https 443 connection.

only one side can use the stunnel connection at once (from memory) as it establishes a tunnel from 443>XXXX

if you had two servers, or two (public) ips on one server, then you could use it as you want... otherwise you will be out of luck, I think.

[B]

Sorry for going off topic.

Edit: Using XN Resource Editor (open source alternate to ResHacker), I found the source code in scprompt.exe/RC Data/999/English (United Kingdom). Thanks!

[supercoe]

B,

Why not just ask the question in the SCPrompt thread??

I'll split it if further discussion is held here about SCPrompt.

[B]

Sorry, supercoe. Never mind; I restarted the editor and found it.

[B]

Hey supercoe, back on topic, you may have already been down this route, but by some inference and Google caching, I think the proxy abilities of VNCProxy.com were influenced at least in part by an older VNC-over-http tunneling mod at http://www.online-marketwatch.com/HttpTunnel4vnc/

It looks very interesting! They seem to be tunneling RFB at the client and server ends, rather than via middleware.

Rather than require a 4th piece (the https tunnel in addition to the client/server/repeater) I think this would enable you to tunnel through most existing http proxies, as is?

It's BSD licensed but they "ask" you contact them for commercial use (which is a bit self-contradictory).

Edit: Just realized, if it's not encrypting, the "deep packet inspection" protocol listening proxies are still an issue, which is why I suppose vncproxy.com further encapsulates in AES....

[supercoe]

B,

I've seen this solution before, it's one of the reasons I'm interested in this type of design.

I don't know what you mean about "rather than via middleware" this solution still requires a forwarder AFAIK...

Either way, their implementation wouldn't be easily built into ChunkVNC but their idea remains a good one.

[B]

I don't know -- my impression was that while they are calling it a "forwarder" it was actually a self-contained VNC server with http protocol tunneling. In the write-up on that page they do <b>not</b> seem to mention having to direct their software to a <b>separate</b> VNC Server instance. (I've never tried implementing this thing.)

But I realize that since Chunk's "only" a wrapper, it would take an UltraVNC developer to do that here.

And since you'd already seen it, my point is moot.

[JDaus]

XN Resource Editor (open source alternate to ResHacker)

awesome,I will take a look at xn ... I like open source ... don't know why :p

[twagner]

hallo pennywise, hallo supercoe,

thanks for the ssl-solution of chunkvnc between the instantsupport.exe and the repeater. But i want to add a solution to use stunnel between repeater and viewer too.
Look at the picture
Now, it is good enough if the repeater an the viewer will be in the same LAN or building. :



But if the repeater, instantsupport.exe and viewer.exe will be on different places or LAN segments. I will miss a ssl-tunnel between the repeater and the viewer. OK the connection in the hole is safed by the RC4 encryption of the DSM UltraVNC Plugin, but there is a security risk all the time, i think:



How can i configure the viewer or can you implement the stunnel modul in the chunkvnc.exe on the viewerside too?? That will be great.

And pennywise, i`ve found

[ChunkVNC]
accept = 127.0.0.1:5901
connect=192.2.2.1:443

in the stunnel.conf-file, sorry but can you tell me the reason for the ip 192.2.2.1:443??? It works, it works great, but i don`t know why Please, don`t let me silly die.

Hi redge you see you are right with the port`s

twagner

[B]

The only part that's unencrypted is the set-up with the repeater; once the connection is established the actual traffic is still encrypted by RC4, end to end. The repeater is just a mindless middleman.

So the question, I guess, is whether someone listening on that 3rd leg (PC2 to repeater) would see enough to gather (a) the login, (b) the password, or (c) the RC4 keys.

I'm not sure, but I think the only questionable thing is (c).

Of course, I'm not crazy about fixed shared private keys in any case.

Anyway, the modder said above that he or she wasn't interested in adding security, just providing a bypass tunnel.

[twagner]

hi b,

thanks for the ideas, but do you have any suggestions
for the configuration of stunnel on the viewerside??
Because its very interesting to build a secure connection
to the repeater from any place where i work through the internet..

twagner

[B]

Sure. Assuming the limitation that JDaus mentioned above is true* -- that STunnel is limited to ONE connection on ONE fixed port per IP address -- then as long as you had another IP address reachable on your repeater, you'd run a second instance of Stunnel to secure that leg between the repeater and your viewer.

I used to do almost the same thing to secure inbound VNC connections by wrapping it in an SSH (not SSL) tunnel, but I found the whole house of cards a bit too unwieldy and unstable for my liking. (For one thing, my Windows SSH daemon kept deciding to take a vacation.)

I think having the whole thing tested and bundled is a key benefit of things like Chunk. One of these days I'm going to check on Amahi's offering.

* Edit: Still not sure whether that's right or not. I find at least one example of someone using multiple stunnels on a single machine: http://www.bacula.org/en/dev-manual/Usi ... ommun.html