>> >> You can't do this. That's kind of the point about SSH tunnels. If
>> >> you could set them up automatically, they would be completely
>> >> ineffective at authentication.
>> >
>> >????
>> >
>> >I might have misunderstood, I don't use SSH very much, but from an
>> >encryption-only standpoint (Using VNC's own authentication, which would go
>> >through the SSH tunnel too, so we don't have to worry about the security
>> >problems recently posted), SSH should be simple and easy to implement,
>> >right?
>> >
>> >I understand that a lot more may be involved if authentication is the name
>> >of the game, but at least for my uses, I only really want/need encryption.
>>
>> The security advisory posted the other day was about authentication
>> vulnerabilities. Hmm. I'd like to see if/how SSH gets around the type of
>> attack posted in that advisory...
>
>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.
- C sends M it's own encryption key, which M can read because it knows S's
key too. M makes another note and forwards the still-encrypted key to S.
Now M can read both halves of the conversation.
- M watches any further authentication tokens pass by. As many tokens as
are specified can be passed in this way, with server authenticating client
and vice versa.
After the last authentication step has been passed, M can either break the
connection to C and use the existing, authenticated channel to talk to S,
or it can simply mediate the connection to conclusion and leave the
authentication tokens in a safe place for later cracking.
If someone can give me a SINGLE example of a protocol which is NOT
susceptible to the above attack (which can be practised by any host capable
of both listening to and modifying the packet stream, eg. a rogue or
compromised router or firewall), I'd be very interested to hear how it
works.
--------------------------------------------------------------
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
---------------------------------------------------------------------
