>> >SSH does its level best never to transmit any data in the clear.
>> >Even the initial authentication exchange is encrypted. The attack
>> >against VNC hinges on the fact that the server transmits the
>> >challenge string in the clear, which gives the man in the middle
>> >some data he can change without upsetting the client or server.
>>
>> I think I've got the picture. VNC needs two separate things if it is to
>> resolve security issues without (efectively) including SSH within itself:
>>
>> - Encryption, using either SSLeay, a subset thereof, or some discrete
>> trustable algorithm.
>>
>> - Authentication, from BOTH ends. The client needs to know it's
>> connecting to the right server, and the server needs to know
>> the client is legit.
>>
>> SSH throws up a big banner if the server's authentication key isn't kosher,
>> before any traditional user-authentication stuff flows over the wire. The
>> problem I can see is whether the same techniques could be used against any
>> connection, regardless of the protocol used. Consider the following
>> scenario:
>>
>> - C connects to S, using some future RFB with stronger authentication and
>> encryption.
>> - M intercepts C's connection, and immediately makes it's own connection
>> (sp00fed with C's real IP address) to S.
>> - S sends M the encryption key, which M makes a note of and forwards to C.
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>This step doesn't happen. The SSH client authenticates the server by
>knowing
>the server's public key; only the server can decrypt the client's
>initial
>handshake. The client and server can exchange a session key using the
>server's public key without ever opening themselves to an MITM attack.
Thanks for the explanation, it does make sense. The system works well for
a single or limited number of hosts, which even if they moved around on the
network retain the same filesystem... but what about the travelling
salesman using his hotel's WebTV terminal or an untrusted host/network
combination that happens to be running a browser? Does his network admin
require him to carry a floppy disk containing the server's encryption key,
or does he risk having the key sniffed by one of these MITM attacks (and
this one doesn't require modification of the stream!).
The answer may be to have the server send the key in an encrypted form
which can only be decrypted using the VNC server password, or a separate
"key password". And then only to have that done on a "once only" basis -
the key should be stored locally as far as humanly possible. Oh...
another problem. Java and WebTV have no local filestore to store such a
thing... and there's also the question of how to avoid J. Random Hacker
connecting to the server, retrieving the (encrypted) key, then cracking
away merrily until he finds it. The only solution to the latter problem is
big passwords, secure encryption, and therefore raising the barrier far
enough to make it a major deterrent to the kind of people capable of
setting up a MITM attack in the first place.
How to add this to the RFB 3.3 protocol? Simply add two new authentication
schemes - these are enforced by the server, not the client. The first
merely extends the length of the password usable and enforces a better
randomiser for generating the challenge. This will aid security for people
who don't want to wait for us all to finish fine-tuning our encryption
stuff.
The second new method waits for a message from the client, which indicates
whether the client has the server key or not. If not, the following client
message will be encrypted using the "key password" and will request the
server key, which should be sent, again encrypted using the "key password",
to the client. The server can now assume the client has the server key and
can now switch to it in both transmit and receive directions. At this
point a session key can be negotiated, after which regular authentication
(using the "first new method" outlined above) takes place and RFB messages
can be exchanged as normal - but now encrypted.
Both of the above methods need further discussion, partly due to my
complete lack of credentials as a security expert =) and also to agree on
exactly which algorithms we'll use for randomising and encryption. I
suspect that entropy-gathering of some form will be a requirement for the
randomiser - since it doesn't directly affect the client, different servers
can use different algorithms, but the guidelines should be universal and
enforce a minumum standard of randomness. Clients and servers supporting
the encrypted methods will need to alter their UI to support the entering
of an extra password, reporting of encryption/decryption errors, and so on.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: [EMAIL PROTECTED] (not for attachments)
big-mail: [EMAIL PROTECTED]
uni-mail: [EMAIL PROTECTED]
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S 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+
-----END GEEK CODE BLOCK-----
---------------------------------------------------------------------
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
---------------------------------------------------------------------
