Jonathan Morton wrote:
>
> >> >> 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.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
(That's assuming the server key is symmetric; I don't remember for sure.
If
not there are secure key exchange protocols that can be used.) The
server
authenticates the client any number of ways, but ALL of those ways are
handled using the session key negotiated in the initial exchange. So
even
if the client is authenticated using the plain Unix password, that
password
never ever travels in the clear.
*For convenience only*, the very first time you connect to a particular
server,
the client offers to fetch the server host key for you; it caches it in
a file in your .ssh directory for use in future connections. That
initial
connection is the *only* time any authentication data travels in the
clear.
Of course, if you are well-paranoid, you install the host keys on the
clients by hand instead.
Since changing even a single bit in any encrypted message will make
the attacker's presence immediately known, the SSH authentication
mechanism
is not vulnerable to the attack you've outlined.
-- Joe
> - 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.
-- Joe Knapka
---------------------------------------------------------------------
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
---------------------------------------------------------------------
