Bug 7535 - Drop support for insecure ssh-rsa
Summary: Drop support for insecure ssh-rsa
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.15.0
Assignee: Pierre Ossman
URL:
Keywords: relnotes, tobfa_tester
Depends on: 7536 7961
Blocks:
  Show dependency treegraph
 
Reported: 2020-07-14 14:44 CEST by Pierre Ossman
Modified: 2022-07-14 16:07 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:
* Client should refuse to connect to host¹ that only support SHA-1 for RSA host key exchange * Client should refuse to authenticate to host that only support SHA-1 for RSA public key authentication * A clear error message should be shown in the above cases ¹ Both master and agent, which complicates things as the agent host key handling is a bit special


Attachments

Description Pierre Ossman cendio 2020-07-14 14:44:28 CEST
Upstream OpenSSH are flagging that they are about to drop support for the "ssh-rsa" method:

> It is now possible[1] to perform chosen-prefix attacks against the
> SHA-1 algorithm for less than USD$50K. For this reason, we will be
> disabling the "ssh-rsa" public key signature algorithm by default in a
> near-future release.

Better alternatives are available, even with the same keys on disk. OpenSSH 7.2 or newer is ideally required.

RHEL 7 has 7.4, so it's fine. But RHEL 6 has the ancient 5.3 so it will not be possible to connect to such systems in the future.

We need to consider if we should just follow upstream and drop support, keep supporting it despite upstream, or add an option to re-enable it if users need to. 

We also need to consider longer support for ssh-rsa in our ssh-keyscan as older clients might still be used.


OpenSSH only talks about host keys, but I would guess that public key authentication is also affected in the same way.


Also note bug 5539 for 4.5.0 where ssh-dsa support was dropped. We dropped support right away in the client, but kept support in keyscan.
Comment 3 Pierre Ossman cendio 2022-07-08 10:38:25 CEST
(In reply to Pierre Ossman from comment #0)
> Also note bug 5539 for 4.5.0 where ssh-dsa support was dropped. We dropped
> support right away in the client, but kept support in keyscan.

Apparently, upstream has kept support in ssh-keyscan. So no need for local modifications here.
Comment 4 Pierre Ossman cendio 2022-07-08 11:16:59 CEST
Argh! Apparently you cannot force SHA-1 for neither host keys nor public keys in the server, which makes testing this a pain. I guess I'll have to spin up something with an old OpenSSH server.
Comment 5 Pierre Ossman cendio 2022-07-11 09:05:47 CEST
Ubuntu 16.04 is still too new, but CentOS 6 is sufficiently old that it lacks the newer ssh-rsa methods.

On paper, it doesn't support the new ECDSA/ECDH stuff, though. But it seems Red Hat has back ported it, so you can still add such host keys:

https://access.redhat.com/solutions/711953
Comment 10 Pierre Ossman cendio 2022-07-11 11:06:30 CEST
Works well now. Tested using a CentOS 6 machine and a Fedora 35 client:

> * Client should refuse to connect to host¹ that only support SHA-1 for RSA
> host key exchange

Yup. Tested both master and agent connection. For the agent connection I started vsmagent whilst sshd was only configured for ssh-rsa. I then reconfigured it to also support ECDSA. That way, the master connection succeeds, but the agent connection fails.

> * Client should refuse to authenticate to host that only support SHA-1 for
> RSA public key authentication

Yup.

> * A clear error message should be shown in the above cases

Yup. In all cases it shows an error message stating that there is a compatibility issue with the server.
Comment 11 Tobias cendio 2022-07-14 16:07:46 CEST
General
======================================
Testing of this bug has been done on CentOS6 -- reason being the inability of
OpenSSH to break down host key algorithms, allowing us to isolate and test
combinations of the hash and encryption algorithms, as mentioned in comment 4
and comment 5 -- using ThinLinc server official release 4.11, and Fedora36
employing developer clients #2639 (pre-fix) and #2660 (post-fix).

Acceptance criteria
======================================

[✔] Client should refuse to connect to host that only support SHA-1 for RSA host
    key exchange.

- Allowing only RSA host keys:
    pre-fix : successful connection
    post-fix: failed connection

- Allowing RSA and ECDSA host keys:
    pre-fix : successful connection
    post-fix: successful connection

- Reproduced the effect mentioned in comment 10, by not restarting vsmagent
  after allowing additional host key algorithms beyond RSA. Client connects to
  master, but fails while proceeding to agent; successful connection after
  restarting vsmagent.

[✔] Client should refuse to authenticate to host that only support SHA-1 for RSA
    public key authentication.

- Allowing only RSA host keys:
    pre-fix : successful connection
    post-fix: failed connection

- Allowing RSA and ECDSA host keys:
    pre-fix : successful connection
    post-fix: successful connection

- Reproduced the effect mentioned in comment 10, by not restarting vsmagent
  after allowing additional host key algorithms beyond RSA. Client connects to
  master, but fails while proceeding to agent; successful connection after
  restarting vsmagent.

[✔] A clear error message should be shown in the above cases.

- There's an updated error message dialog, in addition to the log error.

Summary
======================================
The acceptance criteria are fulfilled: ThinLinc servers supporting solely
ssh-rsa host key algorithms are not accepted by clients, neither using password
nor public key authentications, and the error message dialog has been updated.

Closing.

Note You need to log in before you can comment on or make changes to this bug.