RE: UltraVNC Repeater over port 80 (http like)

For feature requests and bug reports RC15 RC16. Please use the forum at http://forum.ultravnc.net/

The original problem is to do with SC through proxied connections to a
Repeater in Mode II (a scenario that I also have trouble with). The
immediately obvious solution is an implementation of SC that _initiates_ an
HTTP session (which even the full server cannot do at the moment). I would
have serious concerns about security, however, and making it work with the
Repeater could get ugly. The ultimate solution would be to develop the
Repeater into something like an open-source version of GoToAssist, where the
host downloads a _server_ applet that communicates only with the Repeater.
The Repeater would have an SSL certificate to provide authentication and
security, and the applets that it supplies should be configured to only
communicate with the originating Repeater. That would be another project
unto itself, I suspect.

Rudi De Vos:
I think SSL is the way to go for the java applet. 
Need to be something cross platform. 

Sam schreef: 
For feature requests and bug reports RC15 RC16. Please use the forum at
http://forum.ultravnc.net/ 
Sean, 
I know I've said I will study and work on the key exchange question 
about 1 year ago... sorry. 
I still plan to implement dynamic key exchange to use over the DSMPlugin 
encryption and by following your idea (posted on the forum a few months 
ago) of a new rfbEncoding extension dedicated to "key exchange". 
It wouldn't avoid the necessity of the key file on both sides for the 
connection initialization, though... 
Will work on this as soon as the V1 is out. This time ;) 
I personaly don't like the SSL idea because of the certificate. 
But we still have to think about it (at least I have to). 
Sam 

Sean Covel a écrit : 
>For feature requests and bug reports RC15 RC16. Please use the forum at
http://forum.ultravnc.net/ 
> 
>All, 
> 
>Keep reading, I do have a related point to make, eventually! ;-) 
> 
>Rudi and I have been in discussion on-and-off about dynamic key 
>negotiation for the encryption stuff.  There are various "industry 
>standard" ways it can be handled, including Diffie-Hellman key exchange, 
>RSA key exchange, and others. 
> 
>(I'm curious how Real VNC Enterprise Edition implements encryption but I 
>haven't taken the time to research it...) 
> 
>I see this as a mixed bag.  Let me explain: 
> 
>The current setup requires the person attempting to connect to your 
>server to have YOUR keyfile in order to get a connection.  Until they 
>get that key they can't even get a password prompt.  This immediately 
>stops password-crackers.  Its a Good Thing.  This gets you encryption, 
>authentication (password), and authorization (keyfile). 
> 
>The Bad Thing is that if you want your buddy to connect to your PC for 
>some reason, you've got to distribute your key to him before he can 
>attempt a connection.  If you have multiple "SC" clients, you need to 
>keep your keys straight.  Using the same key for an extended period of 
>time can "leak" information about the key (although from what I read, 
>109 bits will keep you safe for about 40 years as long as the encryption 
>implementation isn't flawed...) 
> 
>That brings us to SSL.  If we implemented the standard SSL key exchange 
>this might allow users some options.  They could choose which Good 
>Things and which Bad Things they want to accept as risk.  Again, let me 
>explain. 
> 
>SSL uses Certificates for "Authorization."  The certificate can be used 
>to "identify" the server to the client (to prevent "man in the middle" 
>attacks).  If the client uses "strict" certificate checking, it is 
>basically like a "pre-shared" key.  If the client doesn't really care 
>the contents of the certificate, just that one exists, then it is almost 
>like having no key at all. 
> 
>This DOES require you to have an SSL certificate, either "legit" (costs 
>$$$) or "self-signed". 
> 
>This would get you encryption, authentication, and, if you want it, 
>Authorization.  Just remember, if you don't do strict certificate 
>checking, the only thing between your server, and that script kiddie 
>over there is your password. 
> 
>(side note:  VNC REALLY needs longer passwords....) 
> 
>SSL creates a session key for each connection, thus eliminating the "key 
>leakage" problem. 
> 
>If implemented properly, it "should" make it through port 443. 
> 
>Now all I need is the time and motivation to start working on something 
>like this... 
> 
>Sean 
> 
>I hope my rambling makes sense.... 
> 
>Jason Passow wrote: 
> 
> 
>>For feature requests and bug reports RC15 RC16. Please use the forum at 
>>http://forum.ultravnc.net/ 
>> 
>>Nope.  There is really nothing you can do with this using the single 
>>click version.  If you were to set up vnc on their computers using an 
>>ssl wrapper (search the forum) then you may be able to get through 
>>firewalls using ssl.  Afaik there is no way to use the sc version with 
>>an ssl implementation. 
>>Nir Kornfeld wrote: 
>> 
>> 
>> 
>>>For feature requests and bug reports RC15 RC16. Please use the forum 
>>>at http://forum.ultravnc.net/ 
>>> 
>>>Hello, 
>>> 
>>>I'm trying to use UltraVNC with the Repeater server over port 80. The 
>>>configuration I used is: * Mode II enabled 
>>>* Accept on port 5901 * Listen on port 80 
>>> 
>>>I reconfigured my router (with static IP) to forward all port 80 
>>>requests from the internet to the machine hosting the repeater (I'm not 
>>>using any web server on that IP address), and setup the OneClick VNC 
>>>Server (SC version that can be built using the site) to access the 
>>>repeater at my IP address over port 80, with some kind of IDs in it. 
>>> 
>>>So far so good! It works like a charm and bypasses a lot of firewalls on 
>>>my client machines. 
>>>BUT, with certain firewalls that actually inspect the contents of the 
>>>HTTP package (post 80 is used for HTTP) I can not get through. I guess 
>>>the repeater and the UltraVNC viewer/servers does not actually send a 
>>>"normal" http request - resulting in disgarded package by the firewalls. 
>>> 
>>>Any ideas? 
>>> 
>>>Thanks! 
>>>Nir Kornfeld 
>>>CTO 
>>>Odcanit Ltd. 
>>> 
>>> 
>>> 
>>>------------------------------------------------------- 
>>>SF email is sponsored by - The IT Product Guide 
>>>Read honest & candid reviews on hundreds of IT Products from real users. 
>>>Discover which products truly live up to the hype. Start reading now. 
>>>http://ads.osdn.com/?ad_ide95&alloc_id396&op=click 
>>> 
>>> 
>>> 
>>> 
>>> 
> 
> 
>------------------------------------------------------- 
>This SF.net email is sponsored by Demarc: 
>A global provider of Threat Management Solutions. 
>Download our HomeAdmin security software for free today! 
>http://www.demarc.com/info/Sentarus/hamr30 
> 
> 
> 
> 
------------------------------------------------------- 
This SF.net email is sponsored by Demarc: 
A global provider of Threat Management Solutions. 
Download our HomeAdmin security software for free today! 
http://www.demarc.com/info/Sentarus/hamr30


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/info/Sentarus/hamr30