Re: Fixing exchange of host keys in the SSH key exchange

[Peter Gutmann <[e-mail]>]

denis bider (Bitvise) <[e-mail]> writes:

>(1) Security benefit: although the client could still not verify the server’s
>signature during key exchange, or could do any number of other things
>incorrectly; under reasonable assumptions, if the client has to communicate
>one or more fingerprints of the server’s host key(s) before KEXINIT, this
>prevents the situation where the client will present the user with a host key
>verification dialog, and the user will just click through it.

It also makes things a lot more painful for the user.  If you regularly need
to SSH into a dozen different devices to administer them, it gets even worse.

>(2) Security benefit: on servers that enable this policy, and prevent
>connections where the client does not communicate a correct server host key,
>drive-by password guessing becomes largely impossible, since unknown
>attackers do not know the server’s host key.

This is really just an awkward form of port-knocking.  If you want to use a
port-knocking-style mechanism, you should probably do it properly.  If you
want to bind a client to a server ("only this client, only this server") then
there are better ways of doing it than this.

>Server implementations that do not know about this extension, but correctly
>implement the spec, 

How do we know what percentage of servers do this?  It's true that the spec
says you should expect other stuff in the textual data, but since pretty much
everything out there only ever sends the SSH ID string, it's quite likely that
lots of implementations will choke on unexpected extra lines of text.  Even in
cases where the code does try and handle non-SSH-ID lines, the absence of
anything that sends them means it's probably never been tested.

This doesn't seem like a good idea, it has the potential to break lots of
things, while what you're getting in return could be done better in other
ways.

Peter.