VNC strong authentication, fixing the registry permissions

Tim Waugh twaugh "at" redhat.com
Fri, 24 Nov 2000 09:11:53 +0000


On Fri, Nov 24, 2000 at 10:24:15AM +1100, Andrew van der Stock wrote:

> I come from a security background (I'm a security architect by trade), and
> we use VNC all over the place despite the weaknesses. We currently use ssh
> tunnels, but it is not a total panacea, particularly on non-Unix platforms.

Are you using ssh's port forwarding, or stunnel?

> Unless you can find a stable native sshd port for Win32 (there are various
> non-native cygwin-derived sshd ports, but these are all flawed as they are
> not true NT services),

(I'm interested in why that is the case.  Why aren't they true NT
services, and why does being an NT service matter?)

> sshd is port forwarding the VNC traffic over
> potentially insecure network segments (typically true in a colocation
> scenario).

But sshd is encrypting it, surely?

> I've searched the archives, and I know of the NTLM and SSLeay and
> ssh contribs/methods. But these are irrelevant as they are not in
> the current distribution that freshmeat et al point to. The problem
> with security is that it is a continual learning and improvement
> process. Therefore, although these lessons have been learnt, and the
> improvements contributed, it amounts to nothing because it's not in
> the current public distribution.

Yes.

> I'm too new to *VNC development processes to understand the how and the why
> of why certain things are in the CVS mainline, and why somethings that I
> would love to see mainlined are in contrib.

It basically boils down to two development methodologies.  I'm
reasonably new to this list myself, so I stand to be corrected.

The AT&T VNC guys release patches to fix bugs, and (while there are
still bugs to fix) put links to new features on their web page rather
than incorporating them into their own source tree.  There is no CVS
archive.

The Tridia folks on the other hand _are_ keen to incorporate new
features, and _do_ have a CVS repository (based on the AT&T source
releases) with anonymous access and easy developer access.

> Encrypting traffic
>
> It's relatively easy to extend the current 3des helper class into a
> full blown 3des-cbc encryptor/decryptor. This would satisfy security
> freaks like me. Obviously in countries with silly crypto laws, this
> would have to be an option that can be compiled out.

Now *that* is a really good idea. [But I wonder if 'compiled out' is
enough for those countries.  I think it is now, but it wasn't long ago
that it wasn't.]

I'm not even completely sure which country the source code would be
exported from: since the website is now a .com rather than a .co.uk,
and since Tridia is based in America, would this present problems for
anyone?

> [...] Until IPsec becomes more common [...] individual protocols
> should take at least basic precautions against snooping and replay.

Yes, although rfbproxy kind of relies on this hole to do its job. ;-)
But encryption wouldn't happen over loopback, so that's fine.

> 2. Kerberizing VNC

This is interesting.

Tim.
*/

[demime 0.97b removed an attachment of type application/pgp-signature]
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to majordomo "at" uk.research.att.com
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------