So, I see that my suggestion has drawn up quite a lot of discussion. Let
me further my list of goals, and the suggested "requirements" of my
direction:
1) Adding encryption should add negligible size (of executable) and speed
(of encoding, in CPU use) costs to VNC.
2) Encryption should be "thin", but an integrated layer (see below)
3) Encryption should be either optional or mandatory (client _or_ server
should be able to require encryption, and either should be able to
decline, with failure to connect the result of they disagree about it)
4) Authentication should be improved too.
So, to quantify, I suggest that we can add a thin layer of encryption (by
thin, I mean a stream cipher mode only, with small dependence on outside
libraries, etc.). It should be free, as exportable as possible, and small.
For a school project, I played with the Rijndael algorithm (the AES final
candidate) last semester. It should be possible to build in Rijndael
support for less than 50k executable size increase on most platforms. It's
also fast, believed secure, and unpatented (meaning no licensing issues,
whatever, before it can be incorporated). I'm not averse to
multi-algorithm support, if that's desired, but it gets away from the
"thin" goal in targetting more flexible security. This is, in fact, a
large amount of the complexity which clouds such protocols as SSL, because
they must support different algorithms/authenticators. For "drop in"
easy-go encryption, I think that's something we want to avoid, but that's
just my opinion.
I'm still working out the authenticator framework. I'll post a proposal
for the authentication method soon. I'm thinking something DH-based, with
some form of host->user as well as user<-host authentication being a
feature of that - hard to fake, but not hard to code/likely to be
immediately broken. That's part of why I want others to help me, because I
want some help in the design phase.
Now, the problems of the current system:
1) Relying on an SSH daemon/platform to be available has a lot of faults.
One, different machines have different safety levels in the IP stack.
Would VNC notice if someone registers to listen for the port of the
outgoing SSH session? How does the VNC process verify that it's talking to
the actual end-point, and not a man-in-the-middle?
2) SSH is _not_ thin. It is appropriate as a well-studied general-purpose
encryption layer. It's not suited for a drop-and-go distribution. If
several different users install VNC, in their own space, on a single
machine, there's no implicit depedence between them. If several of them
install VNC, and want encryption, they all must rely on a central server,
as well as trust the operator of the machine to maintain appropriate
security. A layer _within_ VNC removes this external security dependence
(yes, if the admin is corrupt, you're traffic's still toast. But, if the
admin is an idiot, with this approach you get around it, with SSH you're
stuck with your idiotic admin who has unwittingly compromised your
security). If it comes down to people only being willing to support my
proposed effort if we base it around existing, progressive work, than SSL
(specifically, using OpenSSL) is a much better target.
3) My suggestion is for a closed system. If someone wants to study VNC for
security exploits, the whole system is available for study. With SSH as a
layer, there are several extra uncertainties in identifying weeknesses in
VNC (andw several extra inherent weeknesses, as well).
So, back to my plan. I plan to go ahead and implement a VNC server/client
pair that works this way. I'll work on what platforms I can. But, I'm
asking for discussion both to help me clarify my approach, and to seek out
others who can help with the coding and design phases, but also help with
platforms I can't work on. So, are there people out there interested in
helping with this?
--
Bryan Pendleton
ICQ #2680952
Phone: (877)780-3087
"The root of all knowledge lies within, but knowledge is useless unless it is
collected and shared."
---------------------------------------------------------------------
To unsubscribe, send a message with the line: unsubscribe vnc-list
to [EMAIL PROTECTED]
See also: http://www.uk.research.att.com/vnc/intouch.html
---------------------------------------------------------------------
