Mailing List Archive

On 17-6-2010 8:45, Aaron Brooks wrote:
> Hi,
>
> I'm running X11vnc on my server with the following command
> "/usr/local/bin/x11vnc -bg -forever -xkb -rfbauth /etc/x11vnc/passwd
> -o /etc/x11vnc/log". This provides password protection to the server,
> but it doesn't provide any encryption, so I would assume that the
> frames are passed over the internet unencrypted.
>
That's verry true. That's all you get from VNC and its all you need.

> The problem is, whenever I use -ssl or -enc on the X11vnc server, the
> RealVNC viewer chucks a hissy and refuses to connect. Does anyone have
> experience with getting these two working nicely, encrypted? (And I
> don't really want to have to set up an SSH tunnel every time I want to
> VNC to my machine, I know it's more secure, but less convenient).
>
Be noted, the X11VNC server process has 2 network sides:
The X11 side as being an X11 server. This is the communication protocol
between the application an the display. Runs by default at port 6000,
6001, 6002 and so on, depending on the display number you use in X11.
X11 display number 10 (as used in ssh-X11 tunnel) runs at port 6010. I
donnot know if or how this port number can be overrulded.

Then there is the VNC side, being a VNC server. This is the
communication protocol between the X11VNC application and the VNC viewer
you are using. This runs by default on port 5900, 5901, 5902 and so on,
depending on the display number you use in X11. X11 display number 5
runs at port 5905. This port number can be overruled by an option.

To be complete: most VNC servers, including the X11VNC server, can also
act as a (verry simple, limited) webserver, to provide a java-viewer in
a webpage. This webserver runs by default on port number 100 below the
vnc-port: 5800 for the real default, 5805 where VNC runs at 5905.

Correct me if I'm wrong, but as far as I know, the -ssl and/or -enc
options are for the X11 communication, part of the X11 specification. As
far as I know, VNC only has compression, no encryption. However, there
are new, modern, special implementations that do fancy some encryption.

For what its worth, I'd never trust application-based encryption. If I
need encryption, I use a tunnel like VPN or SSH as they are build for
that purpose. Then run the vnc-communication trough that tunnel.

My 2 cents,

CBee

_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

In a message dated 2010.06.18 04:16 -0500, Corne Beerse wrote:

> For what its worth, I'd never trust application-based encryption. If I
> need encryption, I use a tunnel like VPN or SSH as they are build for
> that purpose. Then run the vnc-communication trough that tunnel.

CBee, after years of reading your posts I respect your judgment, but
this is not clear to me: Why is application-based encryption inferior?

John

_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list

On 18-6-2010 19:58, John Kaufmann wrote:
> In a message dated 2010.06.18 04:16 -0500, Corne Beerse wrote:
>
>> For what its worth, I'd never trust application-based encryption. If
>> I need encryption, I use a tunnel like VPN or SSH as they are build
>> for that purpose. Then run the vnc-communication trough that tunnel.
>
> CBee, after years of reading your posts I respect your judgment, but
> this is not clear to me: Why is application-based encryption inferior?
>
> John
That is my general idea: If I choose an application, I do it for the
functionality. If I want security, I like to make a reasonable choice.
In the past I have seen several implementations of a communication
protocol that have added their own security. These appeared to be
inferior after a while but I could not update or change as I still
needed the tool itself.

With tunneling over an ssh connection or over a vpn tunnel, the security
can be updated and altered without changing the communication tools.

On the other side, there are good examples of 'combined' security. And
of course there is also the ease of use and ease of administration that
comes to mind. In fact, ssh is the secure variant of rsh/telnet and
such, effectively a combination. However, here I see it as reverse: the
security is the base of ssh, the shell-connection is here the added
protocol and it shows: the remote shell part of ssh works but there are
better tools. And other protocols can use the same tunnel.


My 2 cents

Corné

_______________________________________________
VNC-List mailing list
VNC-List@realvnc.com
To remove yourself from the list visit:
http://www.realvnc.com/mailman/listinfo/vnc-list