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.
