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

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Iâ??m wondering if anyone - OpenSSH and PuTTY in particular? - would
> be interested in implementing an extension to the way the initial SSH
> handshake is done, in a way that would allow the SSH server to
> require the client to communicate one or more fingerprints of the
> serverâ??s host key(s), before exchanging KEXINIT.

> This would have multiple benefits:

> (1) Security benefit: [...] 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.

How?  As far as I can see, in order to do that, you have to move that
decision from the client to the server.  This carries its own prices.

> (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.

Yes...but if the server does that, it also becomes impossible for the
client to do the now-usual "just accept the key on the first
connection" thing.  You have to provide the host key to the client by
some out-of-band means.

This of course could be an upside or a downside, depending.

> (3) Practical benefit: the server [...] can avoid the situation where
> introduction of a new host key, with no change to previous host keys,
> would break connections for existing clients that prefer to negotiate
> the algorithm of the new host key, but do not actually trust it.

True.

Another possible benefit would be automatic defeat of
host-key-gathering bots.  My logs are full of clients that connect, get
my host key, and then disconnect.  A few of them are honest about what
they're doing ("SSH-2.0-ZGrab ZGrab SSH Survey", or
"SSH-2.0-OpenSSH-keyscan"); others are...less so ("SSH-2.0-PUTTY").
Most just report a library version (eg, "SSH-2.0-sshlib-0.1").

Or, rather, clients used to be doing that; I now disconnect such
clients before giving them any host keys (I prefer to not talk about
the details of what I've configured my server to require to get it to
talk to a specific client).

> Implementation:

> We have room for textual data that can be sent before the SSH version
> string.  To implement this, the client would send one or more lines
> such as:

> Expect-Key: <base64-sha256-fingerprint>\r\n

I strongly suggest that it instead be something like

Expect-Key: <hash-algorithm-name> <base64-hash>

so that when SHA256 finally shows weaknesses, it does not become a
major headache to switch hash algorithms.  If the server thinks the
hash algorithm is too weak, or doesn't recognize it at all, it can
ignore that line.  The client can of course send hashes of the same key
under multiple algorithms, if it wants.

I can't help wondering if perhaps this is time to use the uint32 in
SSH_MSG_KEXINIT that is "0 (reserved for future extension)", though,
rather than shoehorning it into something that's currently outside the
protocol (almost) entirely.  I see no guidance in 4253 for
implementation behaviour if that value isn't 0 - but see below.

Also, 4253 says the server MAY send text before its version number, but
is silent on the question of whether the client also may.  (I suspect
most server implementations share that code with their corresponding
client implementations, though.)

> However, we could also change the protocol to include the Expect-Key
> lines in the SSH key exchange hash. In this case, the client would
> signal support by sending at least one Expect-Key line, and the
> server would signal support in another way.  One way would be to
> include the name "expect-key" among its host key algorithms in
> KEXINIT.

The server has at least as much room to send text before its version
string as the client does.  It seems more elegant to me for the server
to signal support with something like

Accept-Expect-Key: yes

there - or perhaps to use that RFU uint32 in SSH_MSG_KEXINIT if the
client signals support (which would avoid the issue of an unaware
client printing that and thus confusing the user and possibly breaking
scripted uses, and also restrict nonzero values to implementations that
have already advertised awareness of this extension).

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B