mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alon Bar-Lev (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SSHD-618) Support restricting server host key algorithms
Date Sun, 27 Dec 2015 12:47:49 GMT

    [ https://issues.apache.org/jira/browse/SSHD-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15072144#comment-15072144

Alon Bar-Lev commented on SSHD-618:

---------- Forwarded message ----------
From: Lyor Goldstein <lgoldstein@vmware.com>
Date: 21 December 2015 at 18:23
Subject: RE: [GitHub] mina-sshd pull request: [SSHD-618] Support restricting server host...
To: "dev@mina.apache.org" <dev@mina.apache.org>
Cc: "alon.barlev@gmail.com" <alon.barlev@gmail.com>

This the wrong way to do this. You will have to wait until I return, however if you want to
get started here is the way to go:

- Define SignatureFactoriesManager interface that has get/setSignatureFactories factories
- Remove the definitions of these methods from their current interface and make that interface
extend the new one.
- Define UserAuthPubkeyFactory and its created UserAuthPublicKey instances  as implementing
this interface (both client and server side)
- Overwrite each factory's create function to set the created UserAuthPublicKey's signature
factories with its own.
- Overwrite the default factory instance setter to throw UnsupportedOperationException if
- In each UserAuthPublicKey (client or server) instance use a resolveSignatureFactoried method
that checks if the set ones are not null/empty..
    If null or empty the use the session's factories
- Write a unit test - e.g. in the ServerTest class that demonstrates this capability.

There are a lot more details, so if you cannot figure them out your pull request will not
do the necessary job.

> Support restricting server host key algorithms
> ----------------------------------------------
>                 Key: SSHD-618
>                 URL: https://issues.apache.org/jira/browse/SSHD-618
>             Project: MINA SSHD
>          Issue Type: Improvement
>    Affects Versions: 1.0.0, 1.1.0
>            Reporter: Alon Bar-Lev
> In current implementation the signature factories effects all algorithms that can be
used during a connection. There is no way of limiting only sever host key algorithm to be
able to request a specific server key. This is required in order to connect to pre-approved
server using weaker key.
> It should be possible as in rfc4253 "Algorithm Negotiation" we have two fields one for
available algorithms, and another for requesting a specific set of server keys which is subset
of the available algorithms.
>       name-list    kex_algorithms
>       name-list    server_host_key_algorithms
> In rfc4252 we have "Public Key Authentication Method:
> "publickey"" "Public key algorithms are defined in the transport layer specification".
So client public key types are subset of kex_algorithms.
> As far as I understand if we set kex algorithms of rsa and nistp256
> and force host key algorithms of rsa, we should be able to force
> server to use weaker algorithm while client can use any of rsa and
> nistp256.
> To prove that I hacked the AbstractSession with:
>      protected byte[] sendKexInit() throws IOException {
> -        String resolvedAlgorithms = resolveAvailableSignaturesProposal();
> +        //String resolvedAlgorithms = resolveAvailableSignaturesProposal();
> +        //String resolvedAlgorithms = "ssh-rsa";
> +        String resolvedAlgorithms = "ecdsa-sha2-nistp256";
> If I force ssh-rsa I receive ssh-rsa sever key as expected.
> If I force ecdsa-sha2-nistp256 I receive ecdsa-sha2-nistp256 server
> key as expected while can authenticate using client ssh-rsa key, this
> means that server and client are indeed detached.
> Adding an option to specify a list of server host key type like "ssh-rsa" or "ecdsa-sha2-nistp256"
will be nice as once having a pre-approved server keys, we can enforce them easily without
transformation/guessing signature algorithm.

This message was sent by Atlassian JIRA

View raw message