Limited support for Diffie-Hellman and secure key exchange

[NandGates]

Summary

We have hardened our (on premise) Atlassian Bitbucket Server instance. This means we have removed key exchange algorithms that are not secure. Argo reports that it cannot check out an ssh repository from our BitBucket because no mutual key exchange algorithms can be found.

FATA[0000] rpc error: code = Unknown desc = ssh: handshake failed: ssh: no common algorithm for key exchange; client offered: [curve25519-sha256@libssh.org ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 diffie-hellman-group14-sha1], server offered: [diffie-hellman-group-exchange-sha256 diffie-hellman-group18-sha512 diffie-hellman-group17-sha512 diffie-hellman-group16-sha512 diffie-hellman-group15-sha512 diffie-hellman-group14-sha256]

Motivation

All of the supported ciphers are listed as weak (NIST curves or SHA1) , or are vendor specific (curve25519-256@libssh.org). See https://safecurves.cr.yp.to/ for reference.

I assume this is because argo is using the go crypto libraries (golang/crypto).

Proposal

golang/crypto also supports a secure cipher in the form of diffie-hellman-group-exchange-sha256 but this is not in the list of offered ciphers by argo.

Our teams have reported the exact same issue to the flux team, see fluxcd/flux2#1319 and fluxcd/flux2#1320.

We are evaluating a secure git-ops client to use and in the interests of being equitable would respectfully ask whether the Argo team can investigate adding a secure (non-broken NIST / SHA1) cipher to the KEX list so hardened git instances can make use of your (otherwise excellent!) product.

[NandGates]

Please add the security label when this is reviewed, as it is integral to many companies' penetration testing that their key exchange ciphers are secure - and at the moment this is not possible using Argo.

[jannfis]

Thanks for bringing this up, @jgalliers and also thanks for linking the ongoing discussions in the Flux repositories.

I do agree that the current situation is bad and needs a proper solution. I have done some research on my side, and while I'm not a cryptographer, found that at least diffie-hellman-group14-sha1 is not considered utterly broken at least [1][2], despite using SHA-1. But I do understand that people might want to turn this off, as GitHub has done so as well [3].

You are also correct in your assumption that the available Kex algorithms are limited by Golang's SSH implementation, which we partly use for some Git operations through go-git. We also do use the native Git client for most other operations, and this in turn uses the OpenSSH client for accessing repositories via SSH. So I guess we would need to take a look at its configuration as well.

The easiest solution would probably be to just enable diffie-hellman-group-exchange-sha256 in the SSH client used by go-git. I think it's turned off by default because their server side implementation doesn't support it (at least that's what they state in the code). I've seen that the Flux people also consider making the key exchange protocol configurable, that would be an option as well and we do that for TLS cipher suites already.

[1] https://tools.ietf.org/id/draft-ietf-curdle-ssh-kex-sha2-09.html#rfc.section.3.6
[2] https://weakdh.org/sysadmin.html#openssh
[3] https://github.blog/2017-02-27-crypto-deprecation-notice/

[jannfis]

The OpenSSH client shipped with v2.0 branch of Argo CD does support a more sensible list of Kex algorithms:

argocd@1f035602a87d:~$ ssh -Q KexAlgorithms
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256
curve25519-sha256@libssh.org
sntrup4591761x25519-sha512@tinyssh.org

The plan is to enable diffie-hellman-group-exchange-sha256 in go-git with the next patch release (v2.0.2) to enable use cases where Argo CD connects to hardened SSH servers, and to have the list of Kex algorithms configurable in the next minor release (v2.1).

[justincormack]

There is nothing wrong with using curve25519-sha256@libssh.org and it is identical to curve25519-sha256 that you list above for openssh (maybe Go needs to support both names, will check).

[jannfis]

There is nothing wrong with using curve25519-sha256@libssh.org and it is identical to curve25519-sha256 that you list above for openssh (maybe Go needs to support both names, will check).

This is probably correct (https://tools.ietf.org/id/draft-ietf-curdle-ssh-curves-07.html#rfc.section.4).

But as it seems, @jgalliers BitBucket server does only have FFC algorithms enabled. And I think that we should support at least one of those FFCs that are considered secure (one can argue over diffie-hellman-group14-sha1), without having to enforce the usage of ECC or ECDH onto users.

[jannfis]

Leaving this open for further discussions.

[NandGates]

@justincormack Thanks for the feedback and for those who may find this thread at a later point, currently there is an Atlassian Bitbucket-specific reason that we cannot use the @libssh variants, as detailed in this Atlassian support ticket.

The summary is a vendor-specific limitation related to the ssh library they are using (Mina SSHD).

This is definitely an accommodation of that limitation, but I do agree with @jannfis that not forcing users into ECC, EDCH or openssh-specific variants will be appreciated by a section of the community (such as us!).

[jannfis]

Hey @jgalliers, Argo CD v2.0.2 has just been released, which includes a fix to enable diffie-hellman-group-exchange-sha256 Kex algorithm for repository access. Feel free to give it a spin.

[jannfis]

Closing this issue now. Feel free to re-open.