Re: New Proposal for Section 11.1.4 Man-in-the-middle

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

Than you Simon, your comment makes the point I tried to make the other
day, but more clearly and eloquently than my poor attempt.

Nico

On Thu, May 15, 2003 at 03:27:41PM +0100, Simon Tatham wrote:
> Chris Lonvick  <clonvick%cisco.com@localhost> wrote:
> >    2. Use an authentication method that is not vulnerable to
> >       man-in-the-middle attacks.  For example, public-key authentication
> >       is not vulnerable to man-in-the-middle attack as long as the
> >       public-key of the server has been securely distributed to the
> >       clients before the first SSH connection is made.
> 
> Surely the other way round?
> 
> If the server's key has already been securely distributed to the
> client, then _no_ authentication method is vulnerable to MITM -
> that's precisely what the server's host key is for! I don't see how
> public-key authentication is any better than other methods in this
> respect.
> 
> If the _user's_ public key has been securely distributed to the
> _server_ before the first SSH connection is made, then public-key
> authentication might be able to verify the server's host key which
> was previously unknown.
> 
> However, this is conditional on the user being sure they really have
> connected to the right server! I grant that an MITM seeing a
> public-key authentication request wouldn't be able to use it to gain
> access to the real server; but they could simply return Yes, and
> _pretend_ to be the real server for as long as they could get away
> with it in the absence of a genuine login there, in the hope that
> the user might try to (for example) connect through to some other
> system and type a password in. The user would have to verify the
> connection by requesting some other piece of information from the
> server which they already knew but which the MITM would be unlikely
> to guess right.
> 
> Cheers,
> Simon
> -- 
> Simon Tatham         "The distinction between the enlightened and the
> <anakin%pobox.com@localhost>    terminally confused is only apparent to the latter."
>