________________________________________ From: Alon Bar-Lev [alon.bar...@gmail.com] Sent: Thursday, December 17, 2015 9:22 PM To: dev@mina.apache.org; Lyor Goldstein Subject: Re: Selecting a specific KEX signature at client for server key
On 17 December 2015 at 18:19, Alon Bar-Lev <alon.bar...@gmail.com> wrote: > > 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? Other solution(?): if ServerKeyVerifier.verifyServerKey returns false, fallback and rekex with next signature algorithm until all exhausted? Not standard SSH as far as I know... > > Thanks, > Alon Bar-Lev.
