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

Mouse:


> I've encountered servers that misbehave – crash or something
> equivalent from the client's point of view - when faced with
> the string@domainname extension feature.

I am flummoxed by the existence of such implementations. Surely, that would 
not even be compatible with OpenSSH?

Have you seen any of these recently? Was that perhaps a decade ago, when 
OpenSSH maybe didn't have a KEXINIT full of string@domain algorithms by 
default?


> My stance, as above, would be that such implementations are
> broken and deserve nothing but ridicule, but your remarks
> above seem to imply you don't take that stance, or at least
> not as much as I do.

I do take the stance that a broken implementation is broken, but this does 
not change that I'm usually expected to do something about it, and folks 
want me to work around it so it works.

For the most recent example, an older version of a popular library used to 
have the "maximum channel packet size" concept completely borked up. For a 
channel opened by the remote party, this library would overwrite its own 
maximum packet size with the remote one. This caused at least two different 
kinds of session-ending problems to arise.

The library fixed this problem years ago. But a customer wrote an 
application using the old version - it worked until then, why fix it?! - and 
deployed that on N installations. These installations now wouldn't work with 
our software, but are difficult to update. It was less costly if we 
implement a coping mechanism. So we did.

I'd like to think our implementation is close to defect-free, but chances 
are someone somewhere was tasked to implement a workaround for a bug that 
existed in our software, even if it had long since been fixed.

We judge our own software based on the next version we're about to release; 
and other people's software based on all versions that existed. :)


> Hmm, I think I'll give moussh a configuration option to
> send things before the ID string, for exactly that reason.

That would be amazing. I could implement it as an option, but unless it is 
on by default, there's no way we'll get feedback.

At this point, the most feasible option I see is the type of probing you 
said you don't like: blind connections to random IP addresses to produce 
statistics how often it works or not.


denis



----- Original Message -----
From: Mouse
Sent: Saturday, March 25, 2017 20:43
To: [email protected]
Subject: Re: Fixing exchange of host keys in the SSH key exchange

>> 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)",
> Unfortunately, there exist implementations that disconnect, or
> generate an invalid key exchange hash, if that value is not zero.

I'm not sure what my stance is on that.

In general, I take the stand that if there are implementations that
don't implement the spec correctly, that's their problem, not a reason
to avoid using that part of the spec.  But, here, I don't think there's
any current spec for what an implementation should do if it finds a
nonzero value there, so I'm not sure to what extent _any_ behaviour in
response to that constitutes misbehaviour.  In retrospect, I think
specifying that RFU zero without giving any explicit guidance for
behaviour upon finding it nonzero was a mistake.

>> Also, 4253 says the server MAY send text before its version number,
>> but is silent on the question of whether the client also may.
> Of course, even if it did say otherwise, there could exist server
> implementations that do not handle this properly.

Of course - but then it would clearly be a case of the servers in
question being broken (and my stance would be that it's the server's
problem - see above).  As it is, it's not clear.

> It seems that testing would be in order.

Probably.  But it seems to me that any implementation SHOULD have
client configuration knobs so that Expect-Key: is not sent unless the
server is expected to be prepared to handle it.

> Or maybe the server sends something like "Expect-Key:
> support|require".  The format can vary between client and server.
> That might still not work if there are clients that violate 4253,
> though.

That's the problem of any such clients.  IMO.  (As I think I said
upthread, I've encountered servers that misbehave - crash or something
equivalent from the client's point of view - when faced with the
string@domainname extension feature.  Is that a reason to not use it?)

> Another way that would work for sure would be:

> - The server includes "expect-key" among its host key algorithms.
> [...]

> - If client sees "expect-key" among server's host key algorithms,
> [...]

Yesss...though there may exist implementations that misbehave upon
seeing a non-extension algorithm name they do not recognize.  (My
stance, as above, would be that such implementations are broken and
deserve nothing but ridicule, but your remarks above seem to imply you
don't take that stance, or at least not as much as I do.)

> This approach has downsides compared to Expect-Key before version
> string: [...]

Both true, though the second one (that it interferes with guessed kex)
is weak in that all it means is that clients and servers using this
extension can't really do guessed kex.  But all guessed kex really buys
you is one network roundtrip fewer, and I submit that if that matters
then either you have a _really_ laggy network or your PK crypto is so
weak that your security is questionable anyway. :-)

/~\ The ASCII   Mouse
\ / Ribbon Campaign
X  Against HTML [email protected]
/ \ Email!      7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B