ChunkVNC_https - proof of concept

[ahinson]

Now if we can get stunnel bundled in the ChunkVNC instantsupport.exe, that would be awesome.

Is there some way I can edit the deployment file to include this? I'm unfamiliar with how it's packaged.

[B]

Now if we can get stunnel bundled in the ChunkVNC instantsupport.exe, that would be awesome.

Is there some way I can edit the deployment file to include this? I'm unfamiliar with how it's packaged.

Well, sure, it's all out in the open for you to modify at will. As indicated in the original post in this thread, supercoe is already hosting the "one leg" stunnel mod, I think as a self-contained ChunkVNC SSL package.

Most or all of the coding and packaging (other than the actual UltraVNC components) is done using the AutoIT language.

http://chunkvnc.googlecode.com/


http://walkernerds.com/chunkvnc/

[ahinson]

Now if we can get stunnel bundled in the ChunkVNC instantsupport.exe, that would be awesome.

Is there some way I can edit the deployment file to include this? I'm unfamiliar with how it's packaged.

Well, sure, it's all out in the open for you to modify at will. As indicated in the original post in this thread, supercoe is already hosting the "one leg" stunnel mod, I think as a self-contained ChunkVNC SSL package.

Most or all of the coding and packaging (other than the actual UltraVNC components) is done using the AutoIT language.

http://chunkvnc.googlecode.com/


http://walkernerds.com/chunkvnc/

I thought so too but I didn't see a link for it on his site - I checked before asking.

[--Pennywise--]

I thought so too but I didn't see a link for it on his site - I checked before asking.

It's in my first post in this thread.

http://www.walkernerds.com/chunkvnc/ext ... _https.zip

Regards
--Pennyiwse--

[ahinson]

I did some testing using stunnel and chunkvnc from the provided file "ChunkVNC_3_1_https.zip" which is linked in previous posts. I have discovered some issues and solutions.

1. instantsupport doesn't use stunnel if you just fill the compiler as normal. If you do it correctly you need to edit the viewer config file after compiling
2. the stunnel config file included with "instantsupport.exe" has settings in it that won't work


1. It appears that the compiler isn't written in way to leverage stunnel, I'm sure this was never a concern but is an issue none the less. If you enter your FQDN into the compiler, e.g. "example.repeater.com" the "instantsupport.exe" will connect directly to the repeater - bypassing stunnel. This can be observed by checking active sessions in stunnel, which in this case should show as ZERO - because it's not using it.

The solution is to enter "127.0.0.1" in the compiler, because stunnel is listening locally, not on the remote address of your FQDN. This will allow "instantsupport.exe" to connect to the repeater through stunnel. However, it introduces another issue.

Because the compiler uses the address/ip entered into the compiler dialog to setup the viewer as well as "instantsupport.exe", the address we entered previously "127.0.0.1" is incorrect for this application. You need to edit and fix the viewer config file in order to connect to the repeater. (I haven't actually successfully connected both sides yet but this is wrong)

Code: Select all

[Repeater]
Address=127.0.0.1:5901 change this to your address -> example.repeater.com:5901

[ChunkViewer]
ListMax=10
List=
Quality=3

2. The stunnel config file that's included with the "instantsupport.exe" has a static IP in the connect property that isn't going to work.

Code: Select all

[ChunkVNC]
accept = 127.0.0.1:5901
connect=192.2.2.1:443 change this to your address -> example.repeater.com:443

I'm still testing.

[B]

Yeah, I would just recompile multiple versions instead. That's what I did to handle local versus remote IP/DNS for my repeater, since DNS isn't hairpinned here. I made one version called "LocalInstantSupport.exe" and one called "RemoteInstantSupport.exe". You have to copy or rename InstantSupport.exe <b>as well as</b> copy the Viewer directory each time you make such a unique compile, since both are affected. (You also have to leave a directory named "Viewer" in place going forward.)

[ahinson]

***Never mind I figured out what was wrong ***

I was running the wrong viewer. I have more than one copy of it.

So far, after spending some time I'm unable to connect to the repeater with the viewer.

I can connect fine through stunnel with instantsupport.exe but the viewer won't connect.

The repeater is running on a windows 2008 server that is in a multinat DMZ with it's own public IP and all ports exposed for the moment. I can see the port open using tcpview when I attempt to connect but it never is fully established.

Have I missed something?

instantsupport:

Code: Select all

[Repeater]
Address=127.0.0.1:5500

[ChunkVNC]
Installed=0
Path=
ID=

instantsupport stunnel:

Code: Select all

[ChunkVNC]
accept  = 5500
connect = my.fqdn.com:443

repeater stunnel:

Code: Select all

[ChunkVNC]
accept = 443
connect = 127.0.0.1:5500

repeater:

Code: Select all

server: 5500
viewer: 5901

Viewer:

Code: Select all

[Repeater]
Address=my.fqdn.com:5901

[ChunkViewer]
ListMax=10
List=407926|407926
Quality=3

[B]

Good. Please let us know if you manage to add the second stunnel for that second leg.

I suppose, at worst case, one could use stunnel on one leg and ssh for the other... but that would be crazy.

Again, I <b>think</b> the only exposure in the current SSL-enhanced package is the handshake and login on the viewer side, and that's if the RC4 keys are compromised.

[ahinson]

Good. Please let us know if you manage to add the second stunnel for that second leg.

I suppose, at worst case, one could use stunnel on one leg and ssh for the other... but that would be crazy.

Again, I <b>think</b> the only exposure in the current SSL-enhanced package is the handshake and login on the viewer side, and that's if the RC4 keys are compromised.

I tried this and it doesn't work. stunnel disconnects before it (the viewer) can connect. Maybe this is a limitation of stunnel?

I'm not too concerned about the data key being compromised. The connection from the viewer to the repeater will be local. I'm interested in this option offering a cheap way to satisfy client requirements that require transport layer session encryption for remote support. This will be a first effort alternative to setting up a permanent vpn in the concentrator for each client.

We'll see how this goes... Currently, I'm just testing it, and it seems to work great.

[B]

Good luck. Interesting comparison of Stunnel v. OpenVPN v. SSH at http://www.infosecwriters.com/text_reso ... cation.pdf

(PDF Warning)

It includes mention of multiple Stunnel support.

[JDaus]

It includes mention of multiple Stunnel support.

I believe that multiple stunnel are supported, but you need to use different ports for each tunnel (or different ips), as each tunnel is tied to a port.
eg.
accept 1.2.3.4:443
connect 127.0.0.1:5901
accept 2.3.4.5:443
connect 127.0.0.1:5500

or

accept 1.2.3.4:443
connect 127.0.0.1:5901
accept 1.2.3.4:80
connect 127.0.0.1:5500

please note ... the above are guesses of possible configuration options for repeater stunnel side. it has been many years since I looked at stunnel, and things may have changed in that time, but essentially, stunnel create a tunnel from a local port to a remote port. it tunnels that traffic through ssl (https).

any application that encapsulates data in some way (ssl, ssh or vpn) will take some processing time to encrypt / decrypt that data. ssl is by design, the quickest way of doing that encryption. but it will add latency to any application using it.

just thought this may clear up some things for people.

hope it helps ...

[vpdd]

Pennywise,

Could you update the https release to include 3.2 Chunck_VNC ?

Thanks a lot

[supercoe]

Glad to see others are interested in this, I was pouring over it last night considering doing a https release.

I'd be interested if Pennywise has any more insight on the best way to do this or if this was just left at "proof of concept".

[vpdd]

Well, if both (supercoe & Pennywise) work on it, it will be great

I do need it because many of my friends and clients are behind proxy/firewall where the only way around it is to use https (like Skype, logmein, etc does).

I find myself lacking the programming skill to help but I willing to test and help in any other way

thanks for all the work done so far

[Yod4z]

To bypasse the firewall..., no need to encapsulate, juste passe throught the port 443 to the repater.
chunckVNC to port 443, put the repeater waiting chunckvnc on port 443 in place of the default port and that's done

[supercoe]

Yod4z,

Thanks for the tip, Rudi has also given me some information for testing some new proxy support. Stay tuned.

[vpdd]

Yod4z,

I will try it today If it works for me, you not only help me but save the planet (no more car trips

Ok, not much of a joke but it really exited me ;D

Thanks !!

[vpdd]

Yod4z,

I tested it with not much luck, it seems any firewall or proxy/nat that goes a bit futher that just block ports will not allow ChunkVNC.


In any case I test it using ports 443 and then 80 behind:

Fail - Astaro 8 (http://www.astaro.com/landingpages/en-worldwide-homeuse)
Fail - Kerio Control aka WinRoute Firewall (http://www.kerio.com/control) - fail
Ok - Cisco PIX (basic SOHO model)
Fail - SonicWall UTM
(http://www.sonicwall.com/us/products/UT ... l_VPN.html)
Fail - Fortinet FORTIGATE-30B
(http://www.fortinet.com/products/fortigate/30B.html)

Thanks for the tip I got remote support to one more place

However, I still need a https wrap at least for the client part (server)...

[supercoe]

vpdd,

Once I get a test build of a proxy supporting ChunkVNC I'd like to PM you for a test. Seems like you have many more test cases than I do.

[vpdd]

Please do so, I will be more than happy to help ;D

[Yod4z]

Yes this tip work only for proxy/firewall that block only port.

We do this on my society from 5 year without any problems with lot of our customers

[tbran6]

If another tester for the http version is needed I’d be glad to test. I'm behind a corporate CheckPoint firewall, I currently can not connect to my repeater via regular Chunk because of my company’s FW.

tbran6

[supercoe]

Sounds great, I might not have time until this weekend to do some coding but I'll be sure to PM you both.

[redge]

let me part of testers for chunkVNC SSL and repeater SSL/http
with donation if all tree users success remote control

[tbote]

Yes this tip work only for proxy/firewall that block only port.

We do this on my society from 5 year without any problems with lot of our customers

I've also use this trick for years and works ok. Not so much companies use protocol filters, so this is the easyest solution.

Regards

[supercoe]

Just wanted to update everyone interested in proxy support.
I've just spent the last few days testing proxy support code that Rudi will be including in the main UltraVNC executable and the results look promising.

There are a few bugs to work out before repeater support will function but as soon as it works I'll release a ChunkVNC HTTPS beta.

[tbran6]

awesome stuff, like always

[vpdd]

Thanks supercore

[redge]

you welcome to post url as soon is ready for test
as welll, would be good to force securevnc to use arc4 for private use chunckvnc ready to roll swiss. so i'm not worry enterprise want to use of lake of high security for free

[supercoe]

redge, vpdd, Yod4z, tbran6 you will have a PM with the download link.

Since ChunkVNC HTTPS will be not be using stunnel like in Pennywise's proof of concept I've created a new thread:
[post=82487][/post]