Bug#774711: update of debian openssh crypto defaults

Matt Taggart <[email protected]>
Newsgroups gmane.linux.debian.devel.ssh
Message-ID <898538e3-0634-4330-49b7-ad7192a30e3f__18984.5926872053$1664921730$gmane$org@lackof.org>
It has been a while since I reviewed the state of #774711 compared to 
upstream. First here are the relevant changelog entries since I last did.

7.5
ssh(1), sshd(8): Support "=-" syntax to easily remove methods from
       algorithm lists, e.g. Ciphers=-*cbc.

7.6
ssh(1): Delete SSH protocol version 1 support, associated
       configuration options and documentation (LP: #1584321).
ssh(1)/sshd(8): Remove support for the hmac-ripemd160 MAC.
ssh(1)/sshd(8): Remove support for the arcfour, blowfish and CAST
       ciphers.
Refuse RSA keys <1024 bits in length and improve reporting for keys 
               that do not meet this requirement.
ssh(1): Do not offer CBC ciphers by default.

7.8
ssh(1)/sshd(8): Add new signature algorithms "rsa-sha2-256-cert-
       [email protected]" and "[email protected]" to 
explicitly
       force use of RSA/SHA2 signatures in authentication.

8.0
ssh-keygen(1): Increase the default RSA key size to 3072 bits,
       following NIST Special Publication 800-57's guidance for a 128-bit
       equivalent symmetric security level (LP: #1445625).

8.1
ssh(1), sshd(8): Allow prepending a list of algorithms to the default
       set by starting the list with the '^' character, e.g.
       "HostKeyAlgorithms ^ssh-ed25519".

8.2
ssh(1), sshd(8), ssh-keygen(1): this release removes the "ssh-rsa"
       (RSA/SHA1) algorithm from those accepted for certificate signatures
       (i.e. the client and server CASignatureAlgorithms option) and 
will use
       the rsa-sha2-512 signature algorithm by default when the 
ssh-keygen(1)
       CA signs new certificates.
ssh(1), sshd(8): Remove diffie-hellman-group14-sha1 from the default
       key exchange proposal for both the client and server.

8.5 

ssh(1), sshd(8): change the first-preference signature algorithm from
       ECDSA to ED25519.
ssh(1), sshd(8): remove the pre-standardization cipher
       [email protected].

8.8
This release disables RSA signatures using the SHA-1 hash algorithm by
       default.  (Existing RSA keys may still be used and do not need to be
       replaced; see NEWS.Debian if you have problems connecting to old SSH
       servers.)

8.9
ssh(1), ssh(8): since DSA keys are deprecated, move them to the end of
       the default list of public keys so that they will be tried last.

 From my last comparison on 20 Apr 2018, the following unsafe things are 
still supported in 9.0 and debian:

======================================================================
Keys:
* NIST curves (ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, 
ecdsa-sha2-nistp521)

Kex:
* NIST curves (ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521)
* diffie-hellman-group14-sha1, diffie-hellman-group-exchange-sha1
     (supported, but no longer in the default set))

MACs:
* umac-64
======================================================================

Those are the things remaining from the original "stribika" analysis. 
The new ssh-audit.com recommendations are similar and disable the following:

======================================================================
Ciphers:
* 3des-cbc
* aes128-cbc aes192-cbc aes256-cbc
* [email protected]

Kex:
* ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521
* diffie-hellman-group14-sha256
* diffie-hellman-group1-sha1 diffie-hellman-group14-sha1

MACs
* [email protected] [email protected]
* [email protected] hmac-sha1
* [email protected]  (prefers [email protected])
* hmac-sha2-256 (prefers [email protected])
* hmac-sha2-512 (prefers [email protected])
 

HostKeyAlgorithms:
* ecdsa-sha2-nistp256 ecdsa-sha2-nistp384 ecdsa-sha2-nistp521
* [email protected]
   [email protected]
   [email protected]
* [email protected]
   [email protected]
* [email protected] ssh-rsa

======================================================================

This mostly matches the original "stribika" which it is based on, here 
are some observations:

* The Ciphers they recommend removing:
   3des [email protected] aes128-cbc aes192-cbc aes256-cbc
dropped off the radar here because are all disabled by default, but it 
is now well past the time to disable them completely in the server (and 
possibly the client)
* Similarly, Kex:diffie-hellman-group*-sha1 and MAC:umac-64 should be 
fully disabled in the server, and soon the client.
* HostKeyAlgorithms:ssh-rsa/[email protected] are dropped in 
8.2. They should go away but I am unsure when.
* In some cases they prefer the longer "@openssh.com" version, and don't 
explicitly list the short name, I don't know why.
* Why are NIST curves still enabled? They've been proven harmful for 8+ 
years.


Using the new '=-','^','+','-','*' syntax, it is possible to specify 
configuration changes relative to the default, in a way that 
future-proofs the config for additions/removals in future upstream 
versions. Right now that might look something like

======================================================================
Ciphers -3des-cbc,aes*-cbc,[email protected]

KexAlgorithms -ecdh-sha2-nistp*,,
     diffie-hellman-group14-*,diffie-hellman-group1-sha1

MACs -umac-64*,hmac-sha1*,[email protected],
     hmac-sha2-256,hmac-sha2-512

HostKeyAlgorithms -ecdsa-sha2-nistp*, sk-ecdsa-sha2-nistp*,
     [email protected],ssh-rsa
======================================================================

But one might choose to explicitly list the things to enable to prevent 
surprises (at the risk of continuing to support something that upstream 
drops from the default).

When I set out to write this, I was hoping everything in the original 
report had been dealt with by now, there has been a lot of progress 
upstream. But it seems there are still a few things left, let push to 
get this done!

Thanks,
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.