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] [Updated] (SSHD-618) Support restricting server host key algorithms
Date Sun, 27 Dec 2015 12:58:49 GMT

     [ https://issues.apache.org/jira/browse/SSHD-618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Alon Bar-Lev updated SSHD-618:
------------------------------
    Description: 
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:
{code}
     protected byte[] sendKexInit() throws IOException {
-        String resolvedAlgorithms = resolveAvailableSignaturesProposal();
+        //String resolvedAlgorithms = resolveAvailableSignaturesProposal();
+        //String resolvedAlgorithms = "ssh-rsa";
+        String resolvedAlgorithms = "ecdsa-sha2-nistp256";
{code}
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.


  was:
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.



> 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:
> {code}
>      protected byte[] sendKexInit() throws IOException {
> -        String resolvedAlgorithms = resolveAvailableSignaturesProposal();
> +        //String resolvedAlgorithms = resolveAvailableSignaturesProposal();
> +        //String resolvedAlgorithms = "ssh-rsa";
> +        String resolvedAlgorithms = "ecdsa-sha2-nistp256";
> {code}
> 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
(v6.3.4#6332)

Mime
View raw message