As part of the session setup, the server sends the public key to the
client. The client then encrypts a random piece of data with the public
key and sends it back to the server. The server uses the private key to
decrypt it. This random data becomes the session key. In order for Eve
to be able to MITM, she would have to be able to decrypt the data to get
the session key. To do this, she would need Alice's private key. This is
also the reason that Eve can't observe the contents of the session, even
if she's been intercepting it since it's inception.

 This is slightly simplified. The sshd man page has a more complete
description: http://www.hmug.org/man/8/sshd.php

  Seren

-----Original Message-----
From: Christ, Bryan [mailto:[EMAIL PROTECTED] 
Sent: Thursday, August 31, 2006 2:21 PM
To: Seren Thompson
Subject: RE: Need some education: Man-in-the-Middle Attacks

Okay.  I have followed that so far, but I still have a question.  The
presumption is that Bob and Alice have verified keys (via phone call,
etc).  But even then, what prevents Eve from passing host challenge
information on to Bob.  In other words, although Eve cannot decrypt the
message, because she does not have the private key, Alice can because
she does.  Eve could simply pass the challenge information on to Alice,
get a valid reply, and then Eve would pass that back to Bob.  Bob would
never know that Eve is impersonating Alice and brokering messages. 

On Thu, 2006-08-31 at 11:38 -0600, Seren Thompson wrote:
>  This is true and why fingerprinting is useful.
> 
>  For the first connection attempt, Bob needs some way of verifying
that
> the public key being presented is the same as Alice's public key. The
> way to do this is usually an out-of-band exchange where Bob calls
Alice
> or meets with her and manually verifies that the fingerprint of her
key
> matches the fingerprint of the key he's being presented.
> 
>  The purpose of a fingerprint is for this human-verification process,
> since it's easier to read than the full public key.
> 
>  This is the same reason SSL works. Most browser come with
certificates
> preinstalled which is why you can verify that Verisign or some other
> authority has issued a web-site's ssl cert. Without the certs being
> preinstalled in the browser, you'd initially have to verify the
> authenticity of the certs for each website or signing authority, the
way
> you (should) do for self-signed certs.
> 
> 
> -----Original Message-----
> From: Christ, Bryan [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, August 30, 2006 4:05 PM
> To: Mark Senior
> Cc: secureshell@securityfocus.com
> Subject: Re: Need some education: Man-in-the-Middle Attacks
> 
> "Only if Eve gets in the way of the very first connection attempt, can
> he pass her own public key off as Alice's, without Bob detecting it."
> 
> This is exactly my concern.  Isn't that scary?
> 
> On Wed, 2006-08-30 at 12:52 -0600, Mark Senior wrote:
> > On 8/29/06, Christ, Bryan wrote:
> > > All,
> > >
> > > Please pardon my naivete.
> > >
> > > I was looking at the diagram on the URL listed below and
> > contemplating
> > > how host fingerprinting prevents MITM attacks.
> > >
> > >
> >
>
http://www.vandyke.com/solutions/ssh_overview/ssh_overview_threats.html
> > >
> > > So my question is this... Given the illustration in the URL above,
> > what
> > > prevents Eve from *first* contacting Alice to obtain a fingerprint
> > which
> > > then gets passed to Bob on the first connection attempt?
> > >
> > 
> > The server passes the client its public key; the client generates a
> > fingerprint of this public key, and verifies that it matches a known
> > one from previous connections.
> > 
> > Eve can pass Alice's public key to Bob, but she doesn't possess
> > Alice's private key, so she has no way to interfere further with the
> > communications (beyond tampering at a network level - introducing
> > delay, dropping the connection, etc.)
> > 
> > Only if Eve gets in the way of the very first connection attempt,
can
> > she pass her own public key off as Alice's, without Bob detecting
it.
> > On the first connection, he'd have to either trust what he sees, or
> > verify the fingerprint offline somehow.  On subsequent connections,
> > the mismatch would be obvious.

Reply via email to