Debian bugs requesting "safer" default algos/etc.

[Christoph Anton Mitterer]

Hi.

Another FYI:
Along with the recent publications about alleged NSA attacks against
SSH, we got some bug[0][1] reports in Debian about "please use more
secure algos" (i.e. disable all others).

Perhaps something you might want to look at.


- With respect to the DH group sizes, which is requested there to be
increased... well I've already opened #2302 and #2303, but these are
more related around DH-GEX, not about disabling e.g.
diffie-hellman-group1-sha1, diffie-hellman-group14-sha1 and possibly
even diffie-hellman-group-exchange-sha1 nor do they deal with the
request from the submitters of the bugs in Debian to no longer generate
small moduli by default.


- With respect to those submitters request to drop many "legacy" alogs
from the default lists... well it's difficult because of
interoperability, but I'd basically agree with that request... people in
need for those algos can still enable them manually or (for the client
side) even just on a per host basis.
I for example allow on my systems only these per default (in ssh_config
and sshd_config: 
HostKeyAlgorithms       ssh-ed25519,ssh-ed25519-cert-v01 at openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ecdsa-sha2-nistp384,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp256-cert-v01 at openssh.com,ssh-rsa,ssh-rsa-cert-v01 at openssh.com
KexAlgorithms           curve25519-sha256 at libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256
Ciphers                 chacha20-poly1305 at openssh.com,aes256-gcm at openssh.com,aes128-gcm at openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs                    hmac-sha2-512-etm at openssh.com,hmac-sha2-256-etm at openssh.com,umac-128-etm at openssh.com

I.e. everything that matches:
- dss, v00
- diffie-hellman
  => in principle I woluld allow diffie-hellman-group-exchange-sha256,
     but not as long as #2302 and #2303 are issues.
- arcfour, cbc
- sha1, md5, ripemd, umac-64 or that not matches etm
  => I have no real reason to believe that umac-64-etm at openssh.com isn't
     secure enough... I just thought better more bits, it doesn't hurt.

And I'm still thinking about removing all nist curves algos.
Also I'm well aware that the algos I've decided to drop are not
necessarily fully broken... but again,... better safe than sorry.


I'm not sure how much upstream is willing here to "harden" defaults,
since this usually goes on out-of-the-box interoperability... but I
think it would be better if any such hardening takes place on the
upstream side, than every distro cooking it's own stuff.


Cheers,
Chris.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774711
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774793
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150107/cf10f66a/attachment.bin>