>Some of you may remember me as one of those who started one of the periodic
>"we should add encryption" discussions a few months ago.
>
>Anyway, I'm back. And, having finished school, I finally have some time to
>experiment more directly with the code. I'd like to find any other
>developers or security specialists out there who would be interested in
>helping in the design, testing, and security strength evaluation process of
>adding a light encryption layer (ie, probably not doing PKI, or relying
>heavily on the pipe-dream of protected storage at a typical server) to VNC.
>
>Please e-mail me directly, off-list. I will gauge interest, and figure out
>which direction to go from there.
I've already got lots of ideas bouncing around in my head about this,
and some of them have been bounced off other people as well. At some
point I need to get them down on (virtual) paper and see if it still
makes sense as a whole...
The scheme I'm thinking of essentially encapsulates RFB in "packets"
of arbitrary length, but with each packet containing an integral
number of RFB messages. This adds robustness to VNC, even if no
encryption or compression is done within this format. I have a
protocol for initial key/scheme negotiation, some ideas on stream
format, and some justification for why things are so.
Yes, it's loosely based on ideas found in the SSH (v1 and v2)
protocol. AFAICT, SSH v2 is the Right Thing in many ways, but a
little over-complicated in some other ways. I've also seen some
examples of What To Avoid in the SSH v1 protocol, and duly attempted
to avoid them. Security is probably slightly weaker than SSH v2, but
I'm making workarounds and fixes for everything that people can
convince me is a problem, and I think it should actually be stronger
than SSH v1 (which most people are still using today!).
Note that SSH v1 suffers from the same "man in the middle"
challenge-swapping attack that VNC was shown vulnerable to, last year
- my scheme is not, except in well-defined, less common, and
user-avoidable circumstances.
Give me a little time (I'm moving out of university residence, bleh)
and I'll start work on documenting my extensions (and proposed
extensions, such as this one) to VNC. I think it'd also be a good
idea if I re-documented RFB itself, along with the various Tridia
extensions and Tight encoding - that way, eventually, we have all the
(technical) RFB documentation you could ever want, in one place.
Documentation on the "hows and whys" of ChromiVNC's performance
enhancements would also go there, to give people a chance to
incorporate them into other servers and improve VNC overall.
It looks a lot as though I'll have the whole summer to work on this,
and you can probably expect me to make the most of it.
--
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED] (not for attachments)
website: http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline: The key to knowledge is not to rely on people to teach you it.
---------------------------------------------------------------------
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
---------------------------------------------------------------------
