mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alon Bar-Lev <alon.bar...@gmail.com>
Subject Re: Selecting a specific KEX signature at client for server key
Date Fri, 18 Dec 2015 19:07:06 GMT
On 18 December 2015 at 19:56, Lyor Goldstein <lgoldstein@vmware.com> wrote:
> I don't think what yo described is possible tor standard SSH. The KEX must use a key
type that is available for both the server and the flient. If you look at the KEX INIT command
you 2ill notice that there is only ONE FIELD tor key signatures,  unlike ciphers. MACs and
compression wher each side can choose what to use.  Bottom line, you cannot force the server
to present a weaker key than the client. However,  all is not lost - OpenSSH servers do support
a non-standard extension where they send ALL their keys. I only recently added support for
this - look for the OpenSSHHostKeys global request handler

Thanks for the reference, I have saw this when looking at the recent
changes, but did not make the connection between the two.

This happens after user authentication, so in case of password
authentication server already has the password, which is kinda
strange, I will send a question to openssh devs.

As far as I see at sshd-core, there is no support for the
hostkeys-prove-00@openssh.com at client, am I right? What is the
sequence of usage at client side?
I guess setGlobalRequestHandlers with my own instance inherited from
OpenSshHostKeysHandler to accept keys, then I should ask for prove for
selected keys, how can I do that?


> From: Alon Bar-Lev [alon.barlev@gmail.com]
> Sent: Thursday, December 17, 2015 6:19 PM
> To: dev@mina.apache.org; Lyor Goldstein
> Subject: Selecting a specific KEX signature at client for server key
> Hello,
> I have a challenge...
> Let's assume I need to securely reconnect to a server, for that purpose I store its public
key. Every time I connect to this server I compare the public key accepted by ServerKeyVerifier
with the public key that is approved.
> This works perfectly and securely, well, until server adds a stronger algorithm/public
key, for example, a server with ssh-rsa key adds ecdsa-sha2-nistp256 one.
> In this case KEX selects the stronger one, causing client to reject the server as  public
key differs.
> I found a solution to this problem is to limit the signature algorithms based on the
public key type. We know the public key, so we can limit the KEX to use only this type of
signature, for example, assuming the approved key is ssh-rsa we can:
>     client.setSignatureFactories(Collections.singletonList(BuiltinSignatures.rsa))
> Now, even if the server has ecdsa-sha2-nistp256 key, the client will only receive the
ssh-rsa key.
> This works find as long as password authentication is used.
> However, as the signature factory is common to both client and server KEX, this will
not work in all cases for public key authentication, as the factory must contain the union
of both, for example:
>  server has both ssh-rsa and ecdsa-sha2-nistp256 keys.
>  client caches the ssh-rsa.
>  client key is ecdsa-sha2-nistp256.
>  client must enable both rsa and nistp256 signatures for KEX to succeed.
>  server key will be ecdsa-sha2-nistp256 as it is the strongest among ssh-rsa and ecdsa-sha2-nistp256.
> Keep in mind that my understanding of the code is limited, I reviewed the session callbacks,
but from what I do understand there is no way to separate KEX algorithms of server from these
of client, as both are in the same base class KexFactoryManager.
> If I understand correctly, a solution could be implemented by having two signature factories,
one for client side and one for server side, or have a filter for client and server, to enable
forcing a specific set of algorithm for each side.
> Maybe I mis-read the code and there is an option of forcing server to use a specific
key differently.
> Any clue?
> Thanks,
> Alon Bar-Lev.

View raw message